Laut einer Studie (hier das englischen Original) des Bezahldienstleisters Stripe, gehen 42 Prozent der Arbeitszeit eines Entwicklers für die Beschäftigung mit technischen Schulden und "Bad Code" drauf.
Ich habe das gerade erst wieder Freitag selbst erlebt. Ich habe den ganzen Tag mit der Erweiterung eines von mir entwickelten Skripts zugebracht, welches ich schon länger nicht mehr "angefasst" hatte (was ein gutes Zeichen ist, denn es ist in der ganzen Abteilung fast täglich im Einsatz und die Bugs halten sich demnach in Grenzen :-)).
Allerdings waren mir dadurch die Feinheiten der API nicht mehr so ganz präsent, so dass ich nach einigen Stunden plötzlich in einen Fehler lief (beim manuellen Testen. Selbstverständlich gab es keine ständig ausführbaren, voneinander unabhängigen automatischen Tests).
Also debugged (mittels "print") und irgendwann schlug dann die Erkenntnis zu: Stimmt ja, dieser Befehl führt den Code ja verzögert aus. Variablen die darüber definiert werden, sind erst beim nächsten Skriptlauf verfügbar und ein Variablenzugriff im ersten Lauf führt entsprechend zu einem Fehler.
Ein Kommentar an dieser Stelle, welches mich (oder einen anderen Entwickler) daran erinnert hätte, hätte mir (und damit der Firma) eine halbe bis Dreiviertelstunde, in der ich den Fehler eingebaut, danach gesucht und dann wieder ausgebaut habe, erspart.
Jetzt steht der Kommentar im Code.
Aber eben, wie in der Studie aufgeführt, etwa zehn Prozent der Arbeitszeit durch Bad Code verschwendet.
Unternehmen (und vielleicht schon Universitäten?) sollten nicht nur darauf bedacht sein, dass ihre Entwickler (bzw. Studenten) programmieren können, sondern dass sie auch "gut", also verständlich und nachhaltig programmieren.
Also nicht nur "Kann Dein Code dem Computer klar machen, was Du willst?" sondern auch "Kann Dein Code einem Menschen klar machen, was Du willst?"
Ich habe das gerade erst wieder Freitag selbst erlebt. Ich habe den ganzen Tag mit der Erweiterung eines von mir entwickelten Skripts zugebracht, welches ich schon länger nicht mehr "angefasst" hatte (was ein gutes Zeichen ist, denn es ist in der ganzen Abteilung fast täglich im Einsatz und die Bugs halten sich demnach in Grenzen :-)).
Allerdings waren mir dadurch die Feinheiten der API nicht mehr so ganz präsent, so dass ich nach einigen Stunden plötzlich in einen Fehler lief (beim manuellen Testen. Selbstverständlich gab es keine ständig ausführbaren, voneinander unabhängigen automatischen Tests).
Also debugged (mittels "print") und irgendwann schlug dann die Erkenntnis zu: Stimmt ja, dieser Befehl führt den Code ja verzögert aus. Variablen die darüber definiert werden, sind erst beim nächsten Skriptlauf verfügbar und ein Variablenzugriff im ersten Lauf führt entsprechend zu einem Fehler.
Ein Kommentar an dieser Stelle, welches mich (oder einen anderen Entwickler) daran erinnert hätte, hätte mir (und damit der Firma) eine halbe bis Dreiviertelstunde, in der ich den Fehler eingebaut, danach gesucht und dann wieder ausgebaut habe, erspart.
Jetzt steht der Kommentar im Code.
Aber eben, wie in der Studie aufgeführt, etwa zehn Prozent der Arbeitszeit durch Bad Code verschwendet.
Unternehmen (und vielleicht schon Universitäten?) sollten nicht nur darauf bedacht sein, dass ihre Entwickler (bzw. Studenten) programmieren können, sondern dass sie auch "gut", also verständlich und nachhaltig programmieren.
Also nicht nur "Kann Dein Code dem Computer klar machen, was Du willst?" sondern auch "Kann Dein Code einem Menschen klar machen, was Du willst?"
Kommentare
Kommentar veröffentlichen