BlogKontaktTagcloud

Endlich gelesen: The Pragmatic Programmer

"The Pragmatic Programmer" sollte für jeden der mit Software Entwicklung zu tun hat Pflichtstoff werden. Warum ich so lang gehabt habe um dieses Buch zu lesen kann ich mir nur damit erklären das ich denn grössten Teil des Inhalts schon in Vorlesungen und in einem Vortrag von Andy Hunt gehört habe. Die Zusammenfassung des Vortrags, der einen grossen Teil des Buchs abdeckt, findet man in meinem Blog (Teil1, Teil2).

Andy Hunt und Dave Thomas erklären auf nur knapp mehr als 250 Seiten alle wichtigen Paradigmas der modernen Software Entwicklung. Bei so wenig Seiten kann natürlich nicht immer ins Detail gegangen werden, gewisse Themen werden nur angeschnitten und müssen bei Interesse weiter vertieft werden.

Die Tipps wie man ein Projekt zu einem erfolgreichen Abschluss führen kann sind absolut unverzichtbar. "The Pragmatic Programmer" muss man einfach gelesen haben.

Mein nächstes Buch aus dieser Reihe wird, sobald ich es von Mirko endlich bekomme, "My Job went to Serbia India".
Ähnliche Beiträge:
Lesen: iWoz
Gelesen: Afghanische Reise
Buch: Computerlogik
Trockener Code
Pragmatic programming with Andy Hunt (Teil II)
Comments (1)  Permalink

Don’t live With Broken Windows

Die "Don’t live With Broken Windows"-Theorie wurde von Andy Hunt in dem Buch "The pragmatic programmer" aufgegriffen. Die Theorie beschreibt dabei das an einem Ort mit einer kleinen Defekt oder einer kleinen Verunstalltung bald grosses Chaos und Zerstörung herscht. Andy Hunt übertragt diese Theorie die Ursprünglich von der New Yorker Polizei stamm gekonnt in die Welt der Programmierung.

Roli und ich haben nun letztlich herausgefunden das sich dieses Beispiel ebenso gut auf die Ordnung übertragen lässt. Beim Besuch in der Pfarri Herrliberg war an einigen Orten bereits wieder eine riesen Unordung ausgebrochen, ganz nach der "Don’t live With Broken Windows"-Thorie ist überall wo bereits Unordnung herscht die Versuchung gross noch mehr Unordnung zu produzieren und die Lust wieder Ordnung zu machen wird somit immer kleiner.

Für alle die das "The pragmatic programmer"-Buch nicht haben hier noch das Zitat: "broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality.The "Broken Window Theory" has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out
the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level."
Ähnliche Beiträge:
Endlich gelesen: The Pragmatic Programmer
Trockener Code
Pragmatic programming with Andy Hunt (Teil II)
Pragmatic programming with Andy Hunt
Comments (0)  Permalink

Trockener Code

Code muss trocken sein!

Ganz einfach weil er sonst beginnt zu stinken. Trockener Code ist die, nicht ganz korrekte, Übersetzung von "DRY Code", wobei DRY als Abkürzung für Programmierparadigma "Don't repeat yourself" steht. Würden sich alle daran halten hät es den Millenium-Bug nie gegeben (naja, gegeben hätte es ihn wohl schon. Aber wir hätten ihn auf einer Zeile behoben) und Software Engineering währe einiges einfacher.

Warum ich darauf komme? Ganz einfach! Weil ich mich in letzter Zeit wieder viel zu häufig mit nassem und triefendem Code abgeben musst. Repräsentatives Beispiel ist dabei die Applikation WikkiTikkiTavi, die ansonsten eine ganz tolles Wiki ist, ein wenig Vertrauenswürdiger als unser Schulwiki, da sie an mehr Orten eingesetzt wird, und wesentlich weniger kompliziert als Mediawiki , welches meiner Meinung nach gar nicht WikkiWikki ist.

Das besagte WikkiTikkiTavi hatte ich letztlich auf meiner Seite installiert. Irgendwann hat Mirko bemerkt das die Datumsangaben an einigen Stellen falsch sind, aber nicht an allen. Das Problem wurde dann mit ein wenig Glück bei Google gefunden und die Lösung gleich dazu.

  $time = mktime(substr($timestamp, 8, 2),  substr($timestamp, 10, 2),
substr($timestamp, 12, 2), substr($timestamp, 4, 2),
substr($timestamp, 6, 2), substr($timestamp, 0, 4));
Dieses Stück Code scheint nicht nur bei einigen Mysql-Versionen nicht zu funktioniere. Zudem war dieser Code, ganz untrocken, über die ganze Applikation verteilt und kopiert worden. So war an einigen Stellen bereits ein Workaround in die aktuelle Version eingeflossen an anderen liess man da ganze aber stehen.

Schlimm dabei ist nicht nur das dieser, fehlerhafte, Code über die ganze Anwendung verteilt wurde sondern auch das man das ganze mit
  $time = strtotime($timestamp);
oder mit
SELECT UNIX_TIMESTAMP(time);
in SQL viel einfacher und robuster hätte haben können, wenn man die Funktionen der Programmiersprache oder der darunterliegenden Schicht verwendet hätte.

Es gilt darum zwei Grundsätze einzuhalten: Eine Aufgabe wird nur von einem Stück Code erledigt und der Entwickler der Programmiersprache, der Libary oder der darunterliegenden Schicht schreibt immer besserer Code als ich, darum nutze ich diesen und schreib keinen eigenen. Wenn ich dann noch Unittests für meinen Code schreibe kann fast nichts mehr schief gehen.
Ähnliche Beiträge:
Endlich gelesen: The Pragmatic Programmer
Pragmatic programming with Andy Hunt (Teil II)
Pragmatic programming with Andy Hunt
Mobile App Hackathon
Make it human (or how to crack a CAPTCHA)
Comments (0)  Permalink

Pragmatic programming with Andy Hunt (Teil II)

Und weiter...

...gehts hier. Ich musste diesen Eintrag aufspliten da sonst mein Schlafmanagement durcheinander gekommen währe (und das soll vor Prüfungen nicht so toll sein). Der erste Teil meiner Zusammenfassung zum Fortbildungsseminar 'Pragmatic Programming - Overview!' habe ich noch am Dienstag-Abend geschrieben, hier folgt nun der zweite Teil.

Infrastucture

Den Teil Infrastructure teilte Andy Hunt wieder in drei Kapitel ein, nämlich "Use version Controlling", "Unit Testing". Für die Anwesenden wahr Version Controlling kein Fremdwort, leider scheint diese Praxis in der Industrie immr noch keine vollständige Verbreitung zu finden. Das wirklich alles ins VC-System gehört geht oft vergessen, oft gibt es kleine Scripts (für den Build, die Installation) die so plötzlich verlohren gehen und kein Mensch weiss danach mehr wie man diesen Arbeitsschritt wieder automatisieren kann.

Unit Testing war dann bei weitem nicht so verbreitet. Oft wird der Aufwand für das schreiben des Tests gescheut. Andy Hunt fand jedoch das die Disziplin beim Unit Testing den Code einfacher macht und das Design verbessert.

"Automate everything" löste dann einiges stauenen aus. Jede Stunde eine lauffähige neue Version auf CD gepresst und beschrifftet und das Resultat des Unittests auf einer Lava Lampe ist cool wie nichts. Bei unserem letztem Projekt waren wir aber mit der Hilfe von CruiseControll beinahe schon auf diesem Stand und desshalb erstaunte mich diese Kapitel nicht so sehr wie andere.

Team Practices

Die Kommunikation ist eines der wohl am meisten unterschätzten Themen im Software Engeneering. Die Kommunikation sollte ehrlich und verlustfrei sein, sowie möglichst effizient sein. Dabei brachte er auch das Beispiel das man mal den Kopf ins andere Büro stecken soll anstelle ein eMail zu schreiben. Etwas was ich persönlich feststelle immer wieder nützlich ist. Oft erreicht man durch einen kurzen Fussmarsch ins nächste Büro viel mehr als durch ein eMail ping-pong, gleichzeitig tut man etwas für seine Gesundheit und lernt sich automatisch besser kennen.

Schnelle und effiziente Kommunikation kann man laut Andy Hunt durch folgendes erreichen:
  • Gespräche, keine Memos
  • Klarheit, nicht Erklährung
  • Wikis, keine Dokumentreviewsitzungen
  • Standup meetings, nicht Status-Memos
Auf das Standup Meeting ging er dann noch ein bischen weiter ein. Beim Standupmeeting stehen (es ist wichtig das sie stehen, wer nicht sitzt macht automatisch schneller) alle in einem Kreis. Jeder beantwortet drei Fragen:
  • Was habe ich gestern erfüllt?
  • Was planne ich heute zu machen?
  • Was steht in meinem Weg diese zu tuen?
Diese drei Fragen, sonst nichts! Nach dem Meeting kann man an diese Punkte sofern nötig anknüpfen.

Zur Organisation meinte er das man das Team wie den Code organisieren soll (und nicht etwa umgekehrt), keine unnötige Zwischenebenen einschieben soll und den Fokus auf die Kommunikation legen soll.  Intressant war auch  die Geschichte von den Entwickler die in einer Reihe an der Fensterfront arbeiteten. Der Äusserste auf einer Seite erklährte das dass Team einen grossen Server mit einem Thin Client implementiert, jeweiter man nun auf die andere Seite der Tische ging wurde der Server immer einfacher und der Client immer Dicker. Bis am anderen Ende der Tischreihe der Entwickler erklährte das dass Team einen Fat Client mit einem einfachen DB-Server entwickle!

Anforderungen wechseln sich immer. Auch wenn die Anforderungsspezifikation säuberst erarbeitet sind, haben sie pro Monat eine Änderung von gut zwei Prozent. Desshalb ist ein gutes Ausfragen des Kunden (aus meiner Erfahrung: Der Kunde weiss nie was er will) und ein gut änderbares Entwicklungsmodel unumgänglich.

Durch kürzere Iterationen erreicht man besseres Feedback, keine lange nicht gefixte Bugs (Broken-Windows),  kann entscheidungen verschieben, vereinfacht die Kommunikation und man lernt dauernd. Das mit dem Feedback und der vereinfachten Kommunikation wird wohl am besten durch das Beispiel unterstützt in welchem eine Firma ein POS-System entwickelt und erst merkt das die Benutzer sich (Aufgrund von Analphabetismus!)  nicht einmal einloggen können!

Kurze Iterationen fördern also vorallem schnelles Feedback und dauerndes Lernen!

Zum Schluss

Wie schon mal erwähnt, der Vortrag bot wenig neues (für uns Studenten welche pragmatisches Programmieren durch Mister Sommerlad schon bald ein Jahr eingetrichtert bekommen). Vorgetragen waren das ganze aber genial und mit vielen Praxisbeispielen untermauert. Schlussendlich ist es wohl auch wichtig das man all diese Punkte immer wieder aufgedrückt bekommt.

Was ich aus dem Vortrag mitnehme ist das das Wichtigste in Software Projekten (und wohl auch allen anderen) dauerndes Lernen und gutes Kommunizieren ist.
Ähnliche Beiträge:
Pragmatic programming with Andy Hunt
Endlich gelesen: The Pragmatic Programmer
Trockener Code
Mobile App Hackathon
Make it human (or how to crack a CAPTCHA)
Comments (0)  Permalink

Pragmatic programming with Andy Hunt

Heute Abend hat Andy Hunt bevor er an die Software Trends in Gersau reist auf Einladung des Institut für Software und der Weiterbildungsstelle noch einen kleinen Abstecher an unsere Schule gemacht.

Wirklich überaschend war die Präsentation nicht, pragmatisches Programmieren gehört heute ja zum Stoffplan einer moderen Hochschule. Denn noch sollte eine regelmässige Portion Pragmatik Pflicht für jeden Programmierer sein. Andy Hunt hat in 90 Minuten die präzis die wichtigsten Punkte angeschnitten.

Nach einer kurzen Einleitung in dem er nochmals auf die grässlichen Zustand von Softwareprojekten einging und einige Zahlen dazu prässentierte. Die Zahlen hatten allerdings keine Quelle und irgendwie war das für mich alles ein wenig aus der Luft gegriffen, im grundsatzt aber sicher richtig. Ging er dann auf die Themen "Personal Practices", "Design Practices", "Team Practices" und "Infrastructure" ein.

Personal Practices

Bei den "Personal Practices"  ging er zuerst auf die Wichtigkeit des Lernen ein. Wöchentlich sollte jeder 2 Stunden in die persönliche Weiterbildung stecken um sein Knowledge Profil zu erweitern. Schlussendlich fand ich auch noch wichtig das er dabei betonte das man klar diversifizieren sollte, eventuell kommt die Technik auf die man hofft dann doch nicht so wie man damit rechnet.

Die Wichtigkeit der Wachsamkeit beim Programmieren erklärte er am Beispiel eines Frosches. Hält man einen Frosch ins heisse Wasser springt er sofort wieder raus, gibt man hingegen in kaltes Wasser und dreht die Temperatur langsam auf wird er ohne es zu merken kochen. Sicher waren wird schon alle mal in der Situation wo wir das warm werden des Wassers erst merkten als es schon (fast) kochte. Um klippen zu erkennen hilft natürlich aktives und unmittelbares Feedback, haben wir das nicht kann es uns wie der Lady gehen die mit dem Messer im Nacken eine Shopping-Tour sellenruhig zu Ende führt. Darum sollte man sich nach Andys Empfehlung beim Programmieren etwa alle 2 Stunden selber fragen. "Warum mache ich das?", "Muss ich das so machen?" und "Muss man das überhaupt machen?". Dabei immer an den Frosch denken und überprüfen ob sich das Wasser nicht erhitzt.

Unter dem Titel "Fix Broken Windows" erklährte er dann die Wichtigkeit eine eingeschlagene Scheibe ebenso wie einen Bug sofort zu reparieren. Und wenn man es nicht reparieren kann sollte man es wenigstens markieren. Das das mit dem später nicht ganz einfach ist steht gross auf einer Folie: "There is no later...". Das Design soll durch Refactoring angepasst werden. Man sollte sich dabei nicht so stark auf die Pläne festschreiben wie beim Hausbau, sondern es eher wie beim Garten planen handhaben oder eben: "Keep software soft!"

Design Practices

"Design Pratices" bot dann relativ wenig neues, das meiste hatten wir in den Software Engineering Fächern bereits. Als wohl oberstes Gebot legten wir mit DRY (Don't reapeat yourself) los und Andy stellte fest das dass kopieren von Code mit dem kopieren von Fehlern gleichgesetzt werden kann. Die Magic Numbers sind heute vielfach Magic Strings gewichen. Weiter gings mit Coupling und High Cohesion, was wenig Überaschungen bot.

Weiter...

Gehts ein anderes mal, ich wollte diesen Teil aber jetzt erst mal veröffentlichen damit wenigstens scho was online ist.

Ähnliche Beiträge:
Pragmatic programming with Andy Hunt (Teil II)
Endlich gelesen: The Pragmatic Programmer
Trockener Code
Mobile App Hackathon
Make it human (or how to crack a CAPTCHA)
Comments (2)  Permalink
1-5/5