Warum jammern alle über schlechten Code?
-
Nahezu alle Programmierer, die ich kenne, jammern darüber, wie alt der Code ist, mit dem sie arbeiten müssen, dass man heute alles besser machen würde, wie unüberlegt der Code geschrieben wurde, wie schlecht designt er ist, dass ein kompletter Rewrite nötig wäre, etc. etc. etc.
Und wenn man dann neuen Code anschaut, der von solchen Leuten geschrieben wurde (teilweise unabhängig und ohne Legacy-Abhängigeiten), dann ist der mindestens genauso schlecht!
Was soll das? Gehört Jammern zum Job oder was?
-
Ich kenne da zwar nur ein paar Beispiele, aber deren Code ist ~42 mal besser. Insofern haben die jeden Grund zu jammern.
-
@legacy
Ich beobachte das auch.Meine Gedanken/Mutmassungen dazu:
Programmierer jammern immer über den Code anderer Leute. Weil andere Leute anders denken, andere Konventionen verwenden, andere Patterns, einfach anderen Code schreiben.
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.
Und dann gibt es noch die, die wirklich (deutlich) besseren Code schreiben können als das was sie vorgesetzt bekommen, und sozusagen zu Recht jammern. Das hat dann natürlich auch eine gewisse Vorbildwirkung für neue Programmierer. Die lernen dass über alten Code jammern zum guten Ton gehört. Bzw. dass man das tun muss, wenn man als guter Programmierer angesehen werden möchte.
-
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.
