Du bist nicht angemeldet.

fukar

Schüler

  • »fukar« ist der Autor dieses Themas

Beiträge: 109

Registrierungsdatum: 18.08.2012

Wohnort: Berlin

Beruf: freak

Danksagungen: 21

  • Private Nachricht senden

1

20.07.2016, 16:22

Clean Code

Hier mal ne kleine Auflistung mitn paar Notizen von mir. Weitere Infos findet man im Netz.

Zitat


DRY – Dont Repeat Yourself

  • Wiederholung vermeiden, erkennen
    und auflösen



KISS – Keep it simple, stupid

  • einfach und verständlich
    schreiben, PairProg sinnvoll



YAGNI – You ain´t gonna need it

  • Entscheide erst zur letzten
    Möglichkeit, bei Zweifel immer dagegen

  • Fokus auf Aufwand/Kosten/Nutzen
    aus Kundensicht


FcoI – Favour Composition over Inheritance

  • Komposition der Vererbung
    vorziehen


SLA – Single Level Abstraction

  • Pro Funktion nur ein
    Abstraktionslevel /-niveau verwenden

  • Funktionen nach Level(wie Zeitung)
    aufbauen: Einfach, Details, Rest


SRP – Single Responsibility Principle

  • Pro Klasse nur eine
    Verantwortlichkeit/Aufgabe


SoC – Seperation of Concers

  • Übermengen von
    Verantwortlichkeiten trennen, nicht mischen

  • Klare Aufgaben für
    „Code-Einheiten“


OCP – Open Closed Principle

  • Offen für Erweiterungen,
    geschlossen für Modifikationen


ISP – Interface Segregation Principle

  • Interfaces klein halten, wenn
    nötig aufsplitten, Doppellungen möglich

  • Nur Funktionen die der User
    wirklich benötigt


DIP - Dependency Inversion Principle

  • Auf Ebenen bei Vererbung achten,
    keine vertauschte Abhängigkeit erzeugen

  • Hohe Ebene gibt Interface vor,
    niedrige Ebene verwendet Interface



LSP – Liskov Substitution Principle

  • Verhalten der Basisklasse
    berücksichtigen

  • Erben dürfen übernehmen und
    erweitern, aber nicht einschränken


POLA - Principle of Least Astonishment

  • Überrasche niemals den User


IHP - Information Hiding Priciple

  • sichtbare Details immer soweit wie
    möglich einschränken


Tell, don´t ask

  • ohne öffentliche Details
    entstehen Objekte mit Verhalten


Law of Demeter – Don´t talk to strangers

  • Methoden verwenden der: eigene
    Klasse, Parameter, Superklasse, selbst erst. Obj.





Pfadfinderregel

  • Hinterlasse einen Ort immer in
    einem besseren Zustand


Issu Tracking

  • alle Aufgaben notieren: erinnern,
    überwachen, delegieren, priorisieren


Iterative Entwicklung

  • jede Phase liefert Erkenntnisse
    für die Phase davor


  • klar definierte Iterationsziele


Root Cause Analysis

  • Frage mindestens 5x „Warum?“
    (5-Why´s)


Optimierungen

  • Verständlichkeit (Lesbarkeit) und
    Evolvierbarkeit (Grundstruktur für Modifikationen)

  • Grund, Nutzen, Messung immer 2x
    überdenken -> YAGNI


Source Code Conventions

  • PSR nutzen und einhalten


Implementation und Entwurf überlappen nicht

  • dünne Schnittstelle für
    Kommunikation und Anpassungen pflegen


Implementation spiegelt Entwurf

  • physische Codeeinheiten entwerfen
    und implementieren


Komponentenorientierung (Contract-first-design)

Inversion of Control – Container

  • automatisches Laden der
    Abhängigkeiten


Continuous Integration & Delivery


Refaktorisierung durch

  • Einfach: „Methode extrahieren“
    und „Umbenennen“

  • Komplex: Integration von Tests


Automatisierte Integrationstests

  • Frontend und Backend


Automatisierte Unit Tests

Mockups (SUT) System Under Tests

Code Coverage

  • welcher Code wird nocht nicht
    getestet <90% sehr schlecht


Code Reviews

  • 4-Augen-Prizip → KISS


Statische Codeanalysen

Test first

http://clean-code-developer.de/
.:alwayz hardcore:.

JuKu

Profi

Beiträge: 574

Registrierungsdatum: 29.09.2011

Danksagungen: 48

  • Private Nachricht senden

2

10.08.2016, 21:37

Es gibt sehr viele unterschiedliche Ansichten, Clean Code aussehen sollten.
Erwähnenswert wären hier vorallem die vielen Design Patterns, die die Arbeit erleichtern.

Zitat


YAGNI – You ain´t gonna need it

Entscheide erst zur letzten
Möglichkeit, bei Zweifel immer dagegen

Fokus auf Aufwand/Kosten/Nutzen
aus Kundensicht


Laut einem Buch für Software Architekten gilt diese Regel aber auch nicht mehr wirklich.
Da heißt es eher: Mut zu Entscheidungen! Es lässt sich nie vollständig voraussagen, welche Konsequenzen diese Entscheidung birgt, auf der anderen Seite will man aber auch voran kommen.
Dennoch sollten Entscheidungen natürlich immer gut durchdacht sein.

Der Fokus sollte neben dem Aufwand / Kosten / Nutzen vorallem auch auf Qualität und Wartbarkeit liegen, wenn es eine gute Software werden soll.
Funktionalität ist heutzutage nicht mehr alles.
Wenn euch mein Beitrag weitergeholfen hat, drückt auf "Bedanken"!
Danke! :D

Ähnliche Themen

Verwendete Tags

cleancode, dry, kiss, solid, yagni