In meinem ersten Book Review möchte ich das Buch "The Clean Coder" von Robert C. Martin vorstellen. Ihr findet den Link zum passenden Amazon Artikel in meiner Buchliste unter Nummer 2.
In dem Buch beschreibt Robert C. Martin was für ihn einen "professional programmer" ausmacht. Er beginnt mit einem Erlebnis und zeigt dann Stück für Stück professionelle Verhaltensweisen auf, indem er zunächst das unprofessionelle Gegenteil vorstellt um an diesem zu Erläutern was eben daran unprofessionell ist und wie man es besser macht. So stellt er schrittweise Verhaltensregeln für professionelle Programmierer auf.
Ich habe eigentlich nichts erwartet als ich dieses Buch zur Hand nahm. Ich dachte mir "mal schauen was da drin steht" und wurde nur begeistert. Robert C. Martin lese ich sehr gerne, da seine Art zu schreiben selbst die trockene Theorie anschaulich und witzig darstellt und so den Stoff leicht zugänglich macht. Auch das hat er in "The Clean Coder" wieder unter Beweis gestellt. Witzig führt er durch viele Situationen die ein jeder Programmierer garantiert schon erlebt hat. Seine Charaktere sind sehr stereotypisch und treffen dennoch sehr die Realität. Der Chef, der eigentlich keine Ahnung vom Programmieren hat und nur will dass das Projekt schnell fertig wird, trifft auf den 08/15 Entwickler der zu jeder noch so dämlichen Anforderung "Ja" und "Amen" sagt und gerne Überstunden in Kauf nimmt um eine unrealistische, utopische Deadline, die er selber nicht mitbestimmen durfte einzuhalten. Das mag sehr überzogen klingen aber genau das ist die Grundlage dieses Buches die es Uncle Bob erlaubt anschaulich "falsche" und "richtige" Verhaltensweisen aufzuzeigen und verständlich zu machen.
Nachdem man dieses Buch gelesen hat will man es am liebsten allen in den Kopf prügeln. Wenn der Chef mal wieder ankommt und eine utopische Deadline vorgibt möchte man ihm am liebsten sagen "Hier lies dieses Buch danach reden wir weiter". Dieses Buch kann die Arbeitswelt (und zwar nicht nur in der Softwareentwicklung) verändern, wenn sich jeder danach richten würde wäre die Welt unkomplizierter und verständnisvoller.
Meine Empfehlung könnt ihr euch nun vermutlich schon denken: Dieses Buch ist ein MUST-READ für jedermann.
Freitag, 21. Juni 2013
Leserlicher Code ist wichtig
Dass leserlicher Code wichtig ist wissen wir. Zumeist kommen, wenn man nach einer Begründung fragt, Argumente wie "Wenn der Code nicht leserlich ist fällt es einem schwer den Code zu warten" oder "Nicht leserlicher Code macht die Fehlersuche schwierig" und und und.
Ein Grund für leserlichen Code wird aber zumeist vernachlässigt: Er macht es schlicht und ergreifend einfacher den Code zu lesen! Nur wenn Code leserlich ist kann er einfach gelesen werden und nur wenn Code gelesen werden kann, kann er auch verstanden werden.
Das ist jetzt vermutlich auch nichts neues, also weshalb fand ich es wichtig darüber zu schreiben? Ganz einfach weil es mir gerade jetzt so richtig bewusst geworden ist. Ja gewusst habe ich das schon "immer", aber dennoch neigt man dazu Code eben nicht leserlich zu halten. Man implementiert ihn so wie es einem gerade passt. Gliedert Methoden aus oder eben nicht. Nennt diese wie es einem gerade sinnvoll erscheint. Erscheint.... eben das ist das Problem! Ist man in der Materie drin denk man sich vieles dazu und vieles scheint eben klar und nicht erklärungsbedürftig. Man kennt den Kontext und weiß worum es geht und genau das hindert uns daran immer leserlich zu schreiben. Es macht einem auch nicht nur selber das Leben schwer, sondern auch Anderen. Ja, unleserlicher Code ist schlecht wartbar, weil man ihn versteht. Ja, unleserlicher Code macht die Fehlersuche schwer, weil man ihn nicht versteht. Ja, unleserlicher Code macht es anderen schwer ins Projekt einzusteigen, weil man ihn nicht versteht. Es läuft also alles aufs gleiche hinaus. Unleserlicher Code ist unverständlich!
Deswegen mein Apell an alle: Geht Quellcode des öfteren durch und nicht nur wenn ihr etwas ändern müsst/wollt. Lest einen Tag später nochmal drüber und ändert die Namen wenn sie nicht eindeutig sind, gliedert Methoden aus, wenn das dem Verständnis hilft. Refaktoriert was das Zeug hält um euren Code vom Vortag "aufzuhübschen". Ich jedenfalls werde mir genau dies angewöhnen. Morgens als erstes ein Selbsreview durchzuführen. Natürlich wird der Code so nicht perfekt aber besser und das ist mein Ziel: Besser zu werden.
Ein Grund für leserlichen Code wird aber zumeist vernachlässigt: Er macht es schlicht und ergreifend einfacher den Code zu lesen! Nur wenn Code leserlich ist kann er einfach gelesen werden und nur wenn Code gelesen werden kann, kann er auch verstanden werden.
Das ist jetzt vermutlich auch nichts neues, also weshalb fand ich es wichtig darüber zu schreiben? Ganz einfach weil es mir gerade jetzt so richtig bewusst geworden ist. Ja gewusst habe ich das schon "immer", aber dennoch neigt man dazu Code eben nicht leserlich zu halten. Man implementiert ihn so wie es einem gerade passt. Gliedert Methoden aus oder eben nicht. Nennt diese wie es einem gerade sinnvoll erscheint. Erscheint.... eben das ist das Problem! Ist man in der Materie drin denk man sich vieles dazu und vieles scheint eben klar und nicht erklärungsbedürftig. Man kennt den Kontext und weiß worum es geht und genau das hindert uns daran immer leserlich zu schreiben. Es macht einem auch nicht nur selber das Leben schwer, sondern auch Anderen. Ja, unleserlicher Code ist schlecht wartbar, weil man ihn versteht. Ja, unleserlicher Code macht die Fehlersuche schwer, weil man ihn nicht versteht. Ja, unleserlicher Code macht es anderen schwer ins Projekt einzusteigen, weil man ihn nicht versteht. Es läuft also alles aufs gleiche hinaus. Unleserlicher Code ist unverständlich!
Deswegen mein Apell an alle: Geht Quellcode des öfteren durch und nicht nur wenn ihr etwas ändern müsst/wollt. Lest einen Tag später nochmal drüber und ändert die Namen wenn sie nicht eindeutig sind, gliedert Methoden aus, wenn das dem Verständnis hilft. Refaktoriert was das Zeug hält um euren Code vom Vortag "aufzuhübschen". Ich jedenfalls werde mir genau dies angewöhnen. Morgens als erstes ein Selbsreview durchzuführen. Natürlich wird der Code so nicht perfekt aber besser und das ist mein Ziel: Besser zu werden.
Donnerstag, 10. Januar 2013
Meine Tomaten, oder die Pomodoro-Technik
Viele kennen das Problem vermutlich. Man hat sich einen Plan gemacht was man über den Tag erledigen will und immer kommt irgendwas dazwischen: Kollegen die etwas wissen wollen, Chefs die etwas erledigt haben wollen etc. pp. Ein paar mal habe ich es erlebt, dass ich gar nichts von dem erledigt bekommen habe was ich ursprünglich geplant hatte. Doch wie ändert man dies?
In dem Buch "The Clean Coder" von Robert C. Martin habe ich von der Pomodoro-Technik (http://www.pomodorotechnique.com/) gelesen und diese ausprobiert. Die Pomodoro-Technik eignet sich zum Zeitmanagement für geistige Aufgaben. Angewandt ist sie einfach. To-Do-Liste schreiben, Aufgabe (aus der To-Do-Liste) bestimmen die man bearbeiten will, Küchenuhr (Pomodoro) auf 25 Minuten drehen und los gehts. Das besondere dieser Thechnik sind meines Erachtens die festgelegten Zeiteinheiten und Pausen. Eine Zeiteinheit beträgt wie erwähnt 25 Minuten. Diese 25 Minuten werden als Pomodoro oder Tomate bezeichnet[1]. Nach jeder Pomodoro werden 5 Minuten Pause eingelegt, in denen NICHT an der während der Tomate bearbeiteten Aufgabe weitergemacht oder auch nur drüber nachgedacht werden soll. Diese Pause dient dazu Abstand zu gewinnen, sein Mana (wie Martin es in "The Clean Coder" bezeichnet) wieder aufzufüllen und erfrischt in die nächste Tomate zu starten. Daraus resultiert, dass man sich am Ende nicht ausgelaugt fühlt. Während einer Tomate soll man alle Ablenkung und Unterbrechung vermeiden und unterbinden. Kollegen die stören vertröstet man auf nach die Tomate Telefonate werden danach erledigt etc. Man arbeitet also 25 Minuten konzentriert an EINER Aufgabe. Zu Statistik-Zwecken kann/soll man die Anzahl der für eine Aufgabe benötigten Tomaten notieren. Dies sind nur ein Paar Aspekte der Technik, der Rest ist auf der angegebenen Seite nachzulesen wenn bedarf besteht.
Soweit, so gut. Kurzes googlen führte mich zur Pomodoro-App (http://www.pomodoroapp.com/) da ich verständlicherweise in einen Büro, welches ich nicht alleine bewohne keine Küchenuhr klingeln lassen wollte, und das alle 25 Minuten... Also App runtergeladen und los gings. Die App ist denkbar simpel. Aufgaben eintragen die für heute markieren und auf der Aufgabe die man bearbeiten will auf "start" klicken.
Die App wird zu einem kleinen süßen Widget was man auf dem Desktop an eine beliebige Stelle schieben kann und stört so nicht mehr. Sind die 25 Minuten abgelaufen wird die App wieder groß und die Pause fängt an. Auch hier möchte ich auf die weiteren Funktionen nicht eingehen.
In dem Buch "The Clean Coder" von Robert C. Martin habe ich von der Pomodoro-Technik (http://www.pomodorotechnique.com/) gelesen und diese ausprobiert. Die Pomodoro-Technik eignet sich zum Zeitmanagement für geistige Aufgaben. Angewandt ist sie einfach. To-Do-Liste schreiben, Aufgabe (aus der To-Do-Liste) bestimmen die man bearbeiten will, Küchenuhr (Pomodoro) auf 25 Minuten drehen und los gehts. Das besondere dieser Thechnik sind meines Erachtens die festgelegten Zeiteinheiten und Pausen. Eine Zeiteinheit beträgt wie erwähnt 25 Minuten. Diese 25 Minuten werden als Pomodoro oder Tomate bezeichnet[1]. Nach jeder Pomodoro werden 5 Minuten Pause eingelegt, in denen NICHT an der während der Tomate bearbeiteten Aufgabe weitergemacht oder auch nur drüber nachgedacht werden soll. Diese Pause dient dazu Abstand zu gewinnen, sein Mana (wie Martin es in "The Clean Coder" bezeichnet) wieder aufzufüllen und erfrischt in die nächste Tomate zu starten. Daraus resultiert, dass man sich am Ende nicht ausgelaugt fühlt. Während einer Tomate soll man alle Ablenkung und Unterbrechung vermeiden und unterbinden. Kollegen die stören vertröstet man auf nach die Tomate Telefonate werden danach erledigt etc. Man arbeitet also 25 Minuten konzentriert an EINER Aufgabe. Zu Statistik-Zwecken kann/soll man die Anzahl der für eine Aufgabe benötigten Tomaten notieren. Dies sind nur ein Paar Aspekte der Technik, der Rest ist auf der angegebenen Seite nachzulesen wenn bedarf besteht.
Soweit, so gut. Kurzes googlen führte mich zur Pomodoro-App (http://www.pomodoroapp.com/) da ich verständlicherweise in einen Büro, welches ich nicht alleine bewohne keine Küchenuhr klingeln lassen wollte, und das alle 25 Minuten... Also App runtergeladen und los gings. Die App ist denkbar simpel. Aufgaben eintragen die für heute markieren und auf der Aufgabe die man bearbeiten will auf "start" klicken.Die App wird zu einem kleinen süßen Widget was man auf dem Desktop an eine beliebige Stelle schieben kann und stört so nicht mehr. Sind die 25 Minuten abgelaufen wird die App wieder groß und die Pause fängt an. Auch hier möchte ich auf die weiteren Funktionen nicht eingehen.
Ich habe nun also meine Aufgaben die ich noch auf dem Zettel hatte in die App übertragen und mit einer beliebigen angefangen. Zu beginn ist es furchtbar schwierig in den 25 Minuten keine Störungen zuzulassen aber das wird mit der Zeit einfacher. Nun kan ich irgendwann an den Punkt, dass ich zeitaufändige Tests durchführen musste, die allerdings nicht beobachtet werden mussten. Solche Aufgaben eignen sich nicht für die Pomodoro-Technik, da die Technik voraussetzt, dass man während der 25 Minuten aktiv arbeitet. Ich habe hier also eine andere Aufgabe begonnen und erst nach Ablauf einer Tomate nach dem Teststand geschaut. Konnte ich auf den Test reagieren habe ich dies wieder mit der Pomodoro-Technik getan. Hierbei fiel mir eine andere Schwachstelle auf. Eine Pomodoro MUSS ablaufen und komplett bearbeitet werden. Hat man nun eine Aufgabe, welche lediglich 5 Minuten in Anspruch nimmt und die man nicht erweitern kann, durch andere Teilaufgaben beispielsweise, lohnt es sich eigentlich nicht dafür die Technik zu verwenden. Ich will ja nicht, dass die Zeitstatistiken für 2 unterschiedliche Projekte vermischt werden.
Fazit
Die Technik ist für große/lange Aufgabe sehr gut geeignet. Sie verhindert, dass man sich zu sehr reinsteigert und dadurch seine ganze Energie veräußert. Für die Abschließende Phase einer Entwicklung wo zumeinst nur kleinere Buxfixes und Tests anstehen kann man sie jedoch getrost vergessen. Hier lohnt es sich einfach weiter so zu arbeiten wie immer. Eine gute Sache kann man jedoch auch auf kleine Aufgaben mitnehmen. Lass dich nicht stören bis du fertig bist. So wird eine Aufgabe effizient erledigt.
Abonnieren
Posts (Atom)