Clean Code oder Compassionate Code?

Für mich war “Clean Code” von Uncle Bob enorm hilfreich, aber ich habe nie mit allen seinen Ideen übereingestimmt, und fand vieles auch recht dogmatisch.

Johannes Brodwall geht diesem Dogmatismus auf den Grund, er bemängelt eine Geisteshaltung, die die ganzen (an sich durchaus guten und nützlichen) Praktiken anwendet, weil es “professionell” ist, zur “Berufsehre” gehört u.s.w., und nicht, weil es Programmierung einfacher, angenehmer und sicherer macht. Als großes Problem sieht er die daraus erwachsenden Streitereien um den “einzig richtigen Weg”.

Hier ist der Artikel: http://johannesbrodwall.com/2018/06/24/forget-about-clean-code-lets-embrace-compassionate-code/

Meiner Meinung nach ein must-read, der nachdenklich macht. Interessant auch, dass der Ausgangspunkt der Debatte tatsächlich mit Trump’s Politik zu tun hat

1 Like

Klar ist Bob Martin sehr dogmatisch wenn er in seinen Buechern “predigt”, das liegt IMHO daran dass er weiss dass die Realitaet immer zum Pragmatismus tendiert, das passiert also von ganz alleine.

Hab ihn mehrmals live reden hoeren, da klingt er dann schon viel pragmatischer, vor allem wenn er aus den Naehkastchen erzaehlt.

Aus dem verlinkten Blog entnehme ich, dass die Teams von denen er erzaehlt, vor allem sich selber, sich irgendwie schwer tun Kompromisse zu finden. Zum Schluss zaehlt nur was der Anwender/Kunde davon hat, alles andere sind nur mittel zum Weg (Wartbarkeit, Erweiterbarkeit, Wahrscheinlichkeit von Bugs etc.), dem ist es wurscht ob der Code sauber ist, ob es in Java/ Scala/Kotlin/PHP geschrieben ist, der will stabile Systeme und Features.

Zu den politischen Aeusserungen von Bob Martin:
Mich interessiert seine politische Meinung gar nicht, deswegen folge ich seinen Twitter Account sicherlich nicht, dafuer gaebe es andere Twitter Accounts/Personen die sich damit auskennen.
Auch erkennt man dass die beiden sich gerne im Internet anpissen, koennen die gerne machen, muss mich aber nicht interessieren.

Moin…,

ja das ist auch meine Ansicht - wenn mir wieder mal die Nichteinhaltung der „sklavenistischen“ „Clean Code“-Konvetionen vorgeworfen wird. :wink:
Pragmatismus versus Konventionen, und, überspitzt: Wer nicht weiß was zu tun der hält „Clean Code“ ein. :wink:
Ganz so ist es natürlich auch nicht, aber zum Besenstiel Vorlesungen über Qualität von Software brauchen auch einen Inhalt…

( Genug gemeckert für heute. :slight_smile: )

Brodwall geht es ja auch nicht um die politische Position an sich, sondern zieht eine Parallele zwischen Bob’s Denkweise in politischen und in programmtechnischen Fragen, und da zeigt sich ein Muster (Ehre, Pflicht…), das zu Dogmatismus führt.

Generell stimmen wir ja überein, dass man die Sache pragmatisch sehen sollte. Ich habe eben nur noch nicht so intensiv über die “Zielfunktion” für den Pragmatismus nachgedacht, und “Berufsehre” ist wirklich eine ziemlich schlechte.

Um auch mal aus dem Nähkästchen zu plaudern: Wir schreiben eine Abstraktion über verschiedene Arten von Dateisystemen. Jede Klasse, die das Interface implementiert, ist für ein bestimmtes URI-Schema (file, ftp, hdfs…) zuständig, was mach auch mit getSchema() abfragen kann. Jetzt fordert einer meiner Kollegen nachdrücklich, dass wir doch auch testen sollen, dass z.B. unsere FTP-Implementierung als Schema "ftp" zurückgibt. Ich weigere mich, das zu tun. Es gibt keine Möglichkeit, sowas irgendwie “versehentlich” zu ändern, und wenn es doch jemand tut, ist er so inkompetent, dass man ihn feuern sollte. Wenn man das testet, müsste man als logische Konsequenz als nächstes Tests dafür schreiben, dass niemand die Tests ändert.

Es fällt mir wirklich schwer, diese Steilvorlage nicht zu nutzen, aber ich halte mich des Forenfriedens wegen zurück…

Naja, das mit der parallelen ziehen finde ich fast so schraeg wie Bobs politische Ansichten (wuerg), wenn ich sie mir doch Ansehe.

So wie ich Bob Martin verstehe, geht es ihm darum Software Entwickler allgemein als echte Ingenieure zu etablieren, ich sehe so gut wie keinen SW Entwickler als Ingenieur, hab mit Ingenieuren in der L&R gearbeitet die SW entwickelt haben, war 'ne ganz andere Kiste, hat mir keinen Spass gemacht.

Da gibt es eine riesige Bandbreite von Hippies, Drogensuechtigen, Geisteskranken, Skriptkiddies, Schlippstraeger die lieber „Manager“ waeren aber eigentlich Autoverkaeufer sein sollten bis zu „Akademikern“ („Sheldon Cooper“) die meist nur eine Sache gemeinsam haben: soziale Inkompetenz, oft verbunden mit Geltungsdrang.
Nehme mich da selber nicht raus, manchmal waere ich aber lieber Gaertner :slight_smile:
Es gibt Ausnahmen, aber die sind eben Ausnahmen.

Nebenbei, Bob Martin ist nicht der Erfinder von TDD, er propagiert das auf seine spezielle Weise, sehr radikal, war ich auch mal, hatten auch radikale Scala/funktionale Entwickler bis mir aufgefallen ich dass da wirklich keiner Spass hat, muss da schon zwischen der Idee unterscheiden und der Person und der Art & Weise wie das verkauft wird.

TDD setzt viel voraus, ist nicht notwendig, manchen macht es Spass, anderen gar nicht, ist okay, weil es genug Jobs gibt je nach Geschmack.

Wenn ich so zurueckdenke ueber die letzten 12 Monate, gab es eine Sache die mir wirklich Spass machte: ein Student der mit der Aufgabe beauftragt wurde die komplette GUI test suite zu refaktoren, nach ein paar Wochen hat der 'nen richtig miserablen Eindruck gemacht, hab ihm gezeigt wie man refactored, war alles nur C&P davor, in weniger als einer Stunde konnte der Methoden auseinandernehmen, Redundanzen beseitigen, und versuchte bessere Namen fuer Methoden zu finden, der war sichtlich viel besser drauf.

Manchmal wundere ich mich ob das alles nicht wirklich Nebensache ist und es im Kern „Spass machen“ sollte?
Wie wichtig ist es wirklich den saubersten, effizientesten Code zu schreiben wenn doch im Grunde nicht viel davon abhaengt, wir heilen keinen Krebs, wenn es um Menschenleben geht sind immer echte Ingenieure anwesend.

Blahrg… sind das jetzt die Auswüchse davon, dass sowas wie Suffering on Stack Overflow. And How Our Tech Community Might Heal | by April Wensel | Medium und https://compassionatecoding.com/ in die community sickert? :roll_eyes:

TDD ist ein eigenes Thema, und der politische Twitter-Dreck interessiert mich nicht im geringsten.

Die grundsätzlichen Ideen zu Clean Code finde ich nicht verkehrt. Und ich denke auch, dass man sie nicht unreflektiert anwenden sollte - ganz im Sinne von

Rules are for the obedience of fools and the guidance of wise men

Dass man, wenn man lange sucht und sehr kreativ ist, Parallelen findet, zwischen den Prinzipien von Clean Code und Politik, ist nicht verwunderlich. Wenn man es darauf anlegt, könnte man auch ganz direkt sagen, dass die Grundidee hinter Clean Code ja gerade die ist, nazihaft zu sein.

Das Problem bei Abweichungen davon ist, dass jeder die Grenze woanders zieht. Es gibt keinen „Perfekten Code“, und es geht ja nur um die Frage, was an einem Stück Code nun wie schlecht ist. Wenn Bob z.B. sagt, dass eine Funktion „höchstens drei Parameter“ haben sollte, dann kann das zwei Folgen haben:

  1. Jemand, der eine Methode createRectangle(x,y,w,h) hat, versucht durch krampfige Workarounds (und in Java vielleicht ein Spring-Boot-Dependency-Injection-Builder-Factory-Pattern) auf Biegen und Brechen diesen verdammten vierten Parameter wegzubekommen

  2. Jemand bei NVIDIA sieht diese Methode in ihrer Deep-Learning-Library…

    cudnnStatus_t CUDNNWINAPI cudnnFindRNNBackwardDataAlgorithmEx( 
     cudnnHandle_t handle,
     const cudnnRNNDescriptor_t rnnDesc,
     const int seqLength,
     const cudnnTensorDescriptor_t * yDesc,
     const void * y,
     const cudnnTensorDescriptor_t * dyDesc,
     const void * dy,
     const cudnnTensorDescriptor_t dhyDesc,
     const void * dhy,
     const cudnnTensorDescriptor_t dcyDesc,
     const void * dcy,
     const cudnnFilterDescriptor_t wDesc,
     const void * w,
     const cudnnTensorDescriptor_t hxDesc,
     const void * hx,
     const cudnnTensorDescriptor_t cxDesc,
     const void * cx,
     const cudnnTensorDescriptor_t * dxDesc,
     void * dx,
     const cudnnTensorDescriptor_t dhxDesc,
     void * dhx,
     const cudnnTensorDescriptor_t dcxDesc,
     void * dcx,
     const float findIntensity,
     const int requestedAlgoCount,
     int *returnedAlgoCount,
     cudnnAlgorithmPerformance_t *perfResults,
     void * workspace,
     size_t workSpaceSizeInBytes,
     void * reserveSpace,
     size_t reserveSpaceSizeInBytes );
    

    …und fängt an zu überlegen: „Hm… vielleicht könnte man das irgendwie besser machen“ :+1:

Die Tatsache, dass man „Perfektion“ nicht erreichen (und vielleicht nichtmal definieren kann) darf nicht die Rechtfertigung dafür sein, dass man nicht zumindest irgendein „höheres Ideal“ anstrebt.

Beeinflusst wird das ganze natürlich auch durch einen abstrakten und schwer zu erfassenden „Anspruch an sich selbst“ oder allgemein die eigene Persönlichkeit. Man kann entweder jeden Abend 5 Stunden coden+lesen, oder ein richtiges Leben haben. Manchen wird diese Entscheidung durch ihren Mangel an sozialer Kompetenz abgenommen. Praktischerweise landet man dann in einem Teufelskreis, und irgendwann stellen sich die Fragen nach den Alternativen gar nicht mehr.

Was genau nun die Botschaft dieses Blogbeitrags sein soll? Schwer zu sagen. Zwei Kommentare:

People did what they did because of reasons.

Often these reasons are that the people are stupid and incompetent, or that people just dumped out a piece of sh!tcode, because it „worked for them“, and they did not effing care about the people who might have to maintain their crap later.

Your most valuable skill is to know what’s important. Code is not important. Principles are not important. Rules are not important. People are important. That means your users, your team, your family, yourself. […] Make people Awesome.

Awesome in what? Coding? You won’t achieve that without a set of guidelines that define some metric for awesomeness. The result of the work of an engineer who builds a car is the car itself, and not „the movement from place A to place B“. And for me, as a software developer, the result of my work is the code itself, and not the application that results from running the code. The code that I’m writing is never (and has never been, and will never be) „good“ - at least not good enough for me to be satisfied with it. Let’s face it: Most people (including myself, of course) are not (and have never been, and will never be) „awesome“.

Also deine beiden Links sind ja wirklich der Hammer! Ich verstehe ja, dass manche SO-Antworten ein bisschen harsch sein können, aber das kann doch nicht die Lösung darauf sein. Es gehört zum Programmieren dazu, zu lernen, wie man Fragen richtig stellt. Ich würde sagen, dass ich in über 80% der (sehr wenigen) Fälle, wo ich persönlich eine flapsige Antwort auf SO bekommen habe, wirklich etwas ganz einfaches übersehen hatte, oder eben nicht RTFM! beherzigt habe. Und ganz ehrlich, zu programmieren bietet ganz andere Härten als hin und wieder eine unhöfliche Antwort runterschlucken zu müssen - wer daran schon scheitert, sollte seine Berufswahl überdenken.

Ich denke aber, dass der Ausgangsartikel und compassionatecoding.com nicht viel mehr als den Namen gemein haben.

Was würdet ihr machen, wenn euch ein Vorgesetzter befiehlt, „schlechten Code“ zu schreiben? Abseits jeglicher Konventionen und jeglicher Vernunft. Ging mir mal so. Folge war, dass man damit dann auch keine zufriedenstellende Software hinbekommt und am Ende eine Kündigung im Raum steht.

Die andere Perspektive ist, die des Kunden/Unternehmers, der von euch Code will. Der will, wenn er ein wenig Ahnung hat, keine Schneeflocke, sondern Code, den jeder versteht, damit in Zukunft jemand anders daran arbeiten kann. Kurz Standard. Hochkomplizierte Sachen, die Hochkomplexen Code erfordern machen ja die wenigsten Hauptberuflich.

Ich weiss ja nicht wie es euch geht, aber schlechten Code sehe ich häufiger als guten. Da kommt dann auch mal die Erklärung der Kollegin, „da war ich wohl echt betrunken, als ich das schrieb“.

Insofern ist mir das letztlich egal. Es ist ein Job, jemand will es so haben und solange bezahlt wird, kann man über alles andere hinwegsehen. Nach 3 bis 5 Jahren schreibt man das Zeug eh neu. Diesmal dann richtig :wink: Ganz bestimmt.

1 Like

Ich glaube, die beiden sind sich nicht grün. :slight_smile:

Zum eigentlichen Thema: Ich verfolge ziemlich gerne Clean Code. Viel zu häufig wird mit „Pragmatismus“ erklärt, warum der Code nicht clean sein muss.

Vielleicht ist Clean Code auch deshalb so “dogmatisch” geschrieben, weil viele Programmierer mit abstrakten Prinzipien nicht viel anfangen können. Uncle Bob sagt: “Mach es so und so, dann verletzt du nicht das SRP”. Die Programmierer machen es dann so, aber das SRP interessiert sie nicht die Bohne. Für mich ist es dagegen sehr wichtig, die Prinzipien wirklich zu verstehen und kreativ anwenden zu können, und damit ist mir Clean Code notgedrungen zu dogmatisch.

Nebenbei bin ich einem Prinzip auf der Spur, das ich noch nicht so richtig fassen kann. Bei einer Frage auf codereview.stackexchange.com kam dieser Code vor:

if (bmi >= 40) {
    System.out.println("Serious obesity");
} else if (bmi >= 30) {
    System.out.println("Obesity");
} else if (bmi >= 25) {
    System.out.println("Overweight");
} else if (bmi >= 18) {
    System.out.println("Standard");
} else {
    System.out.println("Underweight");
}

Klar, erster Kritikpunkt ist, dass er nicht skaliert. Sowas will man nicht schreiben, wenn man 30 Fälle hat. Aber der zweite Punkt, denn ich nicht so richtig ausdrücken kann, ist die “Immobilität”, die eingeschränkte Anwendbarkeit. Die if-Kaskade fühlt sich für mich wie “festgeklebt” an. Was ist, wenn ich die Fälle an einer Stelle initialisieren will, und an einer anderen benutzen?

Falls es jemanden interessiert, mein Lösungsvorschlag war:

TreeMap<Double, String> map = new TreeMap<>();
map.put(40.0, "Serious obesity");
map.put(30.0, "Obesity");
map.put(25.0, "Overweight");
map.put(18.0, "Standard");
map.put(0.0, "Underweight");
System.out.println(map.floorEntry(bmi).getValue()); 

Danach kann man die “Fallunterscheidung” als Datenstruktur weitergeben, Die Lösung skaliert auch besser, weil man die TreeMap flexibel befüllen kann.

Gibt es dafür schon ein Prinzip (vielleicht ein bisschen wie SRP, aber das trifft es nicht ganz)? Wenn nicht, wie würdet ihr es nennen? Und um zum Thema zurückzukommen: Hat Uncle Bob eigentlich auch eine Lösung dafür parat?

Ich glaube, um die Prinzipien zu verstehen, muss man sie anwenden. Immer und immer wieder. Irgendwann versteht man es und kann von dem dogmatischen abrücken.
Gibt da ja ziemlich viele unterschiedliche Katas und die verschiedenen Prinzipien zu üben.

Der Grundgedanke, dass da Prinzipien dahinter stehen, die über den Code als syntaktisches Konstrukt hinausgehen, ist dabei wohl der entscheidende. Darauf bezog sich genau der Satz, dass man nicht unreflektiert umsetzen sollte, was man liest.

Als suggestives (fast schon polemisch) wirkendes Beispiel: Jemand liest https://refactoring.com/catalog/extractMethod.html und verwendet das als Argument für bestimmte Refactorings („Fowler hat gesagt, das soll man so machen!!!“). Bis https://refactoring.com/catalog/inlineMethod.html kam er halt nicht.

Allgemeiner könnte man wohl sagen, dass Clean Code eben keine „Regeln, sind wie code zu sein hat“, sondern eher die Umsetzung von strukturellen und konzeptuellen Ideen im Code sind. Man kann sich da teilweise bewußt und absichtlich dran halten, und irgendwann „gewöhnt man sich bestimmte Sachen an“.

Auch wenn man glaubt sich etwas schon „angewöhnt“ zu haben, kommt es immer wieder mal vor, dass man beim kritischen Hinterfragen des eigenen Codes merkt, dass man „eine der Regeln verletzt“ hat. In diesem Sinne ist das Wichtigste vielleicht nicht das Einhalten der Regeln an sich, sondern die transzendent-übergeordnete Abstraktion davon: Das kritische Hinterfragen des eigenen Codes.

(BTW: Vieles ^ davon sagt Bob auch selbst auf seinen Seiten in ähnlicher Form).

Ein Beispiel für dieses „verinnerlichen“: SOLID - Wikipedia . Manche Leute kennen das Akronym von irgendeiner Power-Point-Folie im ersten Semester. Andere sind stolz darauf, dass sie nachplappern können, was jeder einzelne Buchstabe bedeutet. In der Detailstufe, wie sie auf Wikipedia zusammengefasst sind, werden die meisten Leute sagen: „Klar!!!111 Mach’ ich!!! Immer!!! Ist doch logisch!!!“. Sich die (ganz unten auf der Wikipedia-Seite verlinkten) einzel-PDFs dazu durchzulesen ist aber nochmal ein Schritt mehr, und ich vermute, dass die wenigsten diesen Schritt gegangen sind.


Fast schon „OT“, weil ein sehr spezielles Beispiel:

Aber der zweite Punkt, denn ich nicht so richtig ausdrücken kann, ist die “Immobilität”, die eingeschränkte Anwendbarkeit. Die if-Kaskade fühlt sich für mich wie “festgeklebt” an.

Eine ähnliche Daumenregel, wie die Clean-Code-Prinzipien, ist: Immer, wenn man ein if schreibt, sollte man überlegen, ob man das nicht auch anders lösen könnte. Im speziellen kann man erstaunlich viele if-Abfragen durch geschickte Polymorphie vermeiden (und das nicht nur, um ums Verrecken das if zu vermeiden, oder unbedingt dieses coole „Polimorfie“ verwenden, von dem man im 2. Semester gehört hat, sondern weil es sinnvoll, flexibler und allgemein besser ist).

Das Beispiel (und die Lösung mit der TreeMap (die (Clean Code ;-)) auch nur als eine NavigableMap deklariert sein könnte)) erinnerte mich 1:1 an den Kommentar, den ich unten bei https://stackoverflow.com/a/22179665 eingestreut hatte - und dort ist auch ein gewisser Trade-Off erwähnt. Manchmal ist ein if auch OK - wobei gerade die Kommentare dort (z.B. die Frage nach dem „Orange“) deine Argumente hinsichtlich der Flexibilität unterstützen.

Das wichtig(er)e in solchen Fällen finde ich aber allgemein weniger die Frage, wie die einzelnen Codezeilen aussehen. Dem übergeordnet ist für mich die allgegenwärtige Frage nach der Schnittstelle: Wer will diesen Code-Teil wie verwenden? Natürlich war dein Lösungsvorschlag auch nur zur Verdeutlichung. Bei sowas würde man ja ohnehin zumindest eine Methode

private static String categorizeBmi(double bmi) { ... }

schreiben. Die Frage, wer in so einem Fall definiert, wie die Kategorien sind, ist wohl wichtig, um zu entscheiden, ob man dort den if- oder den NavigableMap-Ansatz verwendet.

Danach kann man die “Fallunterscheidung” als Datenstruktur weitergeben,

Die Fallunterscheidung weiterzugeben ist in beiden Fällen möglich - wenn man für die Empängerseite die Schnittstelle passend definiert hat:

void printBmiStuff(DoubleFunction<String> bmiCategorizer) {
    double bmi = compute();
    System.out.println(bmiCategorizer.apply(bmi));
}

void callIt() {

    // Entweder so...
    TreeMap<Double, String> treeMap = create();
    printBmiStuff(treeMap::get);

    // Oder so:
    printBmiStuff(ThisClass::categorizeBmi);
}

(Modulo double vs. Double… tja…).

Das ist dem Emfpänger ja dann egal.

Sofern der „Empfänger“ nicht ein Unit-Test, bei dem deine Map-Lösung dann bei assertNonNull(bmiCategorizer.apply(-1.23)) aussteigt :wink:

Hm… erinnert mich schon sehr an das hier

Der Author ist Theodore Kaczynski, aka “The Unabomber”, stammt aus seinem Manifest:
https://www.washingtonpost.com/wp-srv/national/longterm/unabomber/manifesto.text.htm?noredirect=on

Was ist jetzt mehr geschmacklos, Nazi Vergleiche zu Clean Code “weil man das nicht mag” (um auch gleich mal Godwin’s law zu erfuellen) oder Massenmoerder vergleiche wenn jemand sagt “Denk fuer dich selber”?

Das darf jeder selbst entscheiden…

Jedem steht es frei sich einen Arbeitsplatz zu suchen der ihm am besten passt, sehe das nicht als Problem ehrlich gesagt, es zeigt eben die Bandbreite an Jobs und Firmen die es in der SW Entwicklung gibt.

tldr;

Das bestätigt doch geradezu “meine” Hypothese…

Und ganz neu ist das auch nicht, schon Goethe schrieb:

„Wenn man alle Gesetze studieren wollte, so hätte man gar keine Zeit, sie zu übertreten.“

… was heißen mag, das dogmatische Einhalten aller Gesetze ist nicht immer die sinnvollste Alternative.

Um die Frage, ob Nazi-Vergleiche in solchen Fällen angebracht sind, mal mit einem anderen Zitat zu beantworten:

Ja

^ Dieses Zitat stammt von Adolf Hitler. Oder von Mahatma Gandhi. Einer von beiden hat das gesagt. Oder beide. Mal im Ernst: Ich fände es gut, diesen Politik-Sche!ß aus einer technisch-fachlichen Diskussion herauszulassen. Wobei ich zugeben muss, in meiner Antwort als Reaktion auf das Hippiemuschihafte “People are important” zuerst auch ein Zitat/Link auf http://acolumbinesite.com/eric/writing/journal/journal.php eingefügt zu haben (habe es aber wieder rausgenommen - aus genau diesen Gründen).

Wenn ich bei einem Code-Review sehe, dass jemand an einer zentralen Stelle 20 Parameter an eine 1000-Zeilen-Methode übergibt, und da drin trotzdem noch auf 20 static Variablen zugreift, kann ich entweder sagen: “Jo du, ich mag die Einrückung und die schönen Variablennamen, geh’ jetzt ruhig nach Hause und verbring’ ein bißchen Zeit mit deiner Liebsten”, oder ich kann sagen: “Das ist crap, mach’ das nochmal richtig”. Welche Rechtfertigung soll es für ersteres geben? Irgendwelche Gefühle nicht zu verletzen? Wie schon angedeutet: Ich befürchte, das das Auswirkungen davon sind, dass dieser ganze Social-Justice- und “Wir sind alle gut, so wie wir sind”-Dreck in die Gesellschaft sickert. Die Zusammenhänge aufzudröseln, dazwischen, dass Leute, die so etwas fordern, nicht in Entscheidungspositionen aufsteigen, und gleichzeitig die Entscheider kritisieren, wäre mit jetzt aber zu kompliziert…

1 Like

ROFL

Die Frage ist, wie man die Kritik rueberbringt und eine andere Frage ist, wie man die Person dazu bringt das besser zu machen.
Wenn man „irgendwelche Gefuehle“ verletzt, was ich oft machte, ist die Wahrscheinlichkeit gross dass es der Person in Zukunft nicht einfacher faellt „besseren Code“ zu schreiben :wink:

Die Frage ist immer, ob man den Code oder die Person kritisiert. Inzwischen wimmelt es von kleinen Schneeflöckchen, die den Unterschied nicht kennen, oder nicht kennen wollen. Das kommt davon, wenn man jedem Kind nach dem Eierlauf eine Medaille umhängt, selbst wenn sie das Ei an eine Krähe verfüttert haben.

Wer seine Gefühle verletzt sieht, weil sein Code (mit Begründung) kritisiert worden ist, hat leider den falschen Beruf erwischt…

Die erste Frage die sich stellt ist, ob man selbst die Person ist, die etwas zu kritisieren hat.

Vielen, auch mir fällt es oft schwer sich einzugestehen, dass man nicht “die Polizei” ist. Die Polizei ist die Polizei. (Autofahren zum Beispiel, wenn einem Raser und Geisterfahrer entgegenkommen, dann würde man diese am liebsten gleich rauswinken und aburteilen).

Polizei bist du, wenn du der Boss bist. Dann legst du die Regeln fest und mahnst ab oder lässt es sein.

Wenn du betriebliche Strukturen hast, dann legt dort jemand die Regeln fest und schaut ob sie eingehalten werden.

Ansonsten kann man auch auf “flache Hierarchien” setzen, die Regeln und deren Einhaltung selbst festsetzen lassen und jeden morgen einen Stehkreis machen oder jeder macht was er will.

Und wenn einem die Regeln nicht passen, die andere einem auferlegen, dann kann man sich immer noch Selbständig machen und ist dann wieder Boss.

Viele sehen eine Software als etwas worauf sie stolz sind und was man nicht verhunzen sollte. Auch schön, gut und verständlich. Allerdings ist es in der Regel nicht deine Software die da verhunzt wird, sondern die von deinem Boss. Der hat das Problem. Der muss sich um eine Lösung kümmern.

Sicher. Man könnte vordergründig davon reden, dass Kritik „konstruktiv“ sein sollte. Aber manchmal muss man sich echt die Frage stellen, wie weit unten man mit seiner Kritik ansetzen kann, sollte oder muss. Ich gebe ja zu, dass ich ein „Codenazi“ bin: Ich achte auf auf unbedeutende Kleinigkeiten. Da sie unbedeutend sind, müssen andere sie nicht beachten. Da es Kleinigkeiten sind, könnten sie es aber. Die Latte dafür, Code zu schreiben, der einigermaßen vernünftig ist, liegt nicht besonders hoch, aber wenn ich aus meiner bisherigen Programmiererfahrung eine Sache mit Sicherheit sagen kann, dann das: Egal, wie niedrig man die Latte legt - irgendjemand wackelt immer mit einem fröhlichen Limbo drunter durch. Wollen wir kurz über sowas wie einen int array[][][][][][][][]; reden? Muss wohl nicht sein. Man muss sowas auch von mehreren Seiten beleuchten. Selbst der haarsträubendste Müll kann z.B. oft leicht durch „Zeitmangel“ gerechtfertigt werden. (Zeitmangel funktioniert immer). Vielleicht hat auch jemand vorher eine andere Sprache verwendet, und weiß nicht, warum es void foo(List<X> x) statt void foo(ArrayList<X> x) heißen sollte. Man sollte nicht voreilig jemanden als dumm oder inkompetent abstempeln. Eine allgemeine Empfehlung, die ich für sinnvoll halte, ist, zu versuchen, sich auf die kleinste zu ändernde Sache zu konzentrieren. Aber teilweise gibt es so viele kleine Sachen, dass es schwierig ist, nicht die Geduld zu verlieren, und statt der vielen kleinen Sachen (d.h. des Codes) einfach die Person zu kritisieren…

Als Code-Reviewer? Ja. Ansonsten kann man’s ja gleich bleiben lassen :confused:

Mir wurde mal vorgeworfen, ich sei nicht kritikfähig. Das stimmt aber nicht. Ich kritisiere alles mögliche. Den ganzen Tag. Ich bin da quasi Experte. :clown_face: Vor allem, wenn ich meine SSRIs nicht genommen habe :no_mouth:

Man könnte das mit weiteren Worthülsen garnieren. Z.B. das Kritik nicht nur „konstruktiv“ sondern auch „angemessen“ usw. sein sollte. Oder dass man lernt, mit Kritik umzugehen, und nicht versucht, sie einfach „wegzuwischen“, indem man sie als unangemessen oder unkonstruktiv bezeichnet. (Irgendwann bin ich mal auf die total verrückte Idee gekommen, dass eine Möglichkeit, Kritik zu vermeiden, darin bestehen könnte, nichts zu machen, was kritisiert werden kann. Der Versuch ist lähmend. Versucht es nicht.)

Wie das in der Praxis laufen soll, ist mir nicht ganz klar. Klingt, als würde man bei einem Code-Review sehen: „Joa, ist alles crap, aber ist ja nicht mein Problem, sondern das vom Boss“. Da der das Code-Review nicht selbst macht, klingt das nach dem Versuch, sich einer Verantwortung zu entziehen. (Das ist nur eine Vermutung bzw. Interpretation - aber selbst wenn es so ist, ist es erstaunlicherweise keine Kritik :wink: Wer will schon Verantwortung :roll_eyes: )

Nein. Wenn man einen objektiven Grund sieht, warum Code ernsthaft schlecht geschrieben ist, würde ich das immer zum Ausdruck bringen. Wenn so ein Feedback nicht erwünscht ist, befinde ich mich an einem Ort, an dem ich nicht sein sollte. Das heißt nicht, dass man mein Feedback diskutieren oder berücksichtigen muss - es kann gute Gründe geben, das nicht zu tun. Aber konstruktive Kritik zu äußern muss immer erlaubt sein.