4 Comments

  1. Dummerchen

    Ich fürchte, jeder professionelle SW-Entwickler kennt Spaghetti-Code. Dass man diesen vermeiden sollte, ist vermutlich jeden Entwickler klar, aber „gute“ Gründe finden sich immer wieder, dass dieser entsteht:
    * Es soll „nur mal eben schnell“ noch ein unspezifiziertes Feature eingebaut werden.
    * Es soll der Code des aus der Firma ausgeschiedenen Kollegen von einem Bug befreit werden. Der Kunde drängt auf eine schnelle Lösung. Der Fix ist schnell gemacht – der alte Code aber nicht komplett verstanden worden.

    Weitere Möglichkeiten gibt es sicherlich – zumeist ist das Drängen auf eine Problemlösung ohne die notwendige Zeit die Ursache für die „Quick-and-Dirty“-Lösung. Oder aber der Programmierer ist einfach zu faul. Dann geschieht es ihm recht, wenn er immer wieder Probleme mit dem Code haben wird.

    Ich selbst habe schon Code geerbt, der in Produktsoftware eingesetzt wurde und ziemlich chaotisch war. Über mehrere Monate habe ich diesen von unsinnigen Variablen, parallelen Statemachines und doppelten Initialisierungen befreit. Erschwerend kam dazu, dass es sich um Low-Level-Code im Embedded-Bereich handelte, der sich nicht einfach so schön in Unittests am PC überprüfen ließ, sondern von Hardware-Timings abhing. Meines Erachtens führt kein Weg am Verstehen des Codes und seiner Aufgabe vorbei. Einfach „irgendwie“ den Code zu verwenden, halte ich für optimistisch. Das kann auf Dauer nur schief gehen.

    Am besten, man schreibt direkt sauberen Code (welch Erkenntnis!) – „Code Complete“ und „Nie wieder Bugs“ (beide bezeichnenderweise von Microsoft Press ;-)!) haben mir den Weg dahin gezeigt. Dass man diesen leider nicht immer erbt, ist ärgerlich, aber in der SW-Branche „normal“. Wer noch nie unsauberen Code geschrieben hätte, werfe den ersten Stein.

    Gruß
    Dummerchen

    • mafis90

      Hallo Dummerchen,
      da es hast du wohl reicht. Die beste Lösung wird immer gleich sauberer Code sein.

      Für mich ist das ganze Thema mittlerweile auch weniger ein Code Problem direkt. Der Code ist ja eigentlich nur noch das Mittel am Ende.

      Die Einstellung der Entwickler bzw. der ganze Firma ist wohl das größte Problem bzw. Lösung. Wenn man die richtig setzt, dann kommen wohl viele dieser Probleme gar nicht erst auf. Features vor Fehler lösen ist z.B. eigentlich ein Unding. Wie du schon schreibst.

      Und ja der Code von vor einem Jahr sieht schon wieder echt nicht so schön aus teilweise, also den von mir selbst geschriebenen. Aber auch da ist es für mich auch wieder Einstellungssache z.B. korrigiere ich solche Stellen dann, nach bestem Gewissen. Bessere Lösung gibt es wohl immer noch.

      Microsoft Press muss ich mir wohl mal ansehen.

      Danke,
      mafis

      • Dummerchen

        Ich habe in der ersten Woche in meiner letzten Firma den Satz gehört, der sich jahrelang immer und immer wieder bewahrheitet hat:
        „Wenn Du nicht verstanden hast, warum der Code funktioniert, dann funktioniert er auch nicht!“
        Selbst erlebt und bei Kollegen immer und immer wieder mitbeobachten dürfen. So ist es halt (leider).
        Die Prioritätsfrage „Feature oder Fehler“ ist eigentlich klar: Wer die Fehler nicht sauber behebt, wird sie immer und immer wieder um die Ohren gehauen bekommen. Kunden (in meinem Fall das Automotive-Umfeld) sind da unerbittlich – zurecht! Leider sieht die Projektleitung das nicht immer so und will mit einer möglichst hohen „Feature Complete“-Rate den Kunden zufriedenstellen. Das ist meines Erachtens nach ziemlich problematisch, wenn die Probleme damit immer weiter nach hinten geschoben werden. Je früher die Bugs raus sind, desto besser. Da ist tatsächlich die Firmenphilosophie wichtig. Wenn den Entwicklern keine Zeit für sauberer Lösungen gegeben wird, knallt es halt irgendwann – und die Auslieferung zögert sich dann doch heraus…
        Aber wie Du schon schreibst – auch der Griff an die eigene Nase ist wichtig: Pflege ich meinen Code oder lasse ich Wildwuchs zu?!

        „Code complete“ empfehle ich Dir ausdrücklich. Ein echter Klassiker und in meinem Fall ein Augenöffner bezüglich gutem Code. Die erste Auflage habe ich auf Englisch, die zweite auf Deutsch gelesen. Die amerikanischen Reviews sprechen bei Amazon.com eine deutliche Sprache: http://www.amazon.com/gp/product/0735619670?keywords=code%20complete&qid=1443888424&ref_=sr_1_1&sr=8-1

        (Falls Dir die deutsche Version zu teuer ist (immerhin rund 50€), würde ich mal bei Bookbutler nach der englischen Version suchen. Mit 20€ bist Du aktuell dabei. Gut investiertes Geld!)

        Liebe Grüße
        Dummerchen

        • Das Buch habe ich gleich mal auf die Wunschliste gepackt. Danke und ja englisch sollte reichen 😉

          Den ersten Satz kenne ich wirklich auch zu gut. Nichts anfassen, sonst geht etwas kaputt. Und warum? Ja keine Ahnung, aber läuft so. Erschreckend so etwas eigentlich.

          Im Automobil Bereich ist es natürlich noch alles etwas schlimmer. Obwohl wir eigentlich auch Kunden haben aus der Lebensmittelindustrie und die sind ja auch nicht wirklich nett.

          Die Woche war ich auf der Basta, also Entwicklerkonferenz. Schreibe dazu die Tage auch nochmal ein paar Gedanken. Viel ist da natürlich immer die tolle Welt der Startups,… aber so einige Beiträge von Microsoft und so haben mich schon zum Denken bewegt. Also grade wo das Problem ist.

Kommentar verfassen