Avatar von hortensio
  • hortensio

mehr als 1000 Beiträge seit 24.01.2010

mehrere Iterationen notwendig

Wenn ich etwas umsetzen soll, überlege ich mir in welche Teilaufgaben/ Module ich das Problem zerlegen will. Zu dem Zeitpunkt ist das eher noch auf einem gröberen Level, so dass nicht immer der Funktionsumfang oder die Datenstrukturen ausreichend definiert sind.

Beim Umsetzen der einzelen Teilaufgaben/ Module kristallisieren sich dann langsam die Details heraus. An dieser Stelle nutze ich gerne Interfaces für etwas was erst später umgesetzt wird. Wenn sich an einer Stelle etwas konkretisiert muss u.U. an anderer Stelle nachgebessert werden. Wenn Softwarebausteine integriert werden müssen, erkennt man auch wieder was nicht ganz zusammenpasst.

Ich versuche mich an gewissen "Best Practices" zu orientieren (z.B. Clean Code, TDD, etc.). Allerdings halte ich mich nicht immer sklavisch daran. Ganz ohne Kommentare geht es leider auch nicht, denn nicht immer finde ich auf Anhieb sprechende Klassen- und Variablennamen. I.d.R. benötige ich mehrere Iterationen bis ich mit den Datenstrukturen, dem Code und dem Zuschnitt der Softwarebausteine zufrieden bin.

Persönlich ist es mir lieber wenn im Code explizit zu lesen ist was definiert ist und was passieren soll. Abkürzungen in Klassen- und Variablennamen versuche ich zu vermeiden weil diese nach langer Zeit zu einem Problem werden können. Verschachtelte Schleifenkonstrukte versuche ich durch Auslagerung lesbar zu halten. Generell versuche ich zu großen Codeblöcke zu vermeiden.

Was mir besonders fehlt sind Reviews durch einen anderen Entwickler. Daher nutze ich entsprechende Analysetools mit den aktuell gängigen Regeln für die jeweilige Progammiersprache.

Da ich den eigenen Code eh in regelmäßigen Zeitabständen neu anpacken muss, nehme ich mir dann die Zeit um in kleinen Schritten den Code aufzuräumen, ggfs. umzustruktierieren, eigene Libraries zu pflegen und Libraries von Dritten aktuell halten.

Letztendlich ist das ganze ein mehr oder weniger regelmäßiger Prozess. Wenn zu viel Zeit vergeht, brauche ich auch für den eigenen Code eine technische Dokumentation zu den Konzepten und eine Übersicht der Softwaremodule und wie diese zusammenspielen. Oft reichen wenige Skizzen mit entsprechendem Abstraktionsgrad. Auf Codeebene komme ich leider noch nicht ohne Kommentare aus.

Der Code wird zwar objektiv mit der Zeit zwar langsam besser (z.B. durch Abbau von technischen Schulden) oder zumindest nicht schlechter, aber ob er für andere dadurch leichter zu lesen ist, ist die große Frage. Unterschiedliche Personen denken anders und strukturieren Aufgaben/ Probleme anders.

Bewerten
- +