Clean Code Developer

Clean Code Developer

Posts 1-9 of 9
  • Jan Fellien
    Jan Fellien    Premium Member   Group moderator
    The company name is only visible to registered members.
    Kunst und Regeln
    Hallo CCDler,

    ich möchte mich hier als ein CCDler der ersten Stunde vorstellen, auch wenn ich es gar nicht wusste. Wie kommt das?

    Ich habe vor mehr als 10 Jahren mein Studium als Maschinbauer beendet, bin aber sofort in die Softwareentwicklung gewechselt, weil ich auf diesem Gebiet mehr Chancen sah. Ausserdem bestand meine Diplomarbeit darin, ein Softwaremodul für Verwaltungsaufgaben zu schreiben. Und damit kommen wir zur Veknüpfung zu CC, denn das Softwaremodul entstand unter den Regeln des KAIZEN, der kontinuierlichen Verbesserung.

    Eben diese Regeln, auch bekannt unter der 5S-Philosophie (erwähnt im Buch "Clean Code"), waren es, die es mir ermöglichten a.) die Diplomarbeit früher abzugeben und b.) das Modul sofort produktiv gehen zu lassen. Nach der Abgabe konnte, ohne Nachfragen, ein hausinterner Entwickler die Erweiterung des Moduls übernehmen. Das zeigte mir, dass ich den richtigen Weg gewählt hatte.

    Nun habe ich divere Literatur zu Clean Code studiert und auch schon einige Projekte umgesetzt, aber bisher habe ich keine Entwickler gefunden, die den Anspruch haben, diszipliniert sauberen Code zu schreiben. Aussagen wie "ich möchte nächstes Jahr auch noch hier arbeiten" verärgerten mich zunehmens und führten auch schon zu einem Firmenwechsel.

    In meiner aktuellen Position als Software Architekt bin ich beauftragt, die stetige Verbesserung der Software zu realisieren. Das finde ich gut und vor allem spannend, denn hier sitzen viele richtig gute Leute, die Clean Code fabrizieren möchten. Sie sind sich bewusst, dass es ein schwieriger Weg sein kann, vor allem, wenn man bisher Einzelkämpfer war.

    Nun taucht aber ein ganz neues Problem am Horizont auf: die Technologiefrage.
    Ich bin mir bewusst, dass ein erfolgreicher Projektabschluss nicht von der Technolo0gie abhängt, aber die Reinheit des Codes scheint davon abhängig zu sein.

    Derzeit wird das System im Backend mit Python realisiert. Die Entwickler sind schnell aber wenig effektiv, denn sie können Bugs nicht wirklich nachvollziehen. Das wird in der nächsten Zeit durch eine sauberes Testing verbessert.
    Dennoch galube ich, dass Python (oder vergleichbares Sprachen) für Clean Code nicht geeignet sind, da ein wichtiges Prinzip nicht eingehalten werden kann: "Komponentenorientierung". Es ist nicht möglich Black Boxes zu formulieren, es ist alles offen, und es ist nicht wirklich möglich Contracts zu definieren. Oder sehe ich das falsch? Bin ich zu sehr von meiner .Net oder Java Welt verblendet? Wenn man keine privaten Methoden schreiben kann, wie kann ich dann kleine private Funktionen von der Hauptaufgabe eines Objektes trennen oder erkennbar machen? Muss das alles über die Konventionen umgesetzt werden?

    Diese Fragen möchte ich gern geklärt wissen und bin für Beitrage sehr dankbar.

    Vielen Dank
    Janek
    • 18 Jan 2010, 12:58 pm
  • Post visible to registered members
  • Post visible to registered members
  • Post visible to registered members
  • Post visible to registered members
  • Ralf Westphal
    Ralf Westphal    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re: Kunst und Regeln
    Jan:

    Es kommt weniger auf die Sprache an, ob du Komponentenorientierung leben kannst oder nicht. Wichtiger ist "der Geist" der Komponentenorientierung. Wie du den "beschwörst"... das kann auf unterschiedliche Weise geschehen, würde ich sagen. Deshalb die Frage: Was ist denn eigentlich dessen Kern?

    Komponenten sind größere Funktionseinheiten, die dem SRP folgen und mehrere Klassen zusammenfassen.

    Komponenten sind die kleinsten Einheiten, die ein Architekt plant. Das bedeutet im Umkehrschluss, ihre Existenz und ihre Beziehungen (dass eine Beziehung existiert und wie die aussieht (Kontrakt)) dürfen durch die, die sie implementieren, nicht einfach verändert werden.
    Das ist am einfachsten, wenn Komponenten physisch (!) möglichst entkoppelt sind und auch nicht einsehbar. Deshalb sollen sie (wenn möglich) binär sein in Implementation und Kontrakt. Und deshalb sollen Implementationen keine anderen Implementationen referenzieren. (s. dazu die CCD-Bausteine im blauen Grad)

    Wenn du diese Stabilität der Komponenten anders als binär und mit sauberer Trennung des Quellcodes der Komponenten hinkriegst... dann ist ja alles ok. Leider bezweifle ich, dass das einfach ist. Aber mit regelmäßigen Reviews könnte es gehen. Vielleicht ;-)

    Guten Mut!

    Ralf
    • 20 Jan 2010, 01:03 am
  • Jan Fellien
    Jan Fellien    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: Kunst und Regeln
    Ich hatte es mir schon gedacht, dass Python in CC-Hinsicht eher ein disziplinarisches Problem erzeugt statt einem technologischen. Aber diese Disziplin muss gelernt werden, was in vieler Hinsich Probleme bei den Entwicklern erzeugt, Stichwort: "Entwickeln ist ein kreativer Prozess, da kann ich mir nicht vorschreiben lassen wie ich das mache." Aber dann kann ich wieder mit dem Argument der Ärzte und dem Händewachen kommen ;-)

    Zur Zeit bin ich dabei dem Team die Möglichkeit eines Technologiewechsels zu eröffnen, was allerdings nicht wirklich gut ankommt. Sie möchten gern beim Bewährten bleiben, was auch nichts Schlechtes bedeutet, da dafür die Akzeptanz aufgebaut wurde.

    Also werde ich nicht par ordere du Mufti die Technologie wechseln, sondern "Zeremonien" entwicklen, die die Disziplin verstärken.

    Vielen Dank nochmal für die hilfreichen Kommentare
    Jan
    • 20 Jan 2010, 08:43 am
  • Post visible to registered members
  • Florian Künzner
    Florian Künzner
    The company name is only visible to registered members.
    Re^2: Kunst und Regeln
    Hallo!

    Ralf Westphal schrieb:
    Komponenten sind die kleinsten Einheiten, die ein Architekt plant. Das bedeutet im Umkehrschluss, ihre Existenz und ihre Beziehungen (dass eine Beziehung existiert und wie die aussieht (Kontrakt)) dürfen durch die, die sie implementieren, nicht einfach verändert werden.
    Wenn man im Sinne der Bausteine/Einheiten denkt, die eine Architekt beschreibt, dann sind das: Komponenten, Dienst u. Subsysteme. Wie auch immer diese definiert sind (z.B. Größe).

    Die Architektur eines Systems setzt sich aus mehreren Blickwinkeln zusammen: logische, technische, Implementierungs(Quelltext)-, Verteilungs- und Laufzeitarchitektur. Betrachtet man in diesem Zusammenhang die logische und die technische Architektur, bei der es um die Komponenten und deren Zusammenspiel geht, dann ist eine Komponente nicht die "kleinste Einheit".

    Die logische Architektur beschreibt die Komponenten und die Nachrichten, die zwischen den Komponenten ausgetauscht werden.
    Bei der technischen Architektur geht es auch um die Komponenten. Aber diesmal nicht mehr um die abstrakt formulierten Nachrichten, sondern um die konkret formulierten Schnittstellen (Kontrakte).

    Eine Komponente:
    - empfängt und/oder versendet ein oder mehrere Nachrichten;
    - exportiert und/oder importiert ein oder mehrere Schnittstellen.

    Für mich ist somit die kleinste Einheit nicht die Komponente, sondern die Nachricht oder Schnittstelle, die ein Architekt entwirft.

    Wie siehst du das, Ralf?

    Viele Grüße

    Florian Künzner
    • 22 Jan 2010, 2:36 pm