Suche Buch für Clean Code

[OnDemand]

Der Titel sagt es, wer hat ne Empfehlung für ein ebook? Möglichst aktuell und nicht aus 2010 oder so

 

[KonradN]

Also da hat sich nicht so viel geändert. Daher bleibe ich bei Clean Code von Robert C Martin (2008). (und alle seine Clean .... Bücher).

Ansonsten ist das ein Thema, das man sehr gut auch per Video erschließen kann. Da gibt es eigentlich alles sehr schön mit Robert C Martin und in einem guten verständlichen Englisch. Ich habe die in YouTube mal in einer Playlist gesammelt:

https://www.youtube.com/playlist?list=PLlX0P4QQfNkZ2bm0PuVKtHt70S63_PgOT

Es bleibt auch noch die Frage, was Du sonst noch so im Speziellen willst. Es gibt diverse Bücher, die ich als sinnvoll erachte:
Effective Java - da gibt es dann viele Punkte, die Sinn machen und die ich auch unter dem Begriff "Clean Code" sehen würde. Die 3rd Edition ist von 2017 ...

Ansonsten ist das eine Thematik, in der sehr viel auch über reinen Erfahrungsaustausch kommt. Also starte einfach mal ein paar Threads mit entsprechenden Themen

 

[OnDemand]

Das von Robert hab ich grad offen, liest sich gut. Werd ich mit bestellen.

Gibt so einige Sachen die ich wissentlich falsch mache und melde. Dazu müsste ich mir das aber eingestehen und hier so dönliche Threads machen, besser nicht das gibt nur Böses Blut 😂 zb versuche ich interfaces zu vermeiden, Weils mich mega verwirrt. Ich hab die falsch erklärt bekommen oder falsch verstanden und falsch eingesetzt. Ergo meide ich sie.

Außerdem ignoriere ich oft OOP Ansätze weil ich schneller, anders zum Ziel komme. Aber wie wir wissen folgt die Quittung früher oder später weil nix mehr zu erweitern geht. Entsprechend kommt hin und wieder zu viel businesslogik in eine Methode wo man diese noch in mehr einzelne Funktionen aufteilen könnte.

Aus einem oder mehrer Bücher hoffe ich irgendwie einen besseren Stil zu bekommen

 

[Robert Zenz]

Dazu müsste ich mir das aber eingestehen und hier so dönliche Threads machen, besser nicht das gibt nur Böses Blut 😂 zb versuche ich interfaces zu vermeiden, Weils mich mega verwirrt. Ich hab die falsch erklärt bekommen oder falsch verstanden und falsch eingesetzt. Ergo meide ich sie.

Schnittstellen werden meiner Meinung nach in vielen Projekten auch falsch eingesetzt. Wenn du eine Klasse hast welche eine Ausgabe macht, und du machst dann eine Schnittstelle Ausgabe und daneben die Klasse AusgabeImpl, ist das schon ziemlich falsch meiner Meinung nach. Schnittstellen solltest du dort machen wo du wirklich zwei unterschiedliche Implementierungen hast, welche aber ueber die selbe Schnittstelle angesprochen werden sollen. Zum Beispiel wenn du Dateien laden willst, dann hast du FileLoader und als konkrete Implementierungen dazu FileSystemFileLoader und HttpFileLoader.

Ich bevorzuge auch eher pragmatische Ansaetze in der Hinsicht (auch wieso ich den Microservice Wahn nicht verstehe, wenn du einen Monolithen hast, diesen dann in Microservices auftrennst, hast du immer noch einen Monolithen, aber halt Arsch zum entwickeln).

 

[OnDemand]

Ich hatte microservice. Das war der horror! Wir haben das jetzt wieder zum Monolithen geändert.

Microservices ist wirklich nur was für Grosse Firmen mit ausreichend Kapazitäten.

Was mich noch interessiert wäre wie man Module einbindet. Aktuell habe ich einen Ordner com.domain.module

Darin verschiedene Unterordner mit den Modulen und deren Funktionen.
Ob jemand ein Modul gebucht hat; mache ich über einen Eintrag in der Datenbank. Gibt aber bestimmt noch elegantere Lösungen über jar einbinden etc.
Aber erstmal möchte Ich meinen Code „vorzeigbar“ bekommen

 

[KonradN]

Außerdem ignoriere ich oft OOP Ansätze weil ich schneller, anders zum Ziel komme.

Also OOP Ansätze sind oft auch schlicht überholt. Das merkt man schon an der Regel : Favor Composition over Inheritance.

Das ist also nicht unbedingt ein Zeichen, dass etwas falsch ist.

Interfaces werden leicht polarisiert: Es gibt Ansätze, da muss alles ein Interface haben. Das war vor UML ... da wurden wir mit der Booch Method gequält. Ja, war nichts kompliziertes und man hat die Regeln angewendet und dann hatte alles ein Interface und ein Controller und wir hatten damals ein einfaches Faxgerät zu modellieren und das war schon heftig. Das war aber auch damals dann Stand der Entwicklung bei großen Projekten: Dieses: "Archtikten bauen alles in Rational Rose auf mit UML und co und dann wird der Code generiert." Und dann kommen die "dummen Programmierer" und füllen Methoden mit Leben. Das Ergebnis ist grausig und triggert bei guten Entwicklern massiv den Fluchtinstinkt.

Interfaces sind eigentlich nicht kompliziert, wenn man diese aus dem praktischen Nutzen heraus verwendet. Das Interface wird von den Verbrauchern definiert. Wenn Du etwas baust, dann baust Du es so, wie Du es bauen willst. Dann baust Du ein Auto. Das ist in sich zweckmäßig. Und das braucht kein Interface. Deine Klasse ist Deine Klasse! Jedes Interface ist Quatsch an der Stelle!

Nun kommt aber jemand und will diese Klasse nutzen. Dann wird ein Interface sinnvoll. Denn ich will nicht genau Deine Klasse. Ich will etwas, womit genau das machen kann, was ich will. An den Haaren herbeigezogenes Beispiel: Ich will da etwas, dem ich einen Text setzen kann. Das kann man auch bei Deiner Klasse. Das kann ich aber auch mit vielen anderen Klassen. Aber hier macht es dann Sinn: Ich habe ein Interface und das nutze ich dann. Mir kann es egal sein, was es konkret ist. Damit ist auch der Nutzen deutlich: Der Verbrauche kann mit allem arbeiten. Deine Klasse aber auch jede andere Klasse, die eben dann dieses Interface hat.

Ohne einen Verbraucher macht es ansonsten nur SInn, wenn ich mehrere Implementationen habe. Ich habe halt eine Linkedlist, ArrayList, ... -> Da kann man dann abstahieren zu List.

Aber damit sind wir schon weit weg vom eigentlichen Thema. Aber das mit den Interfaces muss also bei Dir gar nicht mal so falsch sein.

 

[OnDemand]

Danke, sehr spannender Text! Fluchtinstinkt getriggert ist gut 😂

Ich hab IF nur als repositories. Wenn ich eine Klasse irgendwo wiederverwenden will, dann will auch die exakte Implementierung so haben und die Methoden so nutzen wie sie bereits sind. Mit nem Interface müsste ich ja die Methode erstmal mit Logik füllen, dafür sehe ich wirklich keine nutzen in meinen Fällen.

Mit Verbraucher meinst du zb einen anderen Entwickler, der mit der Klasse arbeiten will?

 

[mihe7]

Microservices ist wirklich nur was für Grosse Firmen mit ausreichend Kapazitäten.

Der Sinn von Microservices besteht unter anderem darin, die Unternehmensstruktur abzubilden (das UI-Team hat eine andere Pace als das Backend-Team usw.), insofern ist da freilich was dran. Andererseits würde ich die Aussage nicht pauschal unterschreiben, wobei sich Microservices für meine Begriffe automatisch/"natürlich" ergeben müssen.

Wir haben z. B. auch eine überwiegend monolithische Anwendung, es gibt aber Dinge, die sich hervorragend als Microservice realisieren ließen und das in ein paar Fällen auch gemacht wurde - ohne darüber nachzudenken, ob das jetzt ein "Microservice" ist (streng genommen wussten wir damals nicht mal, dass es sowas wie Microservices gibt ). Vielmehr war es schlicht der beste Weg, den Spaß in eine eigene "Anwendung" auszulagern, weil man sonst unkritische Read-Only-Daten bei jeder Installation mitschleifen muss.

Ein anderes Beispiel wäre, wo man für viele Installationen eine zentrale Stelle benötigt, da geht es gar nicht anders.

Das Problem entsteht meines Erachtens, wenn man hergeht und sich die "Microservice-Architektur" als Ziel setzt. Wir machen das jetzt, weil... es jeder macht o.ä. Und je mehr, desto besser. Ich möchte kein System betreiben müssen, das aus 100 Microservices besteht, die womöglich noch alle untereinander kommunizieren.

Ich schweife ab...

 

[OnDemand]

Ich möchte kein System betreiben müssen, das aus 100 Microservices besteht, die womöglich noch alle untereinander kommunizieren.

Ich hatte vielleicht 25 kleine Services. Die waren viel zu detailliert aufgeteilt. Aber das war schon echt zum kotzen je größer die Anwendungen wurden.

Aber zurück zum clean Code, vielleicht hast du da auch was zu zu sagen. Kennst du Lektüre die man gelesen haben muss?

 

[KonradN]

Mit Verbraucher meinst du zb einen anderen Entwickler, der mit der Klasse arbeiten will?

Generell Verbraucher. Wobei eigene Verbraucher kann man sich überlegen, ob es notwendig ist.

Gründe für ein Interface können sein:

• Es wird nur ein Teil der Klasse benötigt
• Es gibt schon Gedanken, da die Implementation zu wechseln.

Aber hier auch aufpassen: Es gibt ja auch ganz andere Verbindungsmöglichkeiten. Ich kann ja auch mit funktionalen Interfaces arbeiten. Meine Klasse, die einen Text setzen kann, braucht so ein Interface ja gar nicht. Wenn es aus der anderen Klasse benötigt wird, dann übergebe ich nur eine Methodenreferenz oder Lambda Ausdruck. Daher ist das Thema Interfaces auch weniger aus Sicht der Vererbung zu sehen sondern mehr als: Ich sehe zu, dass ich für notwendige Verbindungen funktionale Interfaces nutze.

 

[mihe7]

Aber zurück zum clean Code, vielleicht hast du da auch was zu zu sagen. Kennst du Lektüre die man gelesen haben muss?

Ja, dazu ist aber hier schon alles gesagt.

 

[OnDemand]

Clean Code von Robert C Martin (2008)

Liest sich gut, aber ganz schön schwere Kost. Ist nix fürs Bette am Abend