Warum jammern alle über schlechten Code?
-
http://www.joelonsoftware.com/articles/fog0000000069.html
There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It’s harder to read code than to write it.
Auch sonst lesenswert.
-
Fakt ist doch das jeder Code sobald er über eine gewisse Zeit wächst zu einem hässlichen Brei mutiert.
-
Über fremden Code kann man nur meckern, wenn man irgendein Gefühl für das hat, was guten Code auszeichnet. Das bedeutet nicht, dass man selbst guten Code produziert, aber es ist die Voraussetzung dafür. Deshalb jammern IMHO nur schlechte Programmierer nicht über schlechten Code.
-
Die Frage ist gar nicht so uninteressant, auch wenn das erstmal nach einem Trollpost aussieht.
Zu einem großen Teil stimmt es ja einfach auch, dass alter Code schlecht ist. Seitdem hat sich viel weiterentwickelt, man lernt schon im Studium/Ausbildung/modernen Büchern viel mehr über Codequalität und Architekturen. Früher war das nicht so, da hat man hauptsächlich programmieren gelernt. Auch was man heute schreibt ist natürlich aus vielerlei Gründen nicht optimal, aber es ist oft immer noch um Längen besser als alter Code. Das kann ich z.B. bei uns in der Firma beobachten. Die langjährigen Chefentwickler sind alle nicht stolz auf ihren alten Code und programmieren heute ganz anders. Auch weil sie selber sehen, wie stark die Software in 20 Jahren gewachsen ist, und wie unglaublich unflexibles und wirr der Legacy Code war.
Das andere ist natürlich, dass Jammern einfach dazu gehört
Warum sollte man es nicht tun? Wenn ich über richtig schlechten Code stolpere, reg ich mich öfter mal auf. z.B., weil es mich unerwartet viel Zeit kostet, oder weil da versteckte Bugs sind, die viel später entdeckt werden und sehr schwer zu finden sind. Dass ich selber oft suboptimalen Code schreibe, ist mir selber klar. Das ist dann aber bewußt suboptimaler Code, weil die Zeit knapp ist (ist sie grundsätzlich), das ganze Projekt nicht so wichtig ist, eine optimale Lösung viel zu aufwändig oder aus anderen Gründen nicht realisierbar wäre usw.
Kann aber natürlich passieren, dass der nächste sich dann über meinen Code aufregt Wenn ich mal was anfange, was erstmal nicht so wichtig ist und dann "gut genug" ist, ist es natürlich nicht ausgeschlossen, dass später weitere Projekte kommen, die auf derselben Basis aufbauen müssen und dann ist es plötzlich wichtig und der nächste darf sich aufregen 
Aber ganz so üblen Legacy Code schreibe ich dann hoffentlich doch nie
-
Bashar schrieb:
Über fremden Code kann man nur meckern, wenn man irgendein Gefühl für das hat, was guten Code auszeichnet.
Nö, man kann immer über fremden Code meckern.
Viele Leute meckern wenn sie was nicht verstehen. Die sind dann auch gern der Meinung dass es schlecht sein muss, weil sie es ja nicht verstehen. Wobei es halt auch oft daran liegt, dass sie tonnenweise Standardpatterns bzw. einfache Praktiken nicht kennen (ich hab z.B. in den letzten 5 Jahren noch mit etlichen C++ Programmierern gearbeitet denen ich einfache RAII Helperklassen ala
unique_locknoch erklären musste).Bashar schrieb:
Deshalb jammern IMHO nur schlechte Programmierer nicht über schlechten Code.
Meine Erfahrung sagt was anderes.
Schlechte Programmierer jammern auch oft über schlechten Code. Und es gibt sehr gute Programmierer die kaum jammern. (Die dann vielleicht, wenn man sie fragt, sagen dass der Code nicht so gut ist, aber sich von selbst nicht grossartig drüber aufregen.)
Es gibt auch mittelmässige Programmierer die kaum jammern, z.B. weil sie sehr Chaos-resistent sind.
-
Problematisch wird es ja erst dann wirklich, wenn es vom "Jammern auf hohem Niveau" weg und richtung "starke Einbußen bei nichtfunktionalen Anforderungen an den Code" hin geht. Dementsprechend also schon der Einbau kleinster Features die gesamte Code-Basis betreffen, ein Verstehen der Sourcen nur noch nach jahrelanger Einführung möglich ist, Code derart verstrickt ist, dass man quasi nur noch mit Bugfixing beschäftigt ist, etc.
Dementsprechend sollten aber auch "Seniors" oder "Leads" dementsprechende Code-Reviews auf regelmäßiger Basis durchführen, Schwachstellen aufspüren, und in kurzen 5min-Reviews (bspw. beim täglichen Standup-Meeting) auf die Probleme die daraus resultieren hinweisen und "besseren" Code zeigen + warum der Code besser ist. Das Ausbessern selbst dann am besten gleich dem Verursacher überlassen, so lernt er dazu + bekommt nicht das Gefühl, dass es eh jemanden gibt der auf ihn aufpasst und seine Code-Qualität egal ist.
MfG SideWinder
-
Dementsprechend sollten aber auch "Seniors" oder "Leads" dementsprechende Code-Reviews auf regelmäßiger Basis durchführen, Schwachstellen aufspüren, und in kurzen 5min-Reviews (bspw. beim täglichen Standup-Meeting) auf die Probleme die daraus resultieren hinweisen und "besseren" Code zeigen + warum der Code besser ist. Das Ausbessern selbst dann am besten gleich dem Verursacher überlassen, so lernt er dazu + bekommt nicht das Gefühl, dass es eh jemanden gibt der auf ihn aufpasst und seine Code-Qualität egal ist.
Herrlich wäre das. Aber das klingt für mich nach "Schweben in sieben Wolken". Wo passiert so was denn? Und der Chefentwickler muss die entsprechende Kompetenz haben, um die Designfehler des Originalcodes fein auszuweisen und gleichzeitig einen schöneren Code darzustellen. Dafür besteht im Regelfall wohl leider kaum Zeit.
-
Wenn ich schlechtes Essen zu mir nehme, dann beschwere ich mich, dass es schlecht ist.
-
Eisflamme schrieb:
Dementsprechend sollten aber auch "Seniors" oder "Leads" dementsprechende Code-Reviews auf regelmäßiger Basis durchführen, Schwachstellen aufspüren, und in kurzen 5min-Reviews (bspw. beim täglichen Standup-Meeting) auf die Probleme die daraus resultieren hinweisen und "besseren" Code zeigen + warum der Code besser ist. Das Ausbessern selbst dann am besten gleich dem Verursacher überlassen, so lernt er dazu + bekommt nicht das Gefühl, dass es eh jemanden gibt der auf ihn aufpasst und seine Code-Qualität egal ist.
Herrlich wäre das. Aber das klingt für mich nach "Schweben in sieben Wolken". Wo passiert so was denn? Und der Chefentwickler muss die entsprechende Kompetenz haben, um die Designfehler des Originalcodes fein auszuweisen und gleichzeitig einen schöneren Code darzustellen. Dafür besteht im Regelfall wohl leider kaum Zeit.
Das müsste aber jemand machen, der nur daran interessiert ist, richtige Probleme zu fixen. Sobald es nämlich darum geht aus funktionierendem & nicht allzu schlimmem Code irgendwelche eleganten/idiomatischen Lösungen zu machen ... gute Nacht.
-
Ethon schrieb:
Eisflamme schrieb:
Dementsprechend sollten aber auch "Seniors" oder "Leads" dementsprechende Code-Reviews auf regelmäßiger Basis durchführen, Schwachstellen aufspüren, und in kurzen 5min-Reviews (bspw. beim täglichen Standup-Meeting) auf die Probleme die daraus resultieren hinweisen und "besseren" Code zeigen + warum der Code besser ist. Das Ausbessern selbst dann am besten gleich dem Verursacher überlassen, so lernt er dazu + bekommt nicht das Gefühl, dass es eh jemanden gibt der auf ihn aufpasst und seine Code-Qualität egal ist.
Herrlich wäre das. Aber das klingt für mich nach "Schweben in sieben Wolken". Wo passiert so was denn? Und der Chefentwickler muss die entsprechende Kompetenz haben, um die Designfehler des Originalcodes fein auszuweisen und gleichzeitig einen schöneren Code darzustellen. Dafür besteht im Regelfall wohl leider kaum Zeit.
Das müsste aber jemand machen, der nur daran interessiert ist, richtige Probleme zu fixen. Sobald es nämlich darum geht aus funktionierendem & nicht allzu schlimmem Code irgendwelche eleganten/idiomatischen Lösungen zu machen ... gute Nacht.
Was ist eine idiomatische Lösung? Hab das Wort neulich in der Java-"Fachdiskussion" auch dauernd gelesen, finde aber im Netzt keine passende Übersetzung.
-
Redewendungen in C++. Sowas: http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms . Also spezielle Patterns in der jeweiligen Programmiersprache (hier C++), die in anderen Programmiersprachen aufgrund anderer Sprachmittel anders geloest werden muessen/koennen. Im Gegensatz dazu sind Designpatterns nicht zwingend an die Sprache sondern vielmehr an das Paradigma beispielsweise OOP gebunden.
-
Was Idiome sind, wußte ich schon.
Also ist eine idiomatische Lösung eine, die Idiome benutzt? Tut doch eh jede. Und warum verwenden so viele "idiomatisch", wenn sie "kanonisch" meinen?
-
Habe eine mir vertraute Bedeutung für idiomatisch gefunden: http://www.wortbedeutung.info/idiomatisch/
Zum Thema: Es gibt keine Messregel für die Qualität von Code mit einer Skala von z.B. 0 (sehr schlecht) bis 100 (sehr gut).
Es gibt nur einige Ansprüche:
- soll sicher funktionieren
- soll auch Ausnahmefälle berücksichtigen
- soll übersichtlich strukturiert und nachvollziehbar sein, auch für fremde Personen oder die Entwicklung im Team
- soll hinreichend dokumentiert sein
- soll für Änderungen und Erweiterungen vorbereitet sein
- muss den Kostenrahmen einhaltenIch denke, das reicht. Alles weitere ist Praxis, nicht unbedingt Wissenschaft.
-
volkard schrieb:
Was Idiome sind, wußte ich schon.
Also ist eine idiomatische Lösung eine, die Idiome benutzt? Tut doch eh jede. Und warum verwenden so viele "idiomatisch", wenn sie "kanonisch" meinen?
Die Frage verstehe ich nicht ganz. Mir hilft vielleicht ein Beispiel: Was ist die kanonische/idiomatische Implemtieriung eines Zustandsautomaten, also: Wenn in Zustand A ein c gelesen wird, dann mache X und sei danach in Zustand C?
Idiomatisch in C++: switch-Statement.
Idiomatisch in ...: Coroutine.Kanonisch ... ? State-Pattern? Tabelle?
Irgendwie passt "kanonisch" hier nicht. Wenn ich an kanonische Normalformen denke, so sind sie zwar einheitlich, aber sehr aufgeblaeht und restriktiv in den verwendeten Sprachmitteln (z.b. nur AND und OR), was eher nicht erstrebenswert ist. Boilerplatecode mag keiner lesen oder schreiben.
-
Warum werden in der Informatik / IT-Branche so oft bereits vorhandene Begriffe zweckentfremdet mit unklarer neuer Bedeutung verwendet.
Das fängt bei Design und Architektur bereits an! Bei fremden Code wird einfach gejammert, weil man ihn erst verstehen muss! 
-
berniebutt schrieb:
Warum werden in der Informatik / IT-Branche so oft bereits vorhandene Begriffe zweckentfremdet mit unklarer neuer Bedeutung verwendet.(
In der Informatik macht man es aus dem selben Grund so, aus dem man es auch in den anderen technischen Fachrichtungen: weil es einfacher zu merken ist als wenn man komplett neue Begriffe erfinden würde.
Und öfter macht man es, weil sich in der Informatik wahnsinnig viel tut, und so schnell so viele neue Dinge dazukommen für die man einen Namen braucht.----
Bis zu einem gewissen Punkte könnte man sich noch behelfen indem man immer beschreibt was man meint, und sich auf eine kanonische (*g*) Beschreibung einigt.
Dummerweise würde man so vermutlich gleich mehrere Minuten brauchen nur um die kanonische Beschreibung für Begriff wie "Translation Lookaside Buffer" zu sagen.
Ist nicht praktikabel.Also bleibt nur Fachbegriffe zu erfinden. Und da bastelt man halt üblicherweise was aus bestehenden Wörtern zusammen als neue zu erfinden, weil's wie gesagt einfacher ist.
----
Für alle die sich daran stören gibt's aber eine ganz einfache Lösung: englische Fachbegriffe verwenden. Auf die Englischen Wörter aus denen die zusammengebaut sind hat ein deuschsprachig aufgewachsener Mensch noch keine so starke Prägung. Dadurch fallen die Nachteile grösstenteils weg die sich durch die Wiederverwendung von Begriffen aus dem normalen Sprachgebrauch ergeben.
-
Ich meckere viel lieber über alten code, den ich selbst geschrieben habe, weil ich damit zeigen kann, wieviel ich seit damals dazugelernt habe. Ich denke, dass ich die Geschäftsleitung damit noch wesentlich mehr beeindrucken kann als mit dem Schlechtmachen der Arbeit meiner (Ex-)Kollegen.
-
Ich bin und war an 2 sehr langlebigen Projekten beteiligt (bin jeweils 10+ Jahre nach Projektbeginn zugestoßenen), ebenso wie ich kurzlebige kenne.
Allgemein kann man langlebige Projekte wesentlich eher zu Problemen tendieren, als kurzlebige (Was nicht heißt das man nicht in beiden Fällen Fehler gemacht hat - Wäre auch verwunderlich, es gibt keine perfekten Programmierer, die alles exakt so vorausplanen können wie dann wirklich erforderlich ist).
Meines Erachtens kann man Code durchaus eine grundlegende Qualität zusprechen, und dies auch durch Beobachtung von neuen Entwicklern herausfinden (ich habe in beiden Projekten in der Entwicklungszeit noch weitere neue Entwickler kennen gelernt, und an diesen etwa die gleichen Symptome bemerkt):
- Projekt a: Einarbeitung nur sehr stockend, bis zum Schluss viele alte Codestellen schlicht nicht verständlich. Fehlerkorrekturen nahmen hier mindestens 75% der verfügbaren Zeit ein.
- Projekt b: Bereits innerhalb kürzester Zeit waren alle Neueinsteiger fest im Projektleben, und nur bei wenig Codestellen gab es überhaupt Verständnisprobleme. Fehlerkorrekturen kommen hier zwar vor, liegen aber vielleicht bei 10% der Gesamtzeit.Altcode der nicht angefasst/angepasst werden muss ist selten wirklich schlecht, selbst wenn hier mehrere Codestile/Paradigmenwechsel aufeinander treffen (Wobei es auch wirklich "defekten" Code gibt). Aber Altcode der ständig erweitert wird kann entweder wartbar bleiben oder zu einem unwartbaren Moloch werden, abhängig davon wie im Projekt mit Änderungen vorgegangen wird:
- Projekt a: Änderungen am Altcode waren weitgehend Tabu, Refactoring und Reengineering waren mehr oder weniger verboten. Code wurde immer nur an bestehenden drangepappt, Fehler meist nur durch Workarounds umgangen, wenn die Korrektur Designänderungen nach sich gezogen hätte. Zudem war der Chefentwickler (tut mir Leid das ich es so drastisch ausdrücke, der Eindruck war aber auch bei allen anderen Entwicklern die ich in der Projektzeit erlebt habe) kein guter Entwickler, sei es nun, das er mit dem Studium das Lernen beendet hatte, sei es nun, das auch so sehr viele gravierende Design- und Verständnisfehler in seinem Code waren.
- Projekt b: Hier gibt es zwar auch ein paar schlechte Codehierarchien die zu etwas angewachsen sind, wofür sie nicht designt waren (und sich nun als zu unflexibel herausstellen), es gibt hier aber ein ganz massiven unterschied: Codepflege ist erlaubt/erwünscht und vor allem ist hier auch die Zeit dafür da. Der Code als ganzes ist recht gut verständlich, selbst wenn man einiges anders machen würde. Ich habe selten ein Projekt erlebt das im Verhältnis auf die Entwicklungszeit so sauber war - Auch wenn tatsächlich eine Neuentwicklung ansteht, es haben sich dafür aber auch einige Rahmenbedingungen massiv geändert, und es wird an einigen Stellen eine wesentlich höhere Flexibilität nötig.
-
Weil alter Code nunmal schlecht aussieht, sich die Techniken weiterentwickeln und man manchmal das Gefühl hat dass der Programmierer seinen Code nach dem Motto "Nach mit die Sinnflut" hingekotzt hat.
Habe schon Dinge wie kryptische Funktionsnamen, schlechte Funktionsdefinitionen, eine Datei in der alle globalen Variablen definiert sind und Funktionen voller Seiteneffekte erlebt. Mangelnde Const Correctness (Was ist das?), fehlende Dokumentation, mangelnde Überprüfung von statischen Array's, sind da nur die kleineren Dinge.
Zum Teil sind die Codes auch deswegen entstanden weil die Programmierer eine etwas andere Sichtweise hatte. Da programmierte man noch Bits und Byte lastiger und keiner kam auf die Idee den Code anderes zu benutzen wie ihn der Programmierer benutzte.
-
Bitte ein Bit schrieb:
Mangelnde Const Correctness (Was ist das?)
Ich bin zwar ein Freund von Const Correctness, aber dies ist von den aufgeführten Punkten noch das kleinste Übel. Fehlende oder zumindest spärliche Dokumentations wiederum ich doch eigentlich schon Standard... (Wenn die Kommunikation im Unternehmen stimmt, kann dies aber zumindest zu teilen wettgemacht werden - sofern der Entwickler noch existiert).
Bitte ein Bit schrieb:
Da programmierte man noch Bits und Byte lastiger und keiner kam auf die Idee den Code anderes zu benutzen wie ihn der Programmierer benutzte.
In kleineren Firmen kann noch ein weiterer Grund hinzu kommen:
Man hat den Code niemals für ein Anderes, oder für eine langfristiges Projekt geschrieben, oder gar gedacht das man immer Alleine arbeitet.Faktor 1 kommt unter anderem zum Tragen wenn Projekte nur billig abgehandelt wurden sind (Kunde war nicht bereit für mehr zu zahlen) und irgendein Manager dann meint das es doch da mal ein ähnliches Projekt gab, auf das man zurückgreifen kann...
Und das aktuelle Projekt ist aus einer Studienarbeit entstanden, und wurde einige Zeit alleine entwickelt.
