Warum jammern alle über schlechten Code?
-
hustbaer schrieb:
...Blöd wäre wenn das irgendwelche komplizierte Business-Logik wäre für die es keine/nur unzureichende Test-Cases gibt,...
Ist das nicht der Standard? ;p
-
Auch schlimm sind hartcodierte Sonderfälle. Wenn die Logik in seltenen Fällen leicht abgeändert werden muss. Dummerweise häufen sich die Sonderfälle dann irgendwann bis der einstige Normalfall zum Sonderfall wird. Spätestens dann sollte man ebenfalls darüber nachdenken, das anders zu regeln (was nicht selten einiges an refactoring erfordert)
-
hustbaer schrieb:
Gerade schlechte Programmierer haben dann Schwierigkeiten sich im Code andere Leute zurechtzufinden. Und gerade schlechte Programmierer überschätzen sich am meisten. Also jammern sie, und meinen sie könnten das alles viel besser machen, wenn sie es nur neu schreiben dürften.
Allerdings kenne ich wenige Branchen, in denen die Qualität der einzelnen Arbeitskräfte so stark variiert wie im IT-Bereich im Allgemeinen und in der Entwicklung im Besonderen. Hier hat der enorme Bedarf dazu geführt, dass das viele Geld eine Menge weniger qualifizierte IT-ler unterwegs sind.
Auf der anderen Seite gibt auch nur wenige Bereiche, in denen die Arbeitsqualität für die Auftraggeberseite so wenig/spät zu beurteilen ist, wie im IT-Bereich. Dank der heute üblichen Tools sieht die Software von außen schon mit minimalem Aufwand perfekt aus. Designfehler, mangelnde Effizienz, reduzierte Entwicklungsfähigkeit kann man von außen schlecht beurteilen und nur schlecht maschinell messen. Außer in der hohen Quote der gescheiterter Projekte.
War ganz erstaunt, dass diese grundlegende Problematik schon in der Literatur der Sechziger bis Achtziger diskutiert wurde. Frederick P. Brooks zum Beispiel erkannte die Herausforderung korrekt, dass es nicht darum geht, die perfekten Entwickler zu finden/auszubilden, sondern wie man mit Unmengen von weniger begabten Menschen ein lauffähiges Betriebssystem entwickelt.
Ciao, Allesquatsch
-
Allesquatsch schrieb:
hustbaer schrieb:
Gerade schlechte Programmierer haben dann Schwierigkeiten sich im Code andere Leute zurechtzufinden. Und gerade schlechte Programmierer überschätzen sich am meisten. Also jammern sie, und meinen sie könnten das alles viel besser machen, wenn sie es nur neu schreiben dürften.
Allerdings kenne ich wenige Branchen, in denen die Qualität der einzelnen Arbeitskräfte so stark variiert wie im IT-Bereich im Allgemeinen und in der Entwicklung im Besonderen. Hier hat der enorme Bedarf dazu geführt, dass das viele Geld eine Menge weniger qualifizierte IT-ler unterwegs sind.
Auf der anderen Seite gibt auch nur wenige Bereiche, in denen die Arbeitsqualität für die Auftraggeberseite so wenig/spät zu beurteilen ist, wie im IT-Bereich. Dank der heute üblichen Tools sieht die Software von außen schon mit minimalem Aufwand perfekt aus. Designfehler, mangelnde Effizienz, reduzierte Entwicklungsfähigkeit kann man von außen schlecht beurteilen und nur schlecht maschinell messen. Außer in der hohen Quote der gescheiterter Projekte.
War ganz erstaunt, dass diese grundlegende Problematik schon in der Literatur der Sechziger bis Achtziger diskutiert wurde. Frederick P. Brooks zum Beispiel erkannte die Herausforderung korrekt, dass es nicht darum geht, die perfekten Entwickler zu finden/auszubilden, sondern wie man mit Unmengen von weniger begabten Menschen ein lauffähiges Betriebssystem entwickelt.
Ciao, Allesquatsch
Sehr gute Analyse.
-
Wirklich ärgerlich ist es aber (für mich persönlich zumindest), wenn man weiss dass dieser Code von einem einzigen Programmierer verbrochen wurde. Und wenn man schon alleine an einem (Teil eines) Projekt(s) arbeitet, dann sollte man doch wenigstens aufpassen dass man die Grenze nicht überschreitet ab wo es unwartbar wird. Und wenn diese erreicht ist einfach hart bleiben und dem Chef sagen "ne, das dauert jetzt N Tage, geht nicht schneller".
Das habe ich auch erst lernen müssen.
Ist übrigens auch ein Projekt das nach dem Motto "immer nur dazustöpseln, bloss nie was ändern was nicht sein muss, und schon gar keinen alten Code löschen, lieber auskommentieren und vor sich hinrotten lassen" über mehrere Jahre erweitert/geändert wurde.
Oh ja, kommt mir nicht unbekannt vor.
1.) Projekt startet unter Zeitdruck, s.d. schnelles Coding viele Hacks hervorbringt
3.) Immer nur was am Code dazustöpseln
4.) Bloss nie was am Code ändern was nicht sein muss ("Never change a running team")
5.) Und schon gar keinen alten Code löschen, lieber auskommentieren und vor sich hinrotten lassen ("Warum das Rad neu erfinden ?")
6.) Alter Code, welcher bisher funktioniert hat, genießt besonderes Vertrauen, auch wenn dieser nur in sehr speziellen Fällen funktionierte
7.) Entwicklung von speziellen Code, für spezielle Anwendungen. Wird der Code anders benutzt als vom Entwickler gedacht, kommt es meistens zum Crash oder zu korrupten Daten. An Fehlerzuständen wird hierbei nicht gedacht.Wenn man so was erleben durfte, bekommen Sprüche wie "Effizienz" eine ganz andere Bedeutung...
-
Codeauskommentierer ist ein Synonym für Warmduscher. Das machen Leute, die ihr Sourceverwaltungssystem nicht kennen. Leider gilt das für sehr viele Leute in der Branche inklusive Projektverantwortliche.
Eine andere Seite ist, dass ein ITler glänzen kann, wenn er seine Fehler zügig beheben kann, aber nicht, wenn die Fehler erst gar nicht auftreten. Die fallen halt nicht auf. Daher fällt ein mittelmäßiger Programmierer eher positiv auf als ein guter.
Und @Allesquatsch:
-
tntnet schrieb:
Codeauskommentierer ist ein Synonym für Warmduscher. Das machen Leute, die ihr Sourceverwaltungssystem nicht kennen. Leider gilt das für sehr viele Leute in der Branche inklusive Projektverantwortliche.
Stimmt, wobei ich inzwischen hier einen Kompromiss durchgesetzt habe: Bei wirklich massiven Änderungen wird zwar auskommentiert, dies aber mit einem Zeitstempel versehen, und spätestens 2-3 Monate später wird der Code wenn nicht ein Grund für die Reaktivierung vorlag dann entfernt.
-
Allesquatsch schrieb:
Allerdings kenne ich wenige Branchen, in denen die Qualität der einzelnen Arbeitskräfte so stark variiert wie im IT-Bereich im Allgemeinen und in der Entwicklung im Besonderen. Hier hat der enorme Bedarf dazu geführt, dass das viele Geld eine Menge weniger qualifizierte IT-ler unterwegs sind.
Das ist aber kein Grund jegliche Aufräumarbeiten zu unterbinden, jeder kann Hinzulernen und feststellen das er einst Fehler begangen hat. Wenn man zumindest in gewissen Grenzen immer mal aufräumt, bleiben Projekte zumindest grundsätzlich wartbar.
Ich halte mich weder für einen Guru noch einen perfekten Entwickler, den gibt es meines Erachtens nicht. Die Frage ist auch nicht so sehr ob ein Entwickler gut oder schlecht ist, sondern ob dieser bereit ist aus seinen Fehlern zu lernen und diese wenn eine Gelegenheit existiert, auch nach und nach aus Projekten wieder ausbaut.
Die einzig "schlimmen" Entwickler die ich kenne sind die, die nach dem Studium jegliches Lernen eingestellt haben, und meinen das Wissen von vor 20 Jahren heute noch immer perfekt gilt (zumal meiner Erfahrung nach, im Studium nicht gerade sauber programmiert wird).
-
asc schrieb:
Das ist aber kein Grund jegliche Aufräumarbeiten zu unterbinden, jeder kann Hinzulernen und feststellen das er einst Fehler begangen hat. Wenn man zumindest in gewissen Grenzen immer mal aufräumt, bleiben Projekte zumindest grundsätzlich wartbar.
Das war zwar nicht meine Intention, aber auch hier ist die betriebliche Realität eine andere: Die Motivation schlechten Code zu revidieren, geht in der Praxis gegen Null.
1. Niemand braucht perfekten Code, wenn der andere seine Aufgabe auch erfüllt.
2. Die Qualität der Entwickler wird nicht besser, wenn sie etwas zweimal machen. Im Gegenteil ist empirisch festgestellt, dass zweite Projekte weniger effektiv sind.
3. Unternehmen investieren nur einmal in Anwendungen. Budget gibt es nur, wenn funktionale Erweiterungen notwendig oder die Stabilität des Altsystems anscheinend keinen Ausweg mehr bieten.asc schrieb:
Ich halte mich weder für einen Guru noch einen perfekten Entwickler, den gibt es meines Erachtens nicht. Die Frage ist auch nicht so sehr ob ein Entwickler gut oder schlecht ist, sondern ob dieser bereit ist aus seinen Fehlern zu lernen und diese wenn eine Gelegenheit existiert, auch nach und nach aus Projekten wieder ausbaut.
Ist Dir aber nur dann möglich, wenn niemand kontrolliert, was Du wirklich tust. In Unternehmen mit betriebswirtschaftlicher Ausrichtung oder im größeren Umfang ist so etwas i.d.R. nicht möglich.
asc schrieb:
Die einzig "schlimmen" Entwickler die ich kenne sind die, die nach dem Studium jegliches Lernen eingestellt haben, und meinen das Wissen von vor 20 Jahren heute noch immer perfekt gilt (zumal meiner Erfahrung nach, im Studium nicht gerade sauber programmiert wird).
Gerade unter denjenigen, die frisch aus einem IT-basierten Studium kommen, habe ich kaum Mitarbeiter kennengelernt, die man sinnvoll kommerziell als Entwickler einsetzen konnte.
Zum einen befähigt die Kenntnis eines Wörterbuchs nicht dazu, einen Sachverhalt verständlich in einer fremden Sprache auszudrücken. Zum anderen verschaffen Programmierscheine oder Bachelorzeugnis ein trügerisches Selbstbewusstsein, welches die Lernfähigkeit deutlich herabsetzt. So mancher fühlt sich wie ein junger Pilot unter betagten Fahrradfahrern.Ciao, Allesquatsch
-
Allesquatsch schrieb:
Das war zwar nicht meine Intention, aber auch hier ist die betriebliche Realität eine andere: Die Motivation schlechten Code zu revidieren, geht in der Praxis gegen Null.
1. Niemand braucht perfekten Code, wenn der andere seine Aufgabe auch erfüllt.Ich rede nicht von perfekten Code, sondern von aufräumen. Schlechter Code wird nicht besser wenn man diesen immer weiterzieht, und immer mehr erweitert. Im Gegenteil summieren sich die Probleme auf.
Schlechter Code mag anfangs noch laufen, kann einem aber auch später sehr schnell das Bein stellen.
Allesquatsch schrieb:
2. Die Qualität der Entwickler wird nicht besser, wenn sie etwas zweimal machen. Im Gegenteil ist empirisch festgestellt, dass zweite Projekte weniger effektiv sind.
Ich kenne die Studie nicht, halte sie aber auch eher für unsinn. Zum einen geht es beim Aufräumen auch nicht darum Code zu wiederholen, sondern zu verbessern. Zum anderen stimmt deine Aussage aus Sicht des Gehirnes auch nicht (Wiederholung dient dem Merken).
Allesquatsch schrieb:
3. Unternehmen investieren nur einmal in Anwendungen. Budget gibt es nur, wenn funktionale Erweiterungen notwendig oder die Stabilität des Altsystems anscheinend keinen Ausweg mehr bieten.
Die Stabilität des Altsystemes könnte aber wesentlich länger halten, wenn man auch Zeit zum Aufräumen einräumt. Spätestens wenn man (wie ich in einem Projekt erlebt habe) 90% der Zeit mit Fehlerkorrekturen rund um verkorksten Code investieren muss, wird man feststellen, das Aufräumen langfristig die bessere Lösung ist (der Code bleibt langfristig wartbar).
Allesquatsch schrieb:
asc schrieb:
Ich halte mich weder für einen Guru noch einen perfekten Entwickler, den gibt es meines Erachtens nicht. Die Frage ist auch nicht so sehr ob ein Entwickler gut oder schlecht ist, sondern ob dieser bereit ist aus seinen Fehlern zu lernen und diese wenn eine Gelegenheit existiert, auch nach und nach aus Projekten wieder ausbaut.
Ist Dir aber nur dann möglich, wenn niemand kontrolliert, was Du wirklich tust.
Oh, mein Chef kontrolliert dies durchaus. Doch er selbst weiß den Sinn hinter dem Aufräum
Allesquatsch schrieb:
In Unternehmen mit betriebswirtschaftlicher Ausrichtung oder im größeren Umfang ist so etwas i.d.R. nicht möglich.
Nur wenn die Herrn Manager keine Ahnung haben und das Projekt schnelllebig ist. Wer weiß wohin immer nur "schnell, schnell, schnell" führt, kann sich durchaus selbst errechnet ob sich diese "Mehrkosten" nicht sogar den Endpreis reduzieren.
Allesquatsch schrieb:
asc schrieb:
Die einzig "schlimmen" Entwickler die ich kenne sind die, die nach dem Studium jegliches Lernen eingestellt haben, und meinen das Wissen von vor 20 Jahren heute noch immer perfekt gilt (zumal meiner Erfahrung nach, im Studium nicht gerade sauber programmiert wird).
Gerade unter denjenigen, die frisch aus einem IT-basierten Studium kommen, habe ich kaum Mitarbeiter kennengelernt, die man sinnvoll kommerziell als Entwickler einsetzen konnte.
So drastisch wollte ich dies nicht ausdrücken, ich kenne auch beide Seiten (Einige Studierte die man in der Pfeife rauchen kann und andere die sich auf ihren Lorbeeren nicht ausruhen).
Allesquatsch schrieb:
Zum einen befähigt die Kenntnis eines Wörterbuchs nicht dazu, einen Sachverhalt verständlich in einer fremden Sprache auszudrücken.
Nur sollte das Studium nicht lernen auswendig zu lernen, sondern lernen zu Lernen. Und das tut es auch, wenn man sich nicht darauf ausruht.
Allesquatsch schrieb:
Zum anderen verschaffen Programmierscheine oder Bachelorzeugnis ein trügerisches Selbstbewusstsein, welches die Lernfähigkeit deutlich herabsetzt. So mancher fühlt sich wie ein junger Pilot unter betagten Fahrradfahrern.
Auch die Aussage ist zu pauschal. Ich weiß um den Wert eines Studiums (auch wenn ich nur ein abgebrochenes habe), und obwohl ich mich über einige Studierte aufrege (die sich nach dem Studium nichts mehr gemacht haben) gibt es ebenso Studierte die auch wirklich besser sind, weil sie eben nicht aufhören zu Lernen.