Wir haben in letzer Zeit bei TTS öfter mit Tina über die Arbeitsweise von Softwareentwicklern gesprochen und mussten feststellen, dass dieses Thema nur sehr selten besprochen wird und es auch nicht wirklich viel Literatur dazu gibt. Ich kenne keinen Softwareentwickler der sich mit anderen über seine Arbeitsweise unterhält. Denn meistens (und ich bin immer noch geprägt vom letzten devHouse in Köln) tauscht man sich aus über Technologien, Problemlösungen, entdeckte Phänomene von Programmen und anderes Technologiezeugs. Aber Themen wie: wo verliere ich die meiste Zeit beim Entwickeln, wie krieg ich meine 60% Debugging-Aufwand weg, “warum nervt mich das Debugging so” und anderes, sind kaum ein Thema.
Aus diesem Grunde einfach mal hier ein Abbild meiner Gedanken zu dem Thema - festgehalten eigentlich zuallererst für mich, aber auch gern zum Lesen für euch. Einen Anspruch auf Richtigkeit und superdurchdachten Content solltet ihr aber bitte nicht erheben.
Wie ist das wenn ich code?
Was passiert? Irgendjemand - meist der gewogene Kunde - übergibt uns die Spezifikationen für die zu erstellende Software und dann kann es losgehen.
Das erste was ich mache: ich analysiere die Funktionalität und teile diese so in Gruppen ein, dass ich diese einfach in einzelnen unabhängigen Modulen umsetzen kann, welche über definierte Schnittstellen interagieren (z.B. Module). Hierbei gibt es immer folgende Aspekte:
Vor allem der letzte Punkt ist der wichtigste aus meiner Sicht. Unter Beachtung aller Grundsätze der ordnungsgemässen Softwareentwicklung - Wie komme ich mit wenig Aufwand am schnellsten zu meinem Ziel. (Faulheit ist der Motor zu so machem Fortschritt!).
Und gerade bei diesem Nachdenken, diesem Vorrausdenken brauche ich alles nur keinen Rechner. Ich durchdenke in der Situation ganz genau welche Daten und Funktionsströme ich in meiner Software habe. Ich überlege mir, wie ich Exceptions sauber abgefangen bekomme. Ich prüfe an welcher Stelle ich nicht ganz haar genau weiss, wie ich das technisch umsetze (und kläre diesen Unsicherheitspunkt ggf. - denn wenn ich das nicht mache, kann es sein, dass ich alles noch einmal neu entwickle bzw. umbauen muss, was die Software insgesamt instabiler machen wird.).
Wenn ich das hab, wenn ich mir sicher bin - ja, so machst du’s! - dann setze ich mich vor den Rechner, starte die IDE und baue ich mir das Grundgerüst: Sprich, ich erstelle mir die äusseren Hüllen meiner Elemente und definiere die Schnittstellen zwischen diesen und kommentiere alles entsprechend.. Und erst wenn dass alles steht, dann fange ich an die einzelnen Funktionen und Classen herunterzucoden… was dann meist sehr schnell geht und sehr viel Spass machen kann. Aber auch dabei gilt: Comment first!
Wichtig hierzu ist noch, dass sich der selbe Prozess für alle kleineren Teilelemente meiner Aufgabe wiederholt. Sprich für meine Klasse, für meine Funktion gehe ich vollkommen identisch vor - immer bis ich ganz genau weiss, wie es funktionieren soll und wie ich das code.
Ich will hier nochmal herausstreichen, dass coden für mich vor allem bedeutet: das Ab- und Erwägen von verschiedensten Realisationsmöglichkeiten, das creative Evaluieren von Pro- und Contra von möglichen Code-Strukturen mit Hinblick auf Aspekte wie: Serverlast, Fehleranfälligkeit, Verständlichkeit der Einheiten, Flexibilität der Interfaces, Einsparen von doppelten Code (meint nicht Kopien von Code, sondern Code mit identischer Funktionalität), bestmögliche Test- und Debugbarkeit und und und… das ist die wahre Herausforderung für mich und nicht das Heruntertippen von kyrillischen Zeichen, die nur Rechner lesen können…
This entry was posted on Monday, July 30th, 2007 at 10:42 pm and is filed under Coding, Foggy Thoughts. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.