Think First Development

Team Foundation Server 2010 ist eine interessante Weiterentwicklung des Team Foundation Servers 2008. Da möchte man gerne mit dem “alten” Visual Studio 2008 diesen benutzen. Das geht auch, wenn man zum Visual Studio mit Team Explorer folgendes installiert:

1. Visual Studio 2008 SP1 (hier)
2. Hotfix für TFS 2010 (hier)

Nun gibt es nur noch eine Sache zu berücksichtigen, die mich mehrere Stunden gekostet hat: Der Team Explorer 2008 kann nicht mit Team Project Collections umgehen. Also muss zum einen die URL vollständig angegeben werden und zusätzlich der Name der Team Project Collection angehängt werden.

Visual Studio 2008 Konfiguration

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.