{"id":36115,"date":"2019-10-31T22:09:42","date_gmt":"2019-10-31T19:09:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete\/"},"modified":"2019-10-31T22:09:42","modified_gmt":"2019-10-31T19:09:42","slug":"ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"Stimmen Sie nicht zu, etwas zu entwickeln, das Sie nicht verstehen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Stimmen
\n
\nSeit Anfang 2018 bin ich Teamleiter\/Projektleiter\/F\u00fchrender Entwickler in meinem Team \u2013 nenn es, wie du willst, aber im Grunde bin ich vollst\u00e4ndig f\u00fcr eines der Module und alle Entwickler, die daran arbeiten, verantwortlich. Diese Position er\u00f6ffnet mir eine neue Perspektive auf den Entwicklungsprozess, da ich an einer gr\u00f6\u00dferen Anzahl von Projekten beteiligt bin und aktiver an Entscheidungsprozessen teilnehme. K\u00fcrzlich wurde mir dank dieser beiden Umst\u00e4nde bewusst, wie stark das Ma\u00df an Verst\u00e4ndnis den Code und die Anwendung beeinflusst.<\/p>\n

Der Gedanke, den ich ausdr\u00fccken m\u00f6chte, l\u00e4sst sich so zusammenfassen, dass die Qualit\u00e4t des Codes (und des Endprodukts) eng mit dem Zusammenhang steht, wie sehr die Menschen, die mit dem Entwerfen und Schreiben von Code besch\u00e4ftigt sind, sich bewusst sind, was genau sie tun.<\/p>\n

Vielleicht denken Sie jetzt: \u201eDanke, Kapit\u00e4n. Nat\u00fcrlich w\u00e4re es gut zu verstehen, was man \u00fcberhaupt schreibt. Andernfalls k\u00f6nnte man genauso gut eine Gruppe von Affen engagieren, die wahllos auf die Tasten hauen.\u201c Und Sie haben vollkommen recht. Daher gehe ich davon aus: Sie sind sich bewusst, dass es notwendig ist, ein allgemeines Verst\u00e4ndnis daf\u00fcr zu haben, was man tut. Dies kann als nullter Grad des Verst\u00e4ndnisses bezeichnet werden, und dar\u00fcber werden wir nicht im Detail sprechen. Wir werden im Detail untersuchen, was genau verstanden werden muss und wie sich das auf die Entscheidungen auswirkt, die Sie jeden Tag treffen. H\u00e4tte ich diese Dinge im Voraus gekannt, h\u00e4tte ich mir eine Menge wertvoller Zeit und fragw\u00fcrdigen Codes gespart.
\n<\/a><\/noindex>
\nObwohl Sie im Folgenden keinen einzigen Codezeile sehen werden, bin ich dennoch der Meinung, dass alles, was hier gesagt wurde, von gro\u00dfer Bedeutung f\u00fcr das Schreiben von qualitativ hochwertigem, ausdrucksstarkem Code ist. <\/p>\n

Erste Stufe des Verst\u00e4ndnisses: Warum funktioniert es nicht?<\/h4>\n

\nIn der Regel erreichen Entwickler diese Stufe in den fr\u00fchesten Phasen ihrer Karriere, manchmal sogar ohne jegliche Unterst\u00fctzung von au\u00dfen \u2013 zumindest sind das meine Beobachtungen. Stellen Sie sich vor, Sie haben einen Bug-Report erhalten: Eine bestimmte Funktion in der Anwendung funktioniert nicht, sie muss repariert werden. Wie gehen Sie vor?<\/p>\n

Das Standardverfahren sieht folgenderma\u00dfen aus:<\/p>\n

    \n
  1. Den Codeabschnitt finden, der das Problem verursacht (wie das gemacht wird, ist ein eigenes Thema, das ich in meinem Buch \u00fcber veralteten Code behandle)<\/li>\n
  2. \u00c4nderungen an diesem Abschnitt vornehmen<\/li>\n
  3. Sich vergewissern, dass der Bug behoben ist und keine regressiven Fehler aufgetreten sind<\/li>\n<\/ol>\n

    \nLass uns nun auf den zweiten Punkt konzentrieren \u2013 \u00c4nderungen im Code vorzunehmen. Es gibt zwei Ans\u00e4tze f\u00fcr diesen Prozess. Der erste: Verstehen, was im aktuellen Code genau passiert, den Fehler identifizieren und ihn beheben. Der zweite: Auf gut Gl\u00fcck vorgehen \u2013 zum Beispiel +1 in eine Bedingung oder Schleife einf\u00fcgen, sehen, ob die Funktion im vorgesehenen Szenario funktioniert, dann etwas anderes versuchen und so weiter bis in alle Ewigkeit.<\/p>\n

    Der erste Ansatz ist der richtige. Wie Steve McConnell in seinem Buch Code Complete erkl\u00e4rt (\u00fcbrigens kann ich es sehr empfehlen), m\u00fcssen wir jedes Mal, wenn wir etwas im Code \u00e4ndern, in der Lage sein, mit Zuversicht vorherzusagen, wie sich das auf die Anwendung auswirkt. Ich zitiere aus dem Ged\u00e4chtnis, aber wenn ein Bugfix nicht so funktioniert, wie Sie es erwartet haben, sollte Sie dies sehr beunruhigen. Sie sollten Ihren gesamten Handlungsplan in Frage stellen.<\/p>\n

    Zusammenfassend l\u00e4sst sich sagen, dass man, um einen soliden Bugfix durchzuf\u00fchren, der die Codequalit\u00e4t nicht beeintr\u00e4chtigt, sowohl die gesamte Code-Struktur als auch die Quelle des spezifischen Problems verstehen muss.<\/p>\n

    Zweite Verst\u00e4ndnisstufe: Warum funktioniert es?<\/h4>\n

    \nDiese Stufe wird viel weniger intuitiv erfasst als die vorherige. Ich, als noch unerfahrener Entwickler, habe sie durch meinen Chef gelernt und habe sie sp\u00e4ter mehrfach selbst Neulingen erkl\u00e4rt.<\/p>\n

    Stellen wir uns diesmal vor, Sie erhalten gleichzeitig zwei Bugberichte: Im ersten geht es um das Szenario A, im zweiten um das Szenario B. In beiden Szenarien l\u00e4uft etwas schief. Dementsprechend k\u00fcmmern Sie sich zun\u00e4chst um den ersten Bug. Nach den Prinzipien, die wir f\u00fcr die erste Verst\u00e4ndnisstufe abgeleitet haben, tauchen Sie tief in den Code ein, der mit dem Problem zu tun hat, finden heraus, warum er das Verhalten der Anwendung im Szenario A verursacht, und nehmen sinnvolle Anpassungen vor, die genau das Ergebnis liefern, das Sie erwartet haben. Alles l\u00e4uft hervorragend.<\/p>\n

    Dann gehen Sie zum Szenario B \u00fcber. Sie wiederholen das Szenario, um den Fehler zu provozieren, aber \u2013 \u00dcberraschung! \u2013 jetzt funktioniert alles wie gew\u00fcnscht. Um Ihre Vermutung zu best\u00e4tigen, setzen Sie die \u00c4nderungen, die Sie beim Arbeiten an Fehler A gemacht haben, zur\u00fcck, und der Bug B tritt erneut auf. Ihr Bugfix hat beide Probleme gel\u00f6st. Gl\u00fcck gehabt!<\/p>\n

    Sie hatten damit \u00fcberhaupt nicht gerechnet. Sie haben eine M\u00f6glichkeit gefunden, den Fehler im Szenario A zu beheben und haben keine Ahnung, warum dies auch f\u00fcr Szenario B funktioniert hat. In dieser Phase ist die Versuchung gro\u00df zu glauben, dass beide Aufgaben erfolgreich gel\u00f6st wurden. Das ist durchaus logisch: Es ging schlie\u00dflich darum, Fehler zu beseitigen, oder? Aber die Arbeit ist noch nicht abgeschlossen: Sie m\u00fcssen noch herausfinden, warum Ihre Ma\u00dfnahmen den Fehler im Szenario B behoben haben. Warum? Denn m\u00f6glicherweise basiert es auf falschen Prinzipien, und dann m\u00fcssen Sie nach einem anderen Ausweg suchen. Hier sind ein paar Beispiele solcher F\u00e4lle:<\/p>\n