Wie ernst nehmt ihr Clean Code Prinzipien?

[Danya175]

Moin,

mich würde mal interessieren, wie strikt ihr diese ganzen Clean Code Regeln umsetzt, speziell die mit 'nur eine Abstraktion pro Methode'. Ehrlich gesagt, habe ich da meine Zweifel. Ich meine, wir sind hier nicht in der Theorievorlesung, sondern im echten Leben mit echten Projekten und Deadlines.

Klar, ich verstehe den Punkt, dass man den Code sauber und wartbar halten will. Aber wenn ich jedes Mal, wenn ich eine neue Abstraktion finde, eine neue Methode schreibe, habe ich am Ende 100 Methoden in einer Klasse. Das kann doch auch nicht der Sinn der Sache sein, oder?

Ich habe letztens ein bisschen rumprobiert und kam auf sowas hier:

function processData(input) {
 validate(input);
 let data = fetchData(input);
 return transformData(data);
}

Ist das jetzt schon zu viel auf einmal? Fühlt sich für mich richtig an, aber nach den Regeln müsste ich das ja noch weiter aufsplitten. Wie seht ihr das? Irgendwo muss man doch auch mal die Kirche im Dorf lassen.

Grüße,
Danya

 

[Christian]

Hallo Danya,

ich kann das verstehen. Es gibt viele "clevere" Regeln für die Softwareentwicklung, aber nicht immer kann man jede einhalten. Ich halte auch persönlich nichts davon, jede Regel zu 100% strikt umzusetzen.
Das fängt schon bei solch Regeln an wie "eine Methode sollte nie mehr als 15 Zeilen lang sein". Es gibt im praktischen Alltag einfach Fälle, in denen eine Methode einfach mal 20 oder 30 Zeilen haben kann. Die kann man vielleicht auseinanderbröseln, hat aber am Ende überhaupt keinen Mehrwert sondern würde ggf. sogar noch die Nachvollziehbarkeit verschlechtern.

Ebenso ist es bei der Idee: Jede Methode darf nur exakt eine Zuständigkeit haben. Das ist in 95% der Fälle sicher eine gute Idee und meist versucht man sich dran zu halten. Aber es gibt auch Fälle, in denen ich das für Unsinn halte.

Perfekt sauberen Clean Code habe ich in einem größeren Projekt noch nie durchgängig gesehen: weder in Open Source-, Hobby- noch Enterprise-Umfeld.

Ich stimme dir da also zu: Ja, man muss die Kirche auch mal im Dorf lassen und nicht auf Teufel komm raus jede Regel durchdrücken.

 

[JuliaSun]

Hey, das Thema kenn ich und ehrlich gesagt, hab ich da auch lange mit mir gerungen.
Clean Code klingt in der Theorie super elegant, aber in echten Projekten mit echten Deadlines... naja. Pragmatismus schlägt oft Perfektion.

Dein processData-Beispiel find ich übrigens ziemlich gelungen. Validieren, holen, transformieren. Das ist sauber getrennt und verständlich. Ich hab schon deutlich unklarere Methoden gesehen, die trotzdem live gingen.

Diese "eine Abstraktion pro Methode"-Regel... ja, die hab ich auch mal versucht ganz strikt zu befolgen. Aber irgendwann hatte ich dann Methoden mit drei Zeilen, die nichts mehr sagten - und das hat am Ende eher verwirrt als geholfen. Manchmal ist es halt wirklich besser, einen Ablauf zusammenhängend zu sehen, solange er nicht zu viel auf einmal macht.

Mach dir keinen Stress. Theorie ist wichtig, aber Code muss am Ende vor allem nutzbar und pflegbar sein. Und das ist manchmal auch Gefühlssache. Weiter so!

 

[Hayleigh01]

Ich sehe das ähnlich. In der Praxis muss man oft abwägen zwischen "sauberem" Code und pragmatischen Lösungen. Deine Methode wirkt auf mich nicht überladen. Klar, "Clean Code" ist wichtig, aber wenn du dann 100 Mini-Methoden hast, wird es auch unübersichtlich. Manchmal ist es sinnvoller, ein paar Abstraktionen zusammenzufassen, um den Fluss verständlich zu halten. Am Ende zählt, dass der Code lesbar und wartbar bleibt - und das bedeutet nicht immer, strikt alle Prinzipien zu befolgen. Würde vermutlich ähnlich vorgehen wie du und nicht übertreiben mit dem Aufsplitten.