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.
Abonnieren
Posts (Atom)