Diskussion: "Clean Code" von Uncle Bob. Sinnvoll?

mistalan schrieb:
4) Kommentare sind zu 99% unnötig, falsch und gefährlich. Ich habe in Teams mit bis zu 50 Entwicklern gearbeitet. Niemand liest Kommentare wirklich und versteht sie so, wie sie gemeint sind.
Doch, ich lese sehr wohl Kommentare, besonders wenn ich alten Code übernehme.
mistalan schrieb:
Der beste Kommentar ist - neben dem Produktivcode - der Unit Test.
Wenns das nicht gibt?
 
G00fY schrieb:
Man muss halt neue Kollegen intensiver einarbeiten.
Das führt in manchen Firmen dazu das man nur Personen einstellt die das perfekt können um sich einen Teil der Einarbeitung zu sparen. Was wiederum dazu führt das Personen ohne Erfahrung nie dazu kommen diese zu sammeln. Ein Fachkräftemangel ist somit vorprogrammiert.
 
ModellbahnerTT schrieb:
Das führt in manchen Firmen dazu das man nur Personen einstellt die das perfekt können um sich einen Teil der Einarbeitung zu sparen.
Das steht damit nicht im Zusammenhang. Mit "neue Kollegen" meinte ich auch nicht unbedingt Junioren. ;)

War auch mehr aus der Luft gegriffen. Vermutlich ist die Einarbeitung in einer Firma mit klaren Standards sogar einfacher, da sich der Kollegen genau an diesen orientieren kann.
Gute Code-Qualität bedarf natürlich immer Zeit-Invest. Das Einrichten der CI Pipeline und die restlichen von mir beschriebenen Tools zur Qualitätssicherstellung entsteht auch nicht von alleine.
 
Zuletzt bearbeitet:
PHuV schrieb:
Wenns das nicht gibt?

Dann rede ich von unprofessionellem Code. Es gibt auch kein Auto mehr ohne Airbag oder einen Flug ohne einen Sicherheitscheck. Wie gesagt, m.E. fehlen verbindliche Standards in der SE, Unit Tests ist einer davon.
Ergänzung ()

PHuV schrieb:
Doch, ich lese sehr wohl Kommentare, besonders wenn ich alten Code übernehme.

Ja das mag sein aber das gefährliche daran ist, dass du dich auf die Kommentare verlässt. Leider sind diese oft veraltet und irreführend und gaukeln dir Dinge vor, die der Code nicht halten kann.
Ergänzung ()

G00fY schrieb:
Nur kurz zu Punkt 1: Es sollte in jeder Firma/Abteilung/Team verbindliche Standards geben. Es gibt nur eben keine/wenige übergreifende Standards [...]

Natürlich sollte es die geben, nur leider sieht es in der Realität oft so aus, dass es keine oder nur "Placebo" Standards gibt. Freut mich zu hören, dass es bei dir anders läuft.
Aber: Branchenverbindliche Standards sind längst überfällig.
Eine Analogie wäre z.B. das Gesundheitswesen. Stell dir vor jedes Krankenhaus, jeder Arzt hätte seine eigene Definition von Hygiene.
Einer würde sich 30 Sekunden die Hände waschen, ein zweiter nur eine Hand und im dritten Krankenhaus sagte man "Wasser reicht, wir brauchen keine Seife".
Im Prinzip läuft es doch so in der SE und das finde ich schade und gefährlich (s. Airbus A320-214 Unglück)
 
Zuletzt bearbeitet:
Dann ist das in meinen Augen genauso unprofessioneller Code, wie wenn Unit Tests fehlen, und man kann sich auf gar nichts verlassen.

Das ist jetzt sicherlich nicht allgemeingültig, aber ich pflege beispielsweise sehr wohl meine Kommentare ordentlich ein, und den Code, den ich bisher übernommen hatte, war bis auf wenige Ausnahmen sehr wohl gut dokumentiert, so daß die Beschreibung paßte. Und wenn es nicht paßte, hab ich es eben angepaßt.

Ich würde mal behaupten, es ist eine gewisse Stilfrage, eine Philosophie der Arbeitsweise. Es gibt Menschen, die arbeiten ordentlich mit Doku, so daß es auch nachvollziehbar für andere ist, und es gibt leider auch viele Menschen, denen ist das Coden wichtiger als jede Dokumentation.
mistalan schrieb:
Natürlich sollte es die geben, nur leider sieht es in der Realität oft so aus, dass es keine oder nur "Placebo" Standards gibt. Freut mich zu hören, dass es bei dir anders läuft.
Aber: Branchenverbindliche Standards sind längst überfällig.
Eine Analogie wäre z.B. das Gesundheitswesen. Stell dir vor jedes Krankenhaus, jeder Arzt hätte seine eigene Definition von Hygiene.
Da stimme ich Dir vollkommen zu. Leider beweisen manche Firmen hier eine gewaltige Führungsschwäche, gerade wenn sie sich unsicher ist. Ich hab das erst wieder bei einer Firma erlebt, wo die Entwickler eigentlich der Führung auf der Nase tanzen und das kann es nicht sein. Klare Strukturen und klare Anweisungen, und sie hätten viele interne Probleme von vornherein vermieden, aber so... Vor allen Dingen, es tritt nach Jahren kein Lerneffekt ein.
 
Zuletzt bearbeitet:
PHuV schrieb:
Dann ist das in meinen Augen genauso unprofessioneller Code, wie wenn Unit Tests fehlen, und man kann sich auf gar nichts verlassen.

Das sehe ich halt anders. Unit Tests sind ausführbarer Code, wenn sich der Produktivcode ändern dann kompilieren entweder die Tests nicht oder sie schlagen fehl -> Instant Feedback.
Kommentare ändern sich nicht automatisch mit.
Mag ja sein, dass du da sehr penibel und ordentlich bist. Aber anstatt jede Menge Energie in Prosatext fließen zu lassen halte ich es für sinnvoller einfach den Code und die Tests dokumentieren zu lassen.
Wie gesagt ich war vor ein paar Jahren genauso wie du habe alles und jedes kommentiert, aber mit der Zeit festgestellt dass es bis auf die wenigen Ausnahmen keinen Mehrwert bringt
 
  • Gefällt mir
Reaktionen: G00fY
PHuV schrieb:
Leider beweisen manche Firmen hier eine gewaltige Führungsschwäche, gerade wenn sie sich unsicher ist. Ich hab das erst wieder bei einer Firma erlebt, wo die Entwickler eigentlich der Führung auf der Nase tanzen und das kann es nicht sein.
Sehe ich anders. Sauberer Code und Tests liegen in der Verantwortung der Entwickler. Gibt einfach zu viele Entwickler die keine Lust auf Tests schreiben haben, oder keine saubere Architektur nutzen und einfach drauf los schreiben.
Habs selbst oft genug gesehen, wenn wir bestehende Projekte übernommen haben. Zeit darf da keine Ausrede sein. Da fehlt einfach die Kompetenz und Konsequenz vieler Entwickler. Und da gebe ich eben @mistalan Recht, gäbs klarere Standards würde es diese Defizite in dem Ausmaß nicht geben. In der Uni und auch an den praxisnäheren Berufsschulen lernt man Komplexitätsberechnung und die wildesten Sortieralgorithmen. Aber mit konkreten Softwarearchitekturen und Testing wird man erst im Berufsleben konfrontiert.

PS: Die einzigen Fälle in denen ich Kommentare nutze sind FIXME oder TODO comments an Stellen an denen man geblockt ist.:D Dann auch mit Verlinkung auf GitHub issues o.ä.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mistalan
G00fY schrieb:
Sauberer Code und Tests liegen in der Verantwortung der Entwickler. Gibt einfach zu viele Entwickler die keine Lust auf Tests schreiben haben, oder keine saubere Architektur nutzen und einfach drauf los schreiben.
Habs selbst oft genug gesehen, wenn wir bestehende Projekte übernommen haben. Zeit darf da keine Ausrede sein. Da fehlt einfach die Kompetenz und Konsequenz vieler Entwickler. Und da gebe ich eben @mistalan Recht, gäbs klarere Standards würde es diese Defizite in dem Ausmaß nicht geben. In der Uni und auch an den praxisnäheren Berufsschulen lernt man Komplexitätsberechnung und die wildesten Sortieralgorithmen. Aber mit konkreten Softwarearchitekturen und Testing wird man erst im Berufsleben konfrontiert.

Genauso ist es. Einem Manager ist es völlig egal ob wir Clean Code, XP, TDD, MDD, Agile etc. betreiben - und das auch zu Recht. Wir sind die Expertn. Wir geben den Ton an was den Entwicklungsprozess angeht. Das verteidige ich auch bis zur GF.
Was die Unis angeht... ich habe im Studium einiges gelernt aber mit Sicherheit nicht wie man gut und modern programmiert. Das muss sich in Zukungt m.E. einiges ändern.
 
mistalan schrieb:
Was die Unis angeht... ich habe im Studium einiges gelernt aber mit Sicherheit nicht wie man gut und modern programmiert. Das muss sich in Zukungt m.E. einiges ändern.
Das ist auch nicht Aufgabe der Unis.
Eine Uni ist keine Programmierausbildung.

Selbst, wenn man sich auf Software Engineering spezialisiert, geht es da primär um theoretische Konzepte, Analysen, Ideen, PoCs, Einführungen und nicht darum, dass der Arbeitgeber einen Senior Developer zum Junior Gehalt bekommt.

G00fY schrieb:
Sehe ich anders. Sauberer Code und Tests liegen in der Verantwortung der Entwickler. Gibt einfach zu viele Entwickler die keine Lust auf Tests schreiben haben, oder keine saubere Architektur nutzen und einfach drauf los schreiben.
Liegt eigentlich das Pflegen von Kommentaren nicht in der Verantwortung der Entwickler?

PS: Mit mehr Verantwortung muss man auch Experte genug sein, und auch reflektieren können, ob man nicht maßloses Overengineering betreibt.
Dazu gehört teilweise auch Code zu schreiben, den man später wegschmeißt (ggf. mit Absicht).
 
Zuletzt bearbeitet:
new Account() schrieb:
Eine Uni ist keine Programmierausbildung.
Kommt auf den Studiengang an. Ich hatte Module wie "Grundlagen der Softwareentwicklung" und da hätte ich diesbezüglich schon was erwartet. Stattdessen durften wir ein Java Rest Backend mit HTML Frontend programmieren bei dem es nur auf die Lauffähigkeit am Ende ankam.
 
G00fY schrieb:
Stattdessen durften wir ein Java Rest Backend mit HTML Frontend programmieren bei dem es nur auf die Lauffähigkeit am Ende ankam.
Ja, was erwartest du in einem Kurs "Grundlagen der Softwareentwicklung", in welchem der praktische Anteil höchstwahrscheinlich eh optional ist und in welchen in den Anforderungen wahrscheinlich Programmieren I und II (o.ä.) drin steht?
Backend und Rest und Frontend und HTML, JavaScript, etc. kannten die aus PG1 vorher gewiss nicht.

Wie ich schon sagte: PoCs - reicht um ein Verständnis für das Szenario zu bekommen.
 
mistalan schrieb:
Sehe ich anders. Sauberer Code und Tests liegen in der Verantwortung der Entwickler. Gibt einfach zu viele Entwickler die keine Lust auf Tests schreiben haben, oder keine saubere Architektur nutzen und einfach drauf los schreiben.
Nicht so ganz oder wir reden aneinander vorbei. Die Vorgaben müssen von den vorgesetzten Stellen kommen. Wenn es ja gut läuft, geschieht das ja Hand in Hand, oder man hat eine Vorgesetzen, der Ahnung von Entwicklung hat. Und das was ich in über 32 Jahren IT gelernt habe, daß man Entwickler eben NICHT hier freie Hand oder sich selbst lassen sollte (wie es tatsächlich leider oft läuft), dann gibts Chaos und jeder macht so, wie er es denkt, daß es gut und richtig sei. Von denen selbst kommen keine solchen Standards. Wenn da keine Führungsperson leitet und entsprechende personelle Entscheidungsgewalt hat, wird daraus nichts.

Sprich: Vorgabe: Saubere Tests, gute aktuelle Doku und Kommentare, Styleguide. Das muß irgendwo klar als Anweisung stehen und geprüft werden. Das ist ganz klar Vorgesezten- und Führungsarbeit. Entwickler, die das "vergessen" oder sich daran halten, müssen entsprechend angewiesen und sanktioniert werden. Ein Rudel Entwickler kann so was nicht, weil hier alle gleichberechtigt arbeiten, da gäbe es Kompetenzstreitigkeiten.
 
  • Gefällt mir
Reaktionen: #basTi und new Account()
new Account() schrieb:
Das ist auch nicht Aufgabe der Unis.
Eine Uni ist keine Programmierausbildung.

Wieso nicht? Wieso sollte ein (Master) Studiengang Software Engineering o.ä. Studienabgänger nicht zu gut versierten Software Ingenieurn ausbilden, die die defacto Standards beherrschen?
Ich rede hier auch nicht von "Programmierausbildung". Programmieren lerne ich in ein paar Tagen/Wochen.
Ergänzung ()

new Account() schrieb:
Selbst, wenn man sich auf Software Engineering spezialisiert, geht es da primär um theoretische Konzepte, Analysen, Ideen, PoCs, Einführungen und nicht darum, dass der Arbeitgeber einen Senior Developer zum Junior Gehalt bekommt.

Theorie ist gut und notwendig. Vielleicht auf einer (deutschten) Universität noch wichtiger als auf einer FH/BA.
Dies bezieht sich aber m.E. eher auf generelle Studiengänge wie einen Bachelor Informatik.
Ins Besondere dann, falls ich mich für die Forschung etc. interessiere.
Hoch spezialisierte Softwareentwickler sind schon heute so stark gefragt, der Fachkräftemangel ist immens.
Beispiel: unsere letzte Stelle als Anwendungsentwickler war mehr als 6 Monate vakant bis wir sie besetzen konnten.
Ergänzung ()

PHuV schrieb:
Die Vorgaben müssen von den vorgesetzten Stellen kommen.

Das ist leider ein häufiger Trugschluss und zielt nur darauf ab die eigene Verantwortung abzugeben.
"My manager told me to cheat the software in the VW Diesel cars".
"Nobody told me to do Unit Tests".
Bullshit.
Der einzige der für das Einhalten von Coding Standards verantwortlich ist, bin ich selbst.
Ich empfehle hier das Buch The Clean Coder über professionelles Verhalten
 
Zuletzt bearbeitet:
mistalan schrieb:
Hoch spezialisierte Softwareentwickler sind schon heute so stark gefragt, der Fachkräftemangel ist immens.
Beispiel: unsere letzte Stelle als Anwendungsentwickler war mehr als 6 Monate vakant bis wir sie besetzen konnten.
Hochspezialisierte Softwareentwickler mit akademischer Laufbahn sind ja aber gerade nicht die typischen Anwendungsentwickler, sondern Leute, die Kernel schreiben, oder Kryptographie-Software, oder Software für Roboter, KI-Anwendungen, usw.

Da gibt es schon markante Unterschiede.

Für viele KI-Module bei mir z.B. - autonomes Fahren - kann ich gar keine Tests schreiben, weil es viel zu komplex ist, die Realität auch nur irgendwie in solchen Tests abzubilden.
Theoretisch möglich, aber praktisch ist es ungleich viel günstiger einen eigenen Simulator zu schreiben und die Module im Zusammenspiel im Simulator zu beobachten und i.d.R. wöchentlich dann auch noch auf den Teststrecken mit echten Autos.
 
  • Gefällt mir
Reaktionen: new Account()
mistalan schrieb:
Wieso nicht? Wieso sollte ein (Master) Studiengang Software Engineering o.ä. Studienabgänger nicht zu gut versierten Software Ingenieurn ausbilden, die die defacto Standards beherrschen?
mistalan schrieb:
Der einzige der für das Einhalten von Coding Standards verantwortlich ist, bin ich selbst.
Du vermischst da verdammt viele Sachen...

Ja, wenn du Code schreibst, bist du natürlich für deinen Code verantwortlich - außer man macht Pair Programming, dann trägst du nur 50% der Verantwortung. In großen Firmen steckt hinter deinem Commit aber noch eine ganze Reihe weiterer Leute, wie z.B. Code Reviewer. Dann liegt die Verantwortung bei denen, dass der Code die Standards erfüllt bevor er in den master gemerged wird.
Tests schreibt - je nach Typ der Anwendung - auch nicht unbedingt der Software Entwickler, sondern ein dedizierter Tester.
Die Tests führt inzwischen auch meist nicht mehr der Software Entwickler oder Tester aus, sonder das CI System.

Das alles hat aber auch herzlich wenig mit Software Engineering zu tun. Beim Software Engineering geht's um das analysieren und lösen von Problemen - ganz abstrakt. Den Code schreiben die Entwickler. Demnach haben Code Conventions und Tests relativ wenig im Software Engineering Studium zu suchen: Tests tragen nichts zu Lösung der Probleme bei, die die Anwendung lösen soll. Tests tragen zur Lösung der Probleme bei, die der Entwickler nicht bedacht hat.
Genau so wie beim Bau eines Hauses nicht der Architekt und Ingeneur das Haus mauert und das Dach deckt.

In kleinen Software Schmieden ist das natürlich was anderes, da macht oft eine einzelne Person all diese Jobs und ist womöglich gleichzeitig noch Projektmanager.

Und dann gibt's am Ende natürlich immer noch die Punkte Finanzen und Zeitrahmen. Dein Vorgesetzter ist dafür verantwortlich, dass das Projekt im Zeitrahmen bleibt. Das ist - wie in jedem anderen Job auch - eine wirtschaftliche Frage: Es bringt ja nichts, wenn der Code schön einfach verständlich ist, mit 100% Test Coverage, aber das Budget und/oder Zeitlimit derart überzogen wird, dass man am Ende in den finanziellen Ruin stürzt.
Natürlich sollte sowas vor Projektbeginn entsprechend geregelt werden, sodass jeder mit gutem Gewissen Feierabend machen kann. Ohne dass über Nacht der Server abbrennt, weil Budget und Zeit nicht hergegeben haben, dass man alles ausgiebig testet.
Aber wenn's hart auf hart kommt, fügst du dich den Anweisungen von oben, oder du wirst gegangen.

Als Freelancer ist das auch nicht anders. Wenn ich ein festes Zeitbudget bekomme, dann werde ich sicherlich nicht unbezahlt meine Freizeit aufopfern, damit ich ein schönes Kunstwerk abliefern kann - außer es ist Teil des Vertrags. Entweder der Kunde legt noch mal was oben drauf, oder ich muss Abstriche machen. Hängt natürlich auch davon ab, ob der Kunde sich das finanziell und zeitlich leisten kann.[/QUOTE]
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: #basTi, new Account() und PHuV
mistalan schrieb:
Das ist leider ein häufiger Trugschluss und zielt nur darauf ab die eigene Verantwortung abzugeben.
"My manager told me to cheat the software in the VW Diesel cars".
"Nobody told me to do Unit Tests".
Bullshit.
Der einzige der für das Einhalten von Coding Standards verantwortlich ist, bin ich selbst.
Ich empfehle hier das Buch The Clean Coder über professionelles Verhalten
Und wenn Du dann der einzige bist im Team, der das macht? Dann ist zwar Dein Code schön und gut, aber der Rest nicht. Das kannst Du nur beeinflußen, wenn die Kollegen alle vernünftig, klug und nett sind (was leider eher nicht so zutrifft) und auf Dich hören, oder es muß von administrativer Ebene angewiesen werden (was meistens funktioniert, weil die Vorgesetzen, im Gegensatz zu Dir, sanktionieren und weisen können).
benneq hat es wirklich gut ausgedrückt.
benneq schrieb:
Du vermischst da verdammt viele Sachen...
 
PHuV schrieb:
Von denen selbst kommen keine solchen Standards. Wenn da keine Führungsperson leitet und entsprechende personelle Entscheidungsgewalt hat, wird daraus nichts.

Sprich: Vorgabe: Saubere Tests, gute aktuelle Doku und Kommentare, Styleguide. Das muß irgendwo klar als Anweisung stehen und geprüft werden. Das ist ganz klar Vorgesezten- und Führungsarbeit.
So wie du das beschreibst kenne ich das nur aus konservativen Großkonzernen, deren Kerngeschäft dann auch nicht die Softwarentwicklung ist (Versicherungen, Bankenwesen etc).
Jede seriöse IT Firma die ich persönlich oder aus dem Bekanntenkreis kenne, ist in Teams gegliedert die meist eigene Standards und Vorgaben definieren. So ein Team muss natürlich aus den richtigen Leuten bestehen, die solche Sachen auch vorantreiben. Das Team verantwortet aber dann auch die Qualität des Produkts. In einer Umgebung wie du sie schilderst ist die Code-Qualität glaube ich das kleinste Problem.

benneq schrieb:
Das alles hat aber auch herzlich wenig mit Software Engineering zu tun. Beim Software Engineering geht's um das analysieren und lösen von Problemen - ganz abstrakt. Den Code schreiben die Entwickler.
Also Wartbarkeit und Testbarkeit eines Systems sollten ebenfalls ganz oben auf der Prioritätenliste eines Software Engineer stehen. Das sind aus meiner Sicht fundamentale Bestandteile.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mistalan
G00fY schrieb:
Also Wartbarkeit und Testbarkeit sollten ebenfalls ganz oben auf der Prioritätenliste eines Software Engineer stehen. Das sind aus meiner Sicht fundamentale Bestandteile.
Da spricht ja auch absolut nichts gegen. Selbstverständlich sollte die Architektur möglichst angenehm für den Entwickler entworfen werden. Das sehe ich als fundamentalen Bestandteil des Softwareengineerings.
Einfach nur irgendwas zusammenwürfeln, das die Anforderungen erfüllt, kriegt sicherlich auch jeder andere hin. Das habe ich auch schon mit 15 Jahren "erfolgreich" bewerkstelligt mit den unschlagbaren Design Patterns: Copy & Paste, Spaghetti und Blob. :D Dafür braucht's wahrlich kein Studium.

Im Endeffekt wollte ich aber darauf hinaus: Ob, wann, wie und in welchem Umfang Tests geschrieben werden liegt nicht in der Hand des Software Engineers.
 
ascer schrieb:
Hochspezialisierte Softwareentwickler mit akademischer Laufbahn sind ja aber gerade nicht die typischen Anwendungsentwickler, sondern Leute, die Kernel schreiben, oder Kryptographie-Software, oder Software für Roboter, KI-Anwendungen, usw.

Ich finde das kann man so pauschal nicht sagen. Ich kenne einige sehr kompetente Akademiker mit Informatik/Mathematik/Physik Abschlüssen/Promotionen die gerne in der "normalen" Anwendungsentwicklung arbeiten. Dort braucht man die auch.
 
Zurück
Oben