Ankündigung

Einklappen
Keine Ankündigung bisher.

CleanCode - Prinzipien und Praktiken

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • CleanCode - Prinzipien und Praktiken

    Ich stell hier mal meine Notizen zu CleanCode rein.

    Evtl. ist es für jemanden interessant (der das buch noch nicht kennt) oder jemand bemerkt einen Fehler bei mir (Falsches oder Vergessenes)

    Es ist nur eine Liste der wichtigsten Prinzipien und Praktiken von Cleancode an die man sich halten sollte. Detailinfos muss man sich selbst im Netz ziehen.

    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/
    hardcore will never die

  • #2
    DRY ist für mich schon Lebenseinstellung, kann man auch gut im Alltag anwenden.
    [I]You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.[/I]

    Kommentar


    • #3
      yup, KISS auch.. und mit dem issue tracking kanns probleme mit der frau geben, wennse an privaten kanbanboards nicht teilnehmen will ^^
      hardcore will never die

      Kommentar


      • #4
        So eine Liste ist zwar ganz nett, aber im praktischen Einsatz werden viele der Punkte doch gerne falsch verstanden / fehlinterpretiert. Gerade Themen wie SRP oder SoC lesen sich zwar ganz schön, aber diese auch wirklich zu verstehen, verinnerlichen und korrekt anzuwenden ist etwas völlig anderes. Daher mein Vorschlag: baue doch einfach mal zu jedem Punkt ein Pro- und Kontrabeispiel mit PHP um zu veranschaulichen was damit überhaupt gemeint ist
        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

        Kommentar


        • #5
          Das wäre auch ein schöner Beitrag für die Wissenssammlung... Sollte da was bei rauskommen dann "übertrag" ich das gerne dorthin.
          The string "()()" is not palindrom but the String "())(" is.

          Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
          PHP.de Wissenssammlung | Kein Support per PN

          Kommentar


          • #6
            jute idee, muss ik nur nach zeit kiekn, meld mir wenns neue infos oder n ersten teil gibt
            hardcore will never die

            Kommentar


            • #7
              machen wa n deal? ik hau jeweils 1-2 beispiele dazu und irgend jemand kommentiert das ganze für php.de (auf deutsch)
              hardcore will never die

              Kommentar


              • #8
                Codecomments oder was meinst du?
                [I]You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.[/I]

                Kommentar


                • #9
                  Als Randnotiz möchte ich gerne auf die Softwerkskammer verweisen. Diese hat sich Software Craftmanship Manifesto verschrieben. Sie kümmert sich genau, um die Anliegen der OP hier vorgetragen hat. Wie beim Handwerk, sollen Softwerker ihre Fähigkeiten und Werkzeuge besser verstehen und beherrschen. Dazu sind in verschiedenen Bundesländern, oft Zusammenkünfte von Codern, um genau jenes zu erreichen.

                  Hier in Berlin war letztens wieder ein "CodeKata", wo wir Spaghetticode testbar machten und danach refaktorierten. Dabei kommt man mit verschiedenen Sprachen zusammen. Von Go, über Java, zu wasweißiche bis PHP war alles dabei. Es wird immer im 4 - Augen Prinzip trainiert. Jeder in seiner Sprache, oder auch mal über den Tellerrand gelinst. Der Vorteil der Sache ist, anstatt sich etwas theoretisch auf die Fahnen zu schreiben, ist man ohne Deadlinedruck in einer Umgebung, wo man es auch einmal ausprobieren kann.

                  Als Beispiel: Letztens beim Test schreiben, hat einer vor Ort förmlich den halben Test über Reflection gelöst. Wäre mir nie in den Sinn gekommen, war am Ende aber eine echt schöne Lösung.

                  Dort findet man für eine solche Initiative uU schnell Verbündete.

                  Ich weiß nicht ob Links genehm sind, bin neu im Forum. Daher müsst ihr googlen.

                  Kommentar


                  • #10
                    Issue tracking ist fuer mich einer der wichtigsten. Wenn mal schon etwas nicht geht, sollte man sich das wenigstens notieren, bevor sich das Problem im Hintergrund einfach nur vergroessert. Gute Notizen!

                    Kommentar


                    • #11
                      KISS – Keep it simple, stupid
                      • einfach und verständlich schreiben, PairProg sinnvoll
                      Ich hatte das immer als "der einfachste Weg ist auch der beste" verstanden.

                      jute idee, muss ik nur nach zeit kiekn, meld mir wenns neue infos oder n ersten teil gibt
                      Warum schreibst du nicht vernünftig?
                      [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
                      [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

                      Kommentar


                      • #12
                        Bitte entschuldige meinen Dialekt, den ich privat vlt. manchmal übertreibe; ich versuche mich zu bessern!

                        Danke für die Information zur der Softwerkskammer. Ich habe mir deren Link direkt gespeichert.

                        Issue Tracking in der Form von wer schreibt Tickets, bzw vervollständigt sie, etc kann im team auch nervend sein, wenn das nicht klar geregelt ist und unvollständige tickets in "next" oder in den sprint gezogen werden.. oder wenn teammitglieder aufgaben ohne ticket machen wollen, usw
                        hardcore will never die

                        Kommentar


                        • #13
                          Das stimmt. Ein Bugtracker hilft auch nicht mehr, wenn das Team es nicht "richtig" benutzt und es verfolgt. Falls jemand Erfahrungen im Berreich Bugtracker mit Teamarbeit hat, wuerde mich das interessieren wie das so abgelaufen ist.

                          Kommentar


                          • #14
                            in einer firma mit kanban hat das alles der qa-manager gemacht. es wurden bug-tickets mit einer speziellen vorlage (reproduktionsschritte, screenshots, etc) angelegt bzw ausgefüllt.
                            nicht vollständig ausgefüllte wurden direkt abgewiesen.
                            fürs tracking hatte der kollege ein extra board mit spalten wie "ungeprüft", "prio1/2/3/4", etc. die qa konnte pro woche 5tickets reinhängen, manchmal haben wir aber auch mal einen reinen bugfixing-tag gemacht.
                            eilige bugs wurde wie andere schnelltickets in die fastlane gehangen und nach entwicklung/test, direkt live geschoben.

                            in einer anderen firma hatten wir bugzilla genutzt, was eher ein schwarzes Loch war. allerdings wurde in der firma auch die teamarbeit und kommunikation verhindert/untersagt, daher war ich da auch schnell wieder weg ^^

                            eine andere firma hat garkein tracking- bzw. ticketsystem oder aufgabentool genutzt, da war ich dann auch nicht lange ^^
                            hardcore will never die

                            Kommentar


                            • #15
                              Schon erstaunlich dass manche "Firmen" die "Software" entwickeln nichtmals einen Bugtracker haben. Dabei gibt es so viele kostenlose Alternativen..

                              Kommentar

                              Lädt...
                              X