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

[mistalan]

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.

Gleiche Argumentation wie immer: Mein Problem X ist viel kompelxer als alle anderen Probleme Y deshalb kann ich keine Tests schreiben. Ich habe ja nicht gesagt dass es NUR Unit Tests sein sollen. Natürlich braucht es Integrations- und Regressionstest auch mit den von dir genannten Simulatoren. Aber ein unabdinngbarer Grundbaustein ist und bleibt der automatisierte Test in einer dem Produktivcode gleichen Umgebung bez. Programmiersprache, Frameworks. etc.

Ergänzung (30. April 2020)

Du vermischst da verdammt viele Sachen...

Ja und nein. Klar es ging ursprünglich um Kommentare sinnvoll oder nicht bzw. Clean Code allgemein. Ich für meinen Teil trenne da nicht so gern zwischen den einzelen Disziplinen weil sie viel zu eng miteinander verstrickt sind. Aber ja, eine differenzierte Diskussion füre ich gerade nicht, das tut mir leid. Aber dafür mag ich das Getippe in einem Forum nicht gern genug.

Ergänzung (30. April 2020)

Das alles hat aber auch herzlich wenig mit Software Engineering zu tun. Beim Software Engineering geht's um

Ja auch da hast du recht, ích habe den Begriff Software Engineering vereinfacht dargestellt und die ingenieurshafte Tätigkeit dahinter zu kurz gefasst. Das heißt aber nicht, dass ich nicht weiß was es bedeutet bzw. die Punkte die ich genannt habe fallen sehr wohl unter diesen Begriff. Ich habe auch nie behauptet dass meine Antwort Anspruch auf alleinige Richtigkeit bzw. Vollständigkeit hatte.

Dem Rest den du schreibst sehe ich teilweise so, teilweise anders. Aber wie gesagt, ich finde sowas ist schwer per Tasttatur auszudisktutieren.

Ergänzung (30. April 2020)

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.

Gut dass du es ansprichst. Bei meinem jetzigen Arbeitgeber sind wir 6 Entwickler. Als ich dort for 4 Jahren angefangen habe war ich der einzige der das Wort Clean Code etc. überhaupt kannte. Die anderen Entwickler waren weder dumm noch unerfahren, jedoch hatten sie einfach kein know how in dem Thema. Ich habe dann einfach mit meinem Teamleiter geklärt, dass ich jede Woche ein paar Stunden Workshop zu dem Thema halte. Er war zuerst nicht begeistert, ich ließ mich jedoch nicht davon abbringen. Heute arbeiten 5 Entwickler, inklusive meinem Teamleiter, agil nach den CC Methoden, haben ein funktionieredes CI etc.
Ein Entwickler hat das alles nicht so wirklich umsetzen können. Auf eigenen Wunsch ist er jetzt unser Scrum Master und arbeitet eher im Projektmanagement.
Müsste ich auf Dauer mit einem Team arbeiten, dass solche Maßnahmen verweigert, würde ich irgendwann das Unternehmen verlassen und mir was anderes suchen.

Und wie gesagt, ja ich vermische da einiges

Ergänzung (30. April 2020)

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.

Und das ist leider Ausrede Nr. 1: Clean Code [andere professionelle Methoden] sind zu teuer/bezahlt der Kunde nicht, dauern zu lang. Sorry aber auch hier: Das ist Blödsinn.
Wenn ich mir ein Haus bauen lasse, möchte ich dann einen Architekten, Bauingenieur, ... der nach den Prinzipien seines Berufes arbeitet und mir eine Konstruktion nach 3 Monaten für 10.000 € anbietet die noch 100 Jahre steht?
Oder lieber nach 2 Wochen was für 1.000 € was schief ist, wackelt und nach 10 Jahren baufällig ist?
Das gleiche Beispiel kannst du auf die Bereiche Chirurgie, Jura oder eben die Softwareentwicklung anwenden.
Ein Kunde zahlt dir das was du möchtetst wenn du professionell auftrittst und deinen Projektplan objektiv argumentieren kannst. Clean Code, Unit Tests und alle anderen Bereiche die nicht direkt den Produktivcode bestimmen sind für eine professionelle Entwicklung unabdingbar.
Ich arbeite seit ca. 2 Jahren nebenberuflich für einen Kunden der auch zuerst skeptisch war bezüglich Kosten und Zeit. Ich konnte ihn aber relativ einfach davon überzeugen, dass es nicht anders geht. Und jeder der es anders anbietet eben m.E. unprofessionell agiert. Die folgen für eine unprofressionelle Schätzung von Kosten und Zeit sollte jedem einleuchten.

Ergänzung (30. April 2020)

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.

Schade dass du so denkst. Denn es ist nicht so.

Ergänzung (30. April 2020)

Er hat auch nicht gesagt, dass diese nicht in die normale Anwendungsentwicklung einsteigen würden/könnten

Es hat sich halt so gelesen. Nicht jeder Dipl./Master Absolvent möchte KI machen. Ich habe meinen Master in Computer Science ("nur" FH wenn ihr arrogant sein wollte und kann mir nichts besserers Vorstellen als Anwendungsentwicklung. Das ist aber natürlich jetzt sehr subjektiv.

 

[ascer]

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.

Siehe Post von @new Account(): meine Aussage war, dass diese Menschen i.d.R. keine normalen Anwendungsentwickler sind. Das es Ausnahmen gibt, ist klar. In der Masse ist ihre Ausbildungsabsicht aber ein spezialisierter Software Engineer zu sein, sprich Algorithmik, Data Science, Robotik, Simulation usw. usf.

Gleiche Argumentation wie immer: Mein Problem X ist viel kompelxer als alle anderen Probleme Y deshalb kann ich keine Tests schreiben. Ich habe ja nicht gesagt dass es NUR Unit Tests sein sollen.

Finde ich gar nicht. Ich wollte nur darstellen, dass es Bereiche in der Softwareentwicklung gibt, die sich sehr von typischer Anwendungsentwicklung unterscheiden und das es dort schwierig bis teilweise unmöglich sein kein, z.B. mit UnitTests zu arbeiten.

Das negiert ja nicht die Kernaussage, dass das übliche Stück Software kompakt und selbsterklärend sein sollte sowie das Anwendungsfälle mit UnitTests abgedeckt sein sollten.

Es sollte nur aufzeigen, dass pauschalisierte Aussagen wie...

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.

...mit den 99% zu hoch greifen.

Und das die Aussage vom Anwendungsfeld abhängt.

 

[PHuV]

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.

Nope, ich war in einer SW-Bude, und da wurde das genau so gemacht. Und klar konntest innerhalb des Teams noch einiges machen, aber die Vorgabe war sehr wohl firmenübergreifend.

Ergänzung (30. April 2020)

Gut dass du es ansprichst. Bei meinem jetzigen Arbeitgeber sind wir 6 Entwickler.

Glück gehabt, und das ist jetzt nicht arrogant gemeint, Kleinkram. Sei mal in Teams vom 20 aufwärts, da wirds spannend. Und da bekommst Du als Einzelner nicht eben mal so das Wort. Geschweigen den in Teams mit mehreren hundert Entwicklern.

Und wie gesagt, ja ich vermische da einiges

Ja, tust Du, und Du kannst nun mal nicht Deine "kleine" Situation auf alle anderen übertragen. Wenn das so einfach wäre, täts ja jeder.

Und das ist leider Ausrede Nr. 1: Clean Code [andere professionelle Methoden] sind zu teuer/bezahlt der Kunde nicht, dauern zu lang. Sorry aber auch hier: Das ist Blödsinn.

Sorry, dann hast Du keine Ahnung, wie es da draußen wirklich läuft und lebst in einen Luftblase. Es ist schön, daß es bei Dir so klappt. Das ist aber nun mal selten der Fall.

Wenn ich mir ein Haus bauen lasse, möchte ich dann einen Architekten, Bauingenieur, ... der nach den Prinzipien seines Berufes arbeitet und mir eine Konstruktion nach 3 Monaten für 10.000 € anbietet die noch 100 Jahre steht?
Oder lieber nach 2 Wochen was für 1.000 € was schief ist, wackelt und nach 10 Jahren baufällig ist?

Dein Vergleich mit dem Hausbau hinkt, weil eben die meisten Firmen IT nur als "Beiwerk" sehen, bis heute. Traurig, aber wahr. Geld wird nur ausgegeben, wenn es notwendig wird.

Ein Kunde zahlt dir das was du möchtetst wenn du professionell auftrittst und deinen Projektplan objektiv argumentieren kannst.

Du lebst wirklich in einer Luftblase. Nicht aufgefallen, daß der Markt (was so gegen 2007-10, kann mich nicht mehr sogenau erinnern) wirklich bzgl. Kosten eingesackt ist. Dann hast Du Glück, daß Du in den meisten Fällen wohl ausgesiebt wurdest, ohne daß Du es merkst. Und nein, der Kunden zahlt nicht daß, was Du willst, sondern was er für notwendig hält und sich leisten kann.

Du hast theoretisch recht, keine Frage. Aber nochmals, Du bist wirklich in einer Blase, laß Dir das von jemanden sagen, der in über 32 Jahren im Geschäft ist und heute auch Aquise macht. Es wird gedrückt, wo es geht. Du hast nur eine Chance, wenn Du etwas bieten kannst, was andere nicht bieten können, erst dann kannst Du einigermaßen Preise nach oben schrauben. Ansonsten wird gleich nach Indien oder Osteuropa ausgelagert, weil billiger. Das es im Endeffekt nicht billiger ist, wissen wir beide, trotzdem passiert das jeden Tag. Ich hab schon 2 SW-Firmen erlebt, die so den Bauch runtergingen.

Und ja, ich bin auch einer, der es ordentlich macht und realistisch schätzt. Fakt ist aber, daß wir dadurch sehr wohl einige Aufträge verloren haben, weil für die Kunden zu teuer war. Wir können uns glücklich schätzen, daß wir auch - trotz Corona - genug von anderen gefragt sind, und dadurch nicht jeden Auftrag gewinnen müssen. In anderen Firmen, die um ihre Existenz kämpfen müssen, sieht das eben anders aus.

Fühle Dich jetzt bitte nicht angegriffen oder sonstwas und nimm es bitte bloß nicht persönlich. Du hast Deine Erfahrung, ich hab meine, und andere ihre. Leute wie Du machen in meinen Augen immer genau den Fehler, daß sie ihre Situation verallgemeinern. Auch wenn es gut gemeint von Dir ist, und Du wirklich im Prinzip richtig liegst. Fakt ist, es wird Dir nicht jeder Kunde um den Hals fallen, wenn Du professionell auftrittst und alles rechtfertigen kannst, geschweige denn er wird Dir alles bezahlen. Das ist absoluter Quatsch. Viele bezahlen Dich dafür, daß Du was so machst, das es geht, und nicht dafür, den Code besser zu machen, wenn er so funktioniert.

Nur mal so aus der Praxis, ich bin bei ÖD und Behörden auch unterwegs. Ich kämpfe seit Jahren bei einer um eine fucking SSD für einen Datenbankserver, weil die Platten zu langsam sind und sie allen Ernstes über eine Netzwerkfreigabe arbeiten. Keine Chance. Und was kostet so eine SSD? Genau... Klar würde ich vieles gerne besser und effizienter machen. Traurigen Realität ist aber, der Kunde zahlt es nicht.

 

[G00fY]

@PHuV Also ich glaube nicht das @mistalan aus einer Blase berichtet. Du beschreibst hier wirklich das komplette Gegenteil vom dem was ich von professionellen Software-Firmen kenne. Für mich liest sich das eher nach Großagentur oder altem Großkonzern.

Will hier nicht prahlen und möchte es vermeiden Firmen zu nennen, aber ich kenne viele Freunde und Ex-Kollegen die bei sehr großen deutschen sowie internationalen Software-Unternehmen arbeiten. Rede hier auch von Firmen mit mehreren hundert Entwicklern pro Standort. Dort wird natürlich auch teils an eigenen Produkten gearbeitet, sodass die Qualitätsansprüche evtl. anders sind. Ich arbeite persönlich zB an einem Fremdprodukt mit weit über 1M aktiven Endnutzern. Dort läuft das nicht im Ansatz so ab wie von dir beschrieben. Also wäre dann schon einem ziemlich große Blase.

Sei mal in Teams vom 20 aufwärts, da wirds spannend.

20 Leute ist überhaupt keine praktikable Zahl für eine Teamgröße. Wie ich vorhin schon schrieb, bei solchen Unternehmensstrukturen ist die Softwarequalität das geringste Problem. Das hat auch nichts mit der Unternehmensgröße oder Anzahl der Entwickler im Unternehmen zu tun. Könnte da genug Beispiele liefern.

 

[new Account()]

Und wer hat jetzt Recht?
Ich weiß nicht, ob die Diskussion auf diesem Weg zu einem Ergebnis kommen kann.

 

[ascer]

Viele bezahlen Dich dafür, daß Du was so machst, das es geht, und nicht dafür, den Code besser zu machen, wenn er so funktioniert.

I.d.R. sogar eher für ein gutes Gefühl, aus Eigeninteressen heraus oder einfach wegen Vitamin B.

Die F&E-Tochter des Mutterkonzerns, bei dem ich arbeite, ist Technologielieferant für viele verschiedene Stellen im Mutterkonzern.
Mitunter gibt es Manager, die dir nicht nur erzählen, dass XY Personenstunden zu teuer ist, sondern auch noch, wie sie Problem ABC gerne gelöst hätten. Und das sind i.d.R. BWL-Leute, die nicht nur Softwareentwicklung nicht verstehen, sondern die allen ernstes über Forschungsthemen im KI-Bereich entscheiden möchten.

Zumindest in der Automobilbranche habe ich da noch kein Gegenbeispiel gesehen.

Wenn ich einen Prototypen im Bereich autonomes Fahren mit meinem Team ordentlich umsetzen kann, dann nur weil:
- der Manager mit einer anderen Lösung vorher gehörig gegen die Wand gefahren ist (manchmal auch im wahrsten Sinne des Wortes^^)
oder
- weil ich durch Publikationen o.Ä. irgendwann auf einer Veranstaltung, Symposium, ... mal dem Manager vom Manager die Hand geschüttelt habe

Die Software oder Qualität ist denen nicht nur vollkommen egal, die haben davon auch gar keinen Plan und können das in keinster Weise beurteilen oder auch nur irgendwie wertschätzen.

 

[G00fY]

Und wer hat jetzt Recht?
Ich weiß nicht, ob die Diskussion auf diesem Weg zu einem Ergebnis kommen kann.

Um Recht haben geht es sich überhaupt nicht.

Aber gefühlt kann man jede Diskussion über Softwarestandards und Qualität abwürgen mit Sätzen wie

Sorry, dann hast Du keine Ahnung, wie es da draußen wirklich läuft und lebst in einen Luftblase.

Glaube einfach hier diskutieren Leute aus sehr unterschiedlichen Branchen. Nur weil jemand die Sicht aus einer anderen Branche beschreibt muss das aber nicht heißen, dass dieser in einer Blase lebt. Im Endeffekt kommts auf die Unternehmenskultur an. Wenn natürlich alles von oben dirigiert wird bleibt den Entwicklern unten wenig Handlungsspielraum. Meiner Erfahrung nach ist diese Arbeitsweise aber nicht mehr zeitgemäß und nicht umsonst setzen die erfolgreichen Softwarefirmen längst auf andere Ansätze.

Aber sollte doch wohl klar sein, dass in einer Agentur wo nur billig zählt und der Vertrieb um jeden Auftrag bangt am Ende andere Softwarequalität bei raus kommt, als in einer Firma die eigene oder partnerschaftlich Produkte entwickelt.

 

[ascer]

Glaube einfach hier diskutieren Leute aus sehr unterschiedlichen Branchen.

In der Tat.

Genau deshalb wollte ich auch, mit einem Bezug auf die jeweilige Perspektive, auf diesen Aspekt eingehen:

Es sollte nur aufzeigen, dass pauschalisierte Aussagen wie...

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.

...mit den 99% zu hoch greifen.

Das man die typische Schleife nicht kommentieren brauch, insbesondere wenn alles sauber, mimimalistisch programmiert und selbsterklärend benannt ist, ist auf jeden Fall klar.
Es gibt aber schon komplexe Bereiche, wo ich Kommentare als unabdingbar ansehen würde.

 

[PHuV]

@PHuV Also ich glaube nicht das @mistalan aus einer Blase berichtet. Du beschreibst hier wirklich das komplette Gegenteil vom dem was ich von professionellen Software-Firmen kenne. Für mich liest sich das eher nach Großagentur oder altem Großkonzern.

Nope, sind 2 Startups darunter, einer mit ca. 800 MAs und davon ungefähr 700 Entwickler weltweit in verschiedenen Teams, überwiegend Osteuropa. Erschreckende Zustände dort. Ich wurde dort als Notadmin im Devops Bereich eingesetzt, und hab mich sogar als PL angeboten, weil die ihre Entwicklung und Entwickler nicht in den Griff bekommen haben. Wollten sie aber nicht, da ich "zu teuer" war. Gab aber einige Gruppenleiter, die mich sofort dafür haben wollten. Da wurden Leute im Ausland am WE Abends und zu Feierlichkeiten rausgezogen, weil deren Code sich nicht übersetzen lies oder keiner wußte, wie die Zusammenhänge waren, außer dieser eine Entwickler. Kein Witz.

Um Recht haben geht es sich überhaupt nicht.

Richtig, sondern um Erfahrungen.

Aber gefühlt kann man jede Diskussion über Softwarestandards und Qualität abwürgen mit Sätzen wie

Ja, zugegeben, aber mich hat so ein Satz wirklich aufgeregt:

Ein Kunde zahlt dir das was du möchtest wenn du professionell auftrittst und deinen Projektplan objektiv argumentieren kannst.

Im meine Augen zeugt es von tiefer Arroganz (den ich mistalan hier an dieser Stelle ganz klar nicht unterstelle, er ist ok, nur überambitioniert ) oder von einem sehr unreifen Unwisssen, oder er hatte hier wirklich absolutes Glück.
Mein Argument ist beispielsweise auch, daß ein Kunde mit diesen Maßnahmen im Endeffekt günstiger kommt. Interessiert aber manche nicht, weil sie ihr Budget mit aller Gewalt halten müssen. Dann müßte man aber bgzl. Projektplan und Laufzeit gewaltige Kompromisse machen. Was dann dabei rauskommt, kann sich ja jeder ausmalen, ich sag nur mal als Negativbeispiel Boing 737
https://www.golem.de/news/boeing-73...-zwei-weitere-softwarefehler-2004-147785.html
https://www.manager-magazin.de/unte...mt-weiteren-softwarefehler-ein-a-1261378.html
https://www.tagesschau.de/wirtschaft/boeing-mails-sicherheitsmaengel-101.html
Sowas finden wir eben auch bei Siemens und Co. Warum?

Glaube einfach hier diskutieren Leute aus sehr unterschiedlichen Branchen. Nur weil jemand die Sicht aus einer anderen Branche beschreibt muss das aber nicht heißen, dass dieser in einer Blase lebt.

Ich bin in vielen Branchen unterwegs, und hab so ca. 4-6 neue Kundenkontakte pro Jahr und bin hier entweder direkt oder indirekt tätig. Geld verschenken tut keiner. Und der Witz ist, gerade die es am nötigsten haben und nicht mal über so schlechte Geldreserven verfügen, investieren am wenigsten, man mag es nicht glauben.

Im Endeffekt kommts auf die Unternehmenskultur an. Wenn natürlich alles von oben dirigiert wird bleibt den Entwicklern unten wenig Handlungsspielraum. Meiner Erfahrung nach ist diese Arbeitsweise aber nicht mehr zeitgemäß und nicht umsonst setzen die erfolgreichen Softwarefirmen längst auf andere Ansätze.

Natürlich. Wenn es gut läuft, ist es ein zweiseitiger Prozess, wo Wissen und Erkenntnis von unten nach oben fließt und umgekehrt. Beispielsweise haben wir bei uns mittlerweile einige Scrum-Master im Einsatz, die Firmen helfen, erst mal auf eine andere Weise Prozesse und Unterstützung zu bieten, was sehr gut angenommen wird. Machen wir uns nichts vor, SW Entwicklung entwickelt sich schnell weiter, selbst Jahrzehnte lang etablierte und erfolgreiche Firmen müssen sich neu ausrichten, wenn der Erfolg schrumpft. Da sitzen Leute, die über 30-40 Jahre Entwicklungserfahrung haben, die dreht man eben nicht über das Wochenende um, ebenso die Führungskräfte.

Aber sollte doch wohl klar sein, dass in einer Agentur wo nur billig zählt und der Vertrieb um jeden Auftrag bangt am Ende andere Softwarequalität bei raus kommt, als in einer Firma die eigene oder partnerschaftlich Produkte entwickelt.

Das ist aber die Situation, die wir aktuell - dank Corona - haben. Bei uns wurden auch große Entwicklungsprojekte mit großen Firmen z.B. die, die aktuell kaum fliegt), von heute auf 7 Kollegen "beurlaubt" bzw. aus den Projekten entfernt, Kurzarbeit.
Nimm Ausschreibungen bei Behörden und ÖD, da gewinnt nur derjenige, der das günstigste Angebot abgibt, nicht das realistische. Brauchen wir nur mal als Extrembeispiele zu BER und Stuttgart 21 schauen.

Warum kommen wir wohl als Externe so oft in diese Firmen rein? Nach der Logik von mistalan sollte er nicht von dem Kunden stehen, er sollte mit diesen Kenntnissen sofort eingestellt werden. Macht man aber nicht, wie die Situationen in den Firmen dramatisch zeigen: Es ist permanent an vielen Stellen unterbesetzt, es fehlen permanent Entwickler, DevOps, Scrum-Master, PLs, usw. Wir hatten vor 2 Jahren die Situation, daß wir locker das 3fache unserer Leute hätten allein bei einem Konzern unterbringen können, so stark war der Bedarf. Jetzt ist es genau umgekehrt, und gut war es, daß unsere Chefs so umsichtig dachten und nicht mit aller Gewalt gewachsen sind.

Nochmal die Frage, warum kommen wir als Externe da rein? Ganz einfach, weil die Firmen selbst nicht einstellen, warum auch immer. Und dann schauen wir uns mal an, warum nicht. Wir kennen doch alle die Diskussionen um Fachkräftemangel und so. Dann schaut Euch mal die Kommentare bei Heise und Co. dazu an. Fakt ist (und das weiß ich, weil ich mich mal testweise bei einigen beworben hatte), daß die Firmen einfach nicht fachgerecht bezahlen wollen. Wer über 40 und 50 ist, und entsprechendes Know-How hat, wird kaum eingestellt, weil "zu teuer". Nicht mal ein Bewerbungsgespräch. Schraubt man den Preis wirklich unrealistisch runter (ich habs selbst getestet), siehe da, so schnell konnte ich gar nichts schauen, wie ich plötzlich Gespräche hatte. Aber wer selbst Familie und finanzielle Verpflichtigungen hat, hat gar keine Chance, da reinzukommen, weil er es sich nicht leisten kann. Und so nimmt man dann doch die unerfahrenen Kollegen frisch von der Uni, weil günstig. Und so sehen dann auch entsprechend die Projekte aus. Ich weiß das deshalb so gut, weil wir dann immer teuer eingekauft werden und dazugeholt werden müssen, um noch zu retten, was zu retten ist. Hier werden permanent einige große Projekte in den Sand gesetzt.

Wie meinte es ein leider verstorbener Kollegen: "Wenn die Kunden lernfähig wäre, wären wir schon lange arbeitslos!". Tatsache ist aber, wir sind es nicht.

Keine Frage, es ist nicht DIE Erfahrung, aber es ist eine Erfahrung von vielen.

 

[new Account()]

Richtig, sondern um Erfahrungen.

Ist das so?
Es schildert nun jeder, dass XY das beste ist (teilweise universell bzw. ultimativ), weil er die und die Erfahrung (welche von außen nicht nachvollzogen werden kann) gemacht hat.

Soweit war ich vor dem Thread schon - das Internet ist voll davon (und das gleiche gibts dann auch noch bei z.B. funktionaler Programmierung vs Objektorientierung vs Mix vs prozedural 🤦‍♂️ ).
Also ich würde schon gerne etwas draus lernen.

Daher fände ich es schon nicht schlecht, wenn man auf einen Konsens hinarbeiten würde (und sei es nur, dass es jederzeit auf die individuelle Situation drauf ankommt).

 

[PHuV]

Daher fände ich es schon nicht schlecht, wenn man auf einen Konsens hinarbeiten würde (und sei es nur, dass es jederzeit auf die individuelle Situation drauf ankommt).

Du hast ja Deine Antwort bereits. Konsens ist schwierig, einfach aus dem Grund, jeder ist anders, jede Kundensituation ist anders. Rechthaberei oder Besserwisserei kommt bei entsprechenden Kunden auch nicht an. Ich hatte sogar mal die groteske Situation mit einem Schweizer Kunden, der gute Empfehlungen basierend auf Erfahrungen ausdrücklich verlangt hatte, und als sie in seine Kostenplanung nicht gepaßt hatte, sehr brüskiert und abweisend reagiert hatte.

Es gibt Kunden, die sind handzahm, denen schlägt man was vor, macht es gleich richtig und gut, und sie legen ohne Probleme das Geld hin und sind dann auch meistens sehr zufrieden. Und es gibt Kunden, wo Du 20mal hin- und her diskutieren mußt, alle guten Vorschläge abgebügelt werden, man sie sogar vor den Risiken und Problemen warnt. Dann passieren genau diese Probleme und bekommt sie sogar in die Schuhe geschoben. Deshalb gibts bei mir auch in den meisten Fällen immer Protokolle, wo genau alles festgehalten wird. Selbst das nützt nichts, weil dann sich rausgeredet wird, man hätte sie noch mehr darauf hinweisen und warnen müssen... man sitzt dann nur mit dem Facepalms da und möchte eigentlich nur weinen.

Clean Code ist ein gutes Konzept, genauso wie Standards, gute Style Guides, Unit Tests usw. Ich habe als Berater gelernt, auch mal ungünstige Situationen stehen zu lassen. Wie gesagt, ich werde für einen Auftrag bezahlt. Läuft der gut, ist die nächste Beauftragung meistens kein Problem mehr. Veränderungen in verhärmten Umgebungen brauchen Zeit, und die Zeit hat man nur, wenn man dann auch wieder eingekauft wird. Und dann erst kann man schrittweise und gemächlich den einen oder anderen Prozess zur Optimierung und Verbesserung einleiten. Das dauert aber - aus meiner Erfahrung - oftmals mehrere Jahre. Oder es knallt so derartig, daß der Kunde gar nicht mehr anders kann. Daher, immer sofort und alles gleich umzuwerfen - auch wenn die Absicht gut gemeint ist und dem Kunden auch gut tun würde - ist nicht immer hilfreich, kann auch schaden.

Daher sollte man auch eine sehr gute Sozialkompetenz entwickeln, psychologische Fertigkeiten entwickeln. Teamarbeit hat eben nicht nur mit Sach- und Fachlichkeit und Kompetenzen zu tun, sondern eben viel mit sozialem Gefüge. Und das Klischee erfüllt sich leider sehr oft, gute Entwickler sind sozial nun nicht so gut ausgebildet. Für positive Veränderungen muß man an mehreren Ebenen arbeiten, und das ist nicht so einfach, wie es sich anhört. Guten Kundenbeziehungen zeichnen sich dadurch aus, daß man partnerschaftlich miteinander umgeht, genauso wie Führung und Mitarbeitern in Teams.

Mein Fazit ist, wenn der Clean Code Einsatz so einfach wäre, wie jeder es hinstellt, hätte es ja jeder, und wir hätten die diversen Problemen in Firmen überhaupt nicht. Tatsachen aus vielen Projekterfahrungen lehrte mich leider etwas anderes. Trauriger ist noch, daß immer wieder die gleichen Fehler wieder und wieder gemacht werden. Da nützt ein Clean Code ebensowenig wie Vernunft und Verstand, wenn es an anderer Stelle fehlt.

Und nur mal so eine menschliche Eigenschaft in den Raum geworfen, es gibt sehr wohl Entwickler, die mit Absicht so nicht arbeiten. Damit sind sie unabkömmlich, ersetzbar, wichtig, weil nur sie den Code und die Zusammenhänge verstehen, und sonst kein anderer. Gerade manche Freelancer glänzen damit, so haben sie den Kunden immer in der Tasche.

 

[mistalan]

...mit den 99% zu hoch greifen.

Natürlich ist es das. Genauso wie die 100% Code Coverage die man beim Testen anstrebt. Es sollte lediglich darauf hinweisen, dass die meisten Kommentare überflüssig sind. Mach halt ne 90 oder ne 80 draus

Danke für die Klarstellung deiner anderen Punkte

Ergänzung (1. Mai 2020)

Nope, ich war in einer SW-Bude, und da wurde das genau so gemacht. Und klar konntest innerhalb des Teams noch einiges machen, aber die Vorgabe war sehr wohl firmenübergreifend.

Ergänzung (30. April 2020)

Glück gehabt, und das ist jetzt nicht arrogant gemeint, Kleinkram. Sei mal in Teams vom 20 aufwärts, da wirds spannend. Und da bekommst Du als Einzelner nicht eben mal so das Wort. Geschweigen den in Teams mit mehreren hundert Entwicklern.

Ja, tust Du, und Du kannst nun mal nicht Deine "kleine" Situation auf alle anderen übertragen. Wenn das so einfach wäre, täts ja jeder.

Sorry, dann hast Du keine Ahnung, wie es da draußen wirklich läuft und lebst in einen Luftblase. Es ist schön, daß es bei Dir so klappt. Das ist aber nun mal selten der Fall.

Hm und da ist sie wieder die völlig unangebrachte Arroganz. Aber hättest du meinen ersten Post gelesen wüsstest du, dass ich in größeren Teams gearbetiet habe. War 7 Jahre bei Accenture. Knapp 400.000 Mitarbeiter weltweit, solltest du kennen. Unsere Tochter Firma entwickelte Standardsoftware im Bereich Konsumgüter.
Am Standord ca. 200 Personen in der Entwicklung, davon 100 Kernetnwicklung - wie ich - der Rest Customizing Projektgeschäft. Unsere Kunden waren groß, sehr groß. Coca Cola, Pepsi, Bacardi, Inbev etc. Lizenzen im 7-stelligen Bereich. Und weiter? Hat mich das in irgend einer Weise dazu gebracht nicht sauber oder nach Clean Code zu arbeiten oder meine Tests zu vernachlässigen? Nein. Natürlich ist es etwas komplizierter mehr Entwickler/Architekten/Product Owner unter einen Hut zu kriegen aber das ist Aufgabe von HR/Management.
Es war mein 3ter Arbeitgeber und der este bei dem ich gelernt habe nach professionellen Prinzipien zu arbeiten.
Und glaub mir es gab riesigen Gegenwind im mittleren bis hohen Manangement, aus den allseits bekannten Argumentationen (zu teuer, dauert zu lang, Kunde springt ab...). Und? Sachlich argumentieren und es trotzdem machen. Was ist passiert? Delivery In-Time, Budget und Quility in den allter meisten Fällen.
Also bitte sag mir nicht ich hätte keine Ahnung wie es da draußen funktioniert.

Ergänzung (1. Mai 2020)

Du lebst wirklich in einer Luftblase. Nicht aufgefallen, daß der Markt (was so gegen 2007-10, kann mich nicht

Du hast theoretisch recht, keine Frage. Aber nochmals, Du bist wirklich in einer Blase, laß Dir das von jemanden sagen, der in über 32 Jahren im Geschäft ist und heute auch Aquise macht.

Nein ich lebe in keiner Blase. Ich denke du tust das auch nicht. Ist auch relativ irrelevant ob du nun 15 oder 32 Jahre im Beruf bist. Bzw. ich sehe es auch so, je länger man dabei ist, desto verhärteter und unlockerer wird man. Habe ich auch an mir entdeckt. Ich habe nicht ganz deine Berufserfahrung, aber ich habe nicht immer in der IT gearbeitet. Meine ersten Jahre habe ich als Consultant verbracht. Hat mir einiges gelehrt, ist aber abosulut nicht meine Welt (wenn die Leute wüssten wie es in den Banken und Versicherungen so abgeht... aber egal anderes Thema).

Ich will nur sagen, dass wir beide eine andere Herangehensweise habe. Wenn du deine Erfahrungen so gesammelt hast , dann möchte ich das natürlich nicht abstreiten oder klein reden. Aber: Meine Herangehensweise ist eine andere und für mich die völlig angenehmere. Ich, oder im Prinzip wir, sind in einer Luxusposition weil die IT nicht mehr wegzudenken ist und es immer mehr Jobs in diesem Bereich geben wird. Es gibt keinen Weg zurück, "Developers rule the world. Although the world doesn´t know yet".

Es wird von uns ERWARTET und zwar zu recht , dass wir so professionell wie möglich arbeiten, so wie in jeder anderen Dispziplin auch. Für mich zählt Clean Code darunter. Wenn es das für dich nicht wert ist zu kämpfen ist das deine Sache, aber bitte benutze nicht deine Angst vor persönlichen Konsequenzen anderen Entwicklern zu erzählen in großen Firmen, mit großen Kunden, geneinem Chefs könnte man diese Professionalität nicht wahren. Man hat immer eine Wahl. Und ja ich mein Angst. Das ist doch der Motor von eigentlich Top Ausgebildeten, Dinge nicht anzusrepchen oder zu tun. Nur Angst wovor? Kritik? Häme? Kündigung?
Meine Erfahrung zeigt, dass diese Ängste i.d.R. unbegründet sind. Und wie gesagt, wenn ich einen cholerischen Chef habe, der mich dauerns anschreit und mir mit Kündigung oder sonstwas droht.. dann ziehe ich meine persönlichen Konsequenzen denn in so einem unprofessionellem Umfeld möchte ich nicht arbeiten.

Ergänzung (1. Mai 2020)

Und wer hat jetzt Recht?
Ich weiß nicht, ob die Diskussion auf diesem Weg zu einem Ergebnis kommen kann.

Über Recht und Unrecht sollten nur Gerichte urteilen
Ich sage es mal so: Solange sich unsere Zunft der Entwickler ÜBERHAUPT mit dem Thema Professionalität und den damit verbundenen Methodiken wie Clean Code befasst sind wir auf einem guten Weg.

Ergänzung (1. Mai 2020)

Ist das so?
Es schildert nun jeder, dass XY das beste ist (teilweise universell bzw. ultimativ), weil er die und die Erfahrung (welche von außen nicht nachvollzogen werden kann) gemacht hat.

Soweit war ich vor dem Thread schon - das Internet ist voll davon (und das gleiche gibts dann auch noch bei z.B. funktionaler Programmierung vs Objektorientierung vs Mix vs prozedural 🤦‍♂️ ).
Also ich würde schon gerne etwas draus lernen.

Daher fände ich es schon nicht schlecht, wenn man auf einen Konsens hinarbeiten würde (und sei es nur, dass es jederzeit auf die individuelle Situation drauf ankommt).

Es sollte halt sachlich bleiben. Streiterein um die Frage Funktional oder Objektorientierte Programmierung sind halt völlig fehl am Platz weil man das pauschal nicht beantworten kann.
Stell dir doch einfach die Frage: Professionell oder weniger professionell?
Wenn du ersteres wählst hast du die Frage ob Clean Code oder nicht schon beanbtwortet.
Ob man nun jeden Aspekt in CC dogmatisch 1:1 umsetzen sollte ist eigentlich auch schnell erklärt: nein soll man nicht.

 

[PHuV]

Es wird von uns ERWARTET und zwar zu recht , dass wir so professionell wie möglich arbeiten, so wie in jeder anderen Dispziplin auch. Für mich zählt Clean Code darunter.

Dann mal eine ganz einfache ketzerische Gegenfrage: Ist Professionalität nicht auch dazu zu liefern, was der Kunde will? Wenn der Kunde zufrieden ist, ist das IMHO genauso erfüllt.

Wenn es das für dich nicht wert ist zu kämpfen ist das deine Sache, aber bitte benutze nicht deine Angst vor persönlichen Konsequenzen anderen Entwicklern zu erzählen in großen Firmen, mit großen Kunden, geneinem Chefs könnte man diese Professionalität nicht wahren.

Woher willst Du wissen, ob ich Angst habe oder nicht? Und es gibt nun mal, auch wenn Du es vielleicht nicht glauben magst, sehr wohl gemeine Chefs und Menschen da draußen, die Logik und Vernunft nicht zugänglich sind. Gerade in den Führungsetagen finden sich mehr Psychopathen als man denken kann.

Keine Sorge, Angst brauch ich mir keine machen. Ich machen meinen Job so professionell wie möglich, und wenn der Kunde das erfolgreich verhindert, sein Problem, nicht meines, dann gibts nur das, was auf dem Papier steht, und mehr nicht. Ich bin ja als Externer meistens dann eh weg. Kämpfen tu ich mit dem Kunden grundsätzlich nicht, wenn er sich nicht überzeugen läßt, Pech gehabt. Wie gesagt, wenn ich recht habe (und das habe ich in den meisten Fällen) stehen sie nach ein paar Monaten eh bei mir wieder auf der Matte und fordern mich an. Wie Du ja richtig sagst, Schlampigkeit oder schlechte Arbeit rächt sich eben irgendwann. Aber es gibt nun mal Branchen, wie die erwähnten Banken, da ist bei einigen allein durch ihre Strukturen schon Hopfen und Malz verloren.

 

[Jesterfox]

Dann mal eine ganz einfache ketzerische Gegenfrage: Ist Professionalität nicht auch dazu zu liefern, was der Kunde will?

Die Frage ist echt ketzerisch und ne Gratwanderung... wenn der Kunde offensichtlich Bullshit will mit dem er sich so richtig in Probleme reiten wird ist die Frage ob man da wirklich mitgehen will. Ab nem gewissen Grad würd ich da auch ablehnen wenn sich der Kunde nicht überreden lässt, wer weiß ob das nicht mal negativ auf einem zurückfällt.

 

[PHuV]

Wenn man es schriftlich fixiert, daß es Kundenverantwortung ist, und man auf die Probleme vorher hingewiesen hat, wo ist das Problem?

 

[Jesterfox]

Die Außenwirkung die evtl. entstehen kann wenn das Projekt einen etwas größeren Bekanntheitsgrad erlangt (z.B. weil es die Medien aufgreifen). Da fragt dann oft keiner nach den wirklichen Gründen sondern hat halt so seine Meinung.

 

[Andreas_]

wenn der Kunde offensichtlich Bullshit will mit dem er sich so richtig in Probleme reiten wird ist die Frage ob man da wirklich mitgehen will.

Wenn der Kunde ein Pflichtenheft nach offshore liefert, dann bekommt der Kunde in der Regel das, was das Pflichtenheft hergibt. Beratungsleistung kostet mehr ...

 

[new Account()]

Das Thema ist echt schwierig, weil es bei den Kritikern am Ende immer darauf hinausläuft, dass es in Fall X, an dem sie gerade arbeiten, angeblich nicht geht und die Antwort der Clean Coder ist immer, doch, du kannst es nur nicht, was natürlich keiner hören will...

Selbst der "Uncle Bob" spricht sich eindeutig dafür aus die Regeln zu brechen. 😀

This is where I sit down or some other people sit down and they actually write code. And the code we are writing is actually very significant. [...] What you will find [...] is how we break the rules, because we always break the rules. The case studies show pragmatic applications of the rules and we ty to hold to these rules as much as we can find, but you you'll find [...] there's times where we just look at each other and say 'OK, well, can't [...] follow the rules here, we will have to fiddle with it and judge it, we'll come back to the rules as soon as we can'." Happens all the time.
So I have been teaching to you [....] all these rules and I am doing everything right and the best way to go fast is to beat go well, and then you always have to remember that this is engineering. And there is always trade off. And I don't want anybody use that for a licence to say Uh Uncle Bob said we can make a mess, because you try as hard as you can, but the rules sometimes just cannot hold all the time. .... Violate the rules!

Quelle

 

[Slurpee]

Selbst der "Uncle Bob" spricht sich eindeutig dafür aus die Regeln zu brechen. 😀

Den wichtigen Teil,

"And I don't want anybody use that for a licence to say Uh Uncle Bob said we can make a mess, because you try as hard as you can"

ignorierst du. Keiner hat gesagt, dass immer alles theoretische Perfektion erreichen muss. Und CC einfach pauschal, oder "in bestimmten Bereichen" für unnötig/unmachbar zu erklären, hat rein gar nichts mit "Regeln brechen" zu tun. Das ist schlicht auf die Regeln scheißen, weil man glaubt, es besser zu wissen, oder es einfach nicht anders hinbekommt...

Ich würde das ganze auch deutlich ernster nehmen, wenn diejenigen, die behaupten, bei ihnen ginge es nicht, auch mal im Detail erklären könnten, wo es sich beißt und welche Regeln sie brechen müssten. Das Problem: Sie kennen die Regeln schlicht und ergreifend gar nicht.

 

[new Account()]

Keiner hat gesagt, dass immer alles theoretische Perfektion erreichen muss.

Hat sich ziemlich so angehört.

die Antwort der Clean Coder ist immer, doch, du kannst es nur nicht, was natürlich keiner hören will...

Außerdem habe ich den "wichtigen" Teil nicht ignoriert. Wer nicht versucht den Code ordentlich zu machen, ist i.d.R. sowieso nicht an Codequalität interessiert bzw. nur soweit er muss.