{"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\/novosti-interneta\/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 als Teamleiter \/ Chefentwickler \/ leitender Entwickler t\u00e4tig \u2013 nennen Sie es, wie Sie m\u00f6chten, aber der Kern der Sache ist, dass ich die volle Verantwortung f\u00fcr eines der Module und alle Entwickler, die daran arbeiten, trage. 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 Entscheidungen teilnehme. K\u00fcrzlich habe ich, dank dieser beiden Umst\u00e4nde, unerwartet erkannt, wie stark das Ma\u00df an Verst\u00e4ndnis den Code und die Anwendung beeinflusst.<\/p>\n

Der Gedanke, den ich ausdr\u00fccken m\u00f6chte, ist, dass die Qualit\u00e4t des Codes (und des Endprodukts) eng damit verbunden ist, wie gut die Menschen, die das Design \u00fcbernehmen und den Code schreiben, sich bewusst sind, was sie tats\u00e4chlich tun.<\/p>\n

Vielleicht denken Sie jetzt: \"Danke, Kapit\u00e4n. Nat\u00fcrlich w\u00e4re es gut zu verstehen, was man da eigentlich schreibt. Sonst k\u00f6nnte man genauso gut eine Gruppe Affen engagieren, die zuf\u00e4llig auf die Tasten haut, und sich damit zufrieden geben.\" Und Sie haben vollkommen recht. Daher gehe ich davon aus, dass Sie sich dessen bewusst sind, dass es unerl\u00e4sslich ist, eine grundlegende Vorstellung davon zu haben, was man tut. Dies k\u00f6nnte man als Basisverst\u00e4ndnis bezeichnen, und wir werden es nicht im Detail er\u00f6rtern. Stattdessen werden wir uns damit besch\u00e4ftigen, was genau verstanden werden muss und wie es sich auf die Entscheidungen auswirkt, die Sie t\u00e4glich treffen. H\u00e4tte ich diese Dinge im Voraus gewusst, h\u00e4tte ich mir viel Zeit und fragw\u00fcrdigen Code erspart.
\n<\/a><\/noindex>
\nObwohl Sie hier unten keinen einzigen Code-Zeilen sehen werden, halte ich dennoch alles, was hier gesagt wird, f\u00fcr sehr wichtig, um qualitativ hochwertigen, ausdrucksstarken Code zu schreiben. <\/p>\n

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

\nEntwickler erreichen dieses Niveau oft sehr fr\u00fch in ihrer Karriere, manchmal sogar ohne jegliche Unterst\u00fctzung von au\u00dfen \u2013 zumindest ist das meine Beobachtung. Stellen Sie sich vor, Sie erhalten einen Bug-Report: Eine Funktion in der Anwendung funktioniert nicht, sie muss repariert werden. Wie w\u00fcrden Sie vorgehen?<\/p>\n

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

    \n
  1. Finden Sie den Codeausschnitt, der das Problem verursacht (wie das geschieht, ist ein separates Thema, das ich in meinem Buch \u00fcber veralteten Code behandle)<\/li>\n
  2. \u00c4nderungen in diesen Codeausschnitt vornehmen<\/li>\n
  3. Sicherstellen, dass der Bug behoben ist und keine regressiven Fehler aufgetreten sind<\/li>\n<\/ol>\n

    \nJetzt konzentrieren wir uns auf den zweiten Punkt \u2013 die \u00c4nderungen im Code vorzunehmen. Es gibt zwei Ans\u00e4tze f\u00fcr diesen Prozess. Der erste: Verstehen, was genau im aktuellen Code passiert, den Fehler identifizieren und beheben. Der zweite: Auf gut Gl\u00fcck vorgehen \u2013 zum Beispiel +1 in eine Bedingung oder Schleife einf\u00fcgen, pr\u00fcfen, ob die Funktion im gew\u00fcnschten Szenario nun funktioniert, dann noch etwas ausprobieren 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), sollten wir jedes Mal, wenn wir etwas im Code \u00e4ndern, in der Lage sein, zuverl\u00e4ssig vorherzusagen, wie sich dies auf die Anwendung auswirkt. Ich zitiere aus dem Ged\u00e4chtnis, aber wenn ein Bugfix nicht wie erwartet funktioniert, sollte Sie das ernsthaft alarmieren und 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 verschlechtert, sowohl die gesamte Struktur des Codes als auch die Quelle des spezifischen Problems verstehen muss.<\/p>\n

    Die zweite Ebene des Verst\u00e4ndnisses: Warum funktioniert es?<\/h4>\n

    \nDiese Ebene wird viel weniger intuitiv erfasst als die vorherige. Ich habe sie als noch unerfahrener Entwickler von meinem Chef gelernt und habe sie anschlie\u00dfend oft selbst Neulingen erkl\u00e4rt.<\/p>\n

    Stellen Sie sich vor, Sie erhalten gleichzeitig zwei Fehlerberichte: Der erste betrifft Szenario A, der zweite Szenario B. In beiden Szenarien l\u00e4uft etwas schief. Daher k\u00fcmmern Sie sich zuerst um den ersten Fehler. In Anlehnung an die Prinzipien, die wir f\u00fcr das erste Verst\u00e4ndnislevel aufgestellt haben, vertiefen Sie sich gr\u00fcndlich in den Code, der mit dem Problem zusammenh\u00e4ngt, und kl\u00e4ren, warum er das Verhalten der Anwendung in Szenario A beeinflusst. Schlie\u00dflich nehmen Sie sinnvolle Anpassungen vor, die genau das gew\u00fcnschte Ergebnis liefern. Alles l\u00e4uft bestens.<\/p>\n

    Dann wechseln Sie zum Szenario B. Sie wiederholen das Szenario, um den Fehler auszul\u00f6sen, aber \u2014 \u00dcberraschung! \u2014 jetzt funktioniert alles wie geplant. Um Ihre Vermutung zu best\u00e4tigen, setzen Sie die \u00c4nderungen zur\u00fcck, die Sie bei der Fehlerbearbeitung von A vorgenommen haben, und Fehler B tritt wieder auf. Ihr Bugfix hat beide Probleme gel\u00f6st. Wie praktisch!<\/p>\n

    Darauf haben Sie noch nie gerechnet. Sie haben einen Weg gefunden, um den Fehler im Szenario A zu beheben, und haben keine Ahnung, warum das auch im Szenario B funktioniert hat. An diesem Punkt liegt die Versuchung nahe zu denken, dass beide Probleme erfolgreich gel\u00f6st sind. Das erscheint logisch, denn das Ziel war schlie\u00dflich, die Fehler zu beheben, 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? Weil es sein k\u00f6nnte, dass es auf falschen Prinzipien basiert, und dann m\u00fcssen Sie nach einer anderen L\u00f6sung suchen. Hier sind einige Beispiele daf\u00fcr:<\/p>\n