Think First Development

Schon einmal einen Programmierer sagen hören “Diese neue Technologie ist cool. Die sollten wir einsetzen”. Hört man auf den Programmierer und setzt die Technologie einfach ein? Wie ist das denn wenn der Kunde sagt “Diese neue Technologie ist cool. Die solltet ihr einsetzen”. Sollte man die Technologie jetzt einsetzen? Neue Technologien bieten auch neue Chancen für das Produkt und neue Motivation für Entwickler.

Der erste Schritt liegt auf der Hand. Mittels eines Proof Of Concept wird die neue Technologie getestet und verifiziert, ob die Technologie zur Architektur passt. Aber wie geht es weiter? Die folgenden fünf Fragen geben eine Entscheidungshilfe für die Entscheidung.

• Erfüllt die Technologie die Anforderungen an die Architektur?
• Will der Kunde diese Technologie haben?
• Wollen die Entwickler diese Technologie einsetzen?
• Wie groß ist der Einfluss der Technologie auf den bestehenden Code?
• Wie leicht lässt sich diese Technologie bei einer Fehlauswahl wieder entfernen?

Zu guter letzt muss wieder der Architekt entscheiden, aber doch bitte bewusst und nach objektiven Kriterien und nicht nach Bauchgefühl.

Heute wurde ich von einem Kollegen gebeten, aus meiner Sicht die 10 wichtigsten Regeln zum Programmieren aufzuschreiben. Diese Regeln sollen Programmierern helfen, besser und schneller stabilen Code zu programmieren. Hier sind meine 10 wichtigsten Regeln aus meiner heutigen Sicht.

Zeit für Sauberkeit. Wenn du etwas machst, mache es direkt ordentlich. Später wirst du keine Lust zum Aufräumen haben. Wer hat schon Lust tausende Zeilen von Code nachträglich zu kommentieren und aufzuräumen.

Geh’ in kleinen Schritten. Definiere genau dein Ziel und teile es sinnvoll in möglichst kleine Schritte ein. Gestalte erst ein Formular und schreibe anschließend die Logik. Programmier die Logik in kleinen aber abgeschlossenen Schritten und nicht alles auf einmal.

Erst denken, dann programmieren. Wenn du nicht in der Lage bist, dein Programm auf Papier zu formulieren, wirst du es erst recht nicht schaffen, dieses dann in Code umzusetzen.

Buy it, don’t make it. Bevor du ein Modul programmierst, überlege ob es nicht bereits etwas Fertiges auf dem Markt gibt. Goggle ist dein Orakel: Frag was du suchst und Google wird dir mit OpenSource und kommerziellen Projekten antworten…ganz sicher!

Fragen kostet nix. Es gibt immer jemanden, den man fragen kann. Also wenn du dir mit irgend etwas nicht sicher bist frag nach. 10 Minuten fragen bringt dich weiter als 3 Stunden ‘try and error’.

Halte dich an Coding Guidelines. Coding Guidelines dienen dem allgemeinen Verständnis von Code. Jede Programmiersprache hat ein grundsätzliches Verständnis von “schönem Code”. Halte dich daran. Falls es in deinem Projekt keine Coding Guidelines gibt berufe dich auf allgemein gültige Regeln.

Code muss verständlich sein-für alle. Du entwickelst zwar den Code, aber normalerweise mit anderen zusammen oder andere übernehmen unter Umständen deinen Code. Jeder muss verstehen können was du gemacht hast und warum du es gemacht hast. Sogar du musst noch nach Monaten oder Jahren den Code warten und erweitern können. Und bedenke immer: Je mehr du dokumentierst und deinen Code verständlich programmierst, umso weniger (blöde) Fragen muss man zum Code beantworten.

Logging nicht vergessen. Du musst jederzeit die Möglichkeit haben, dein Programm auch nach der Auslieferung (intern fürs Testen oder beim Kunden in Produktion) verfolgen und debuggen zu können. Fehler müssen immer Persistiert werden. Das erste was der Anwender vergessen hat ist, was er gemacht hat und wie die Fehlermeldung lautete.

Testen, testen, testen. Jeder würde jetzt schreiben, “Unit Testes sind das wichtigste” oder “Test Driven Development ist essentiell”. Es ist viel wichtiger, dass du Bestandteile deiner Applikation isoliert testen und dabei alle Variationen verifizieren kannst. Und wenn es nur eine Test-GUI ist, ist es immerhin ein Test und besser als nichts. (@Stefan Lieser: Sorry )

Mehrmals täglich einchecken. Wenn du kleine Arbeitspäckchen schnürst, kannst du auch mehrmals täglich diese nach dem Implementieren einchecken. Spätestens aber wenn du abends nach Hause gehst. Wichtig sind folgende Punkte für ein gutes und sicheres Einchecken:

• Code zuerst aktualisieren und kompilieren und erst dann einchecken.
• Nur kompilierbaren Code einchecken.
• Immer einen Kommentar für das Einchecken angeben.
• Immer mit einem personalisierten Benutzerkonto Code einchecken.