Clean Code Developer

Clean Code Developer

Posts 1-6 of 6
  • Louis Haußknecht
    Louis Haußknecht    Premium Member
    The company name is only visible to registered members.
    CCD Erfahrungen
    Hallo zusammen,

    ich möchte gerne kurz über meine CCD Erfahrungen berichten.

    1. In kleinen Projekten
    Ich habe ein paar kleinere Projekte realisiert in denen ich der einzige Entwickler war. Dort ist es immer wieder erstaunlich wie der innere Schweinehund mich daran gehindert hat, größere Refactorings durchzuführen.
    Zeitdruck und der Gedanke, man stehe ja kurz vor dem Ziel haben verhindert, dass so mancher Code-Smell beseitigt wurde.
    Natürlich hat sich das gerächt, denn nach einem Jahr wollte der Kunde Erweiterungen haben, und dann sieht man schnell, dass man die Pfadfinder-Regel doch besser hätte gleich beachten sollen.

    2. In Projekten im Team
    Bei Teamprojekten kommt es auf das Mindset der Teammitglieder an.
    Ganz vorne muss natürlich der Gedanke des Shared Code Ownership stehen. Schon oft bin ich über Code-Smells gestolpert, die ich dann beseitigt habe und hinterher kamen doofe Kommentare wie „Warum hast Du denn da an meinem Code was geändert?“ oder „Never touch a running system“.

    Lebt das Team für Software und hat auch immer den Gedanken, etwas verbessern zu wollen, dann sieht die Sache gleich ganz anders aus.
    Der Wille etwas zu verbessern, sich mit der Materie zu beschäftigen und weiter zu bilden kann eine ganz tolle Erfahrung für das Team sein und ist nur gut für das Produkt.
    • 22 Jun 2009, 10:05 am
  • Andreas Leue
    Andreas Leue    Group moderator
    The company name is only visible to registered members.
    Re: CCD Erfahrungen - Metaphern fürs Team
    Hallo Louis, hallo allerseits,

    zum Thema Pfadfinderregel und Ownership fallen mir noch ein paar Metaphern ein, die wir im Team gelegentlich verwenden und die dazu beitragen können, auch anderen gegenüber den Sinn dieser Übungen zu illustrieren.

    1.) Gartenarbeit

    Viele Begriffe aus der Gartenarbeit wie Unkraut jäten, Holz hacken, umpflügen, junge Plänzchen setzen, etwas aussäen passen sehr treffend auf Entwicklung, und jedem ist unmittelbar klar, was damit gemeint ist und wie man sich verhalten sollte. Etwa: junge Plänzchen setzen, naja, da muß man vorsichtig sein, ein wenig Schutz geben, regelmäßig draufschauen usw.

    Ich meine auch, daß das Bild des Gartens auf sehr liebevolle Weise vermittelt, warum es ein collective ownership gibt. "Hey, ich habe in Deinem Beet mal etwas Unkraut gejätet" klingt viel netter als "Du hast da aber ganz schönen Mist geschrieben, ich hab das mal richtig gemacht".

    2.) (Holz-)Handwerk

    Die optisch und haptisch ansprechende Welt des Bauens, speziell mit Holz und anderen schönen Materialien, taugt auch gut für Vergleiche: ich habe in Deiner Komponente nochmal ein paar Sicherungsbolzen eingeschlagen und so. Die materielle Welt im allgemeinen versinnbildlicht die Trennung von Produkt und Schöpfer und hilft, den eigenen Code "loszulassen" - bei aller Begrenztheit, die eine solche Analogie natürlich mit sich bringt.

    Nicht ohne Absicht dürfte auch die "Craftsmenship"-Bewegung diese Konnotationen mit sich führen.

    3.) Go (Brettspiel)

    Nicht allzu bekannt, aber wenn doch, recht nützlich. Insbesondere in nicht ausschließlich romantisch-friedlichen Projektsituationen, wie sie ja hin und wieder auftauchen sollen. Kann dann zur Kommunikation innerhalb der eigenen Untergruppe herhalten (die Stellung lebt noch nicht usw.)

    Viele Grüße,
    Andreas
    • 22 Jun 2009, 12:28 pm
  • Thomas Schulte
    Thomas Schulte
    The company name is only visible to registered members.
    Re^2: CCD Erfahrungen
    Hallo zusammen,

    das mit den Team ist eine defiziele Sache. Code eines anderen Entwicklers zu korrigieren kann aus menschlichen Aspekt doch schon mal eine heikle Sache werden.

    "Warum korrigiert er den das, ist das nicht schön genug?"

    Wenn man das nicht richtig anpackt, findet der eine oder andere sich schnell in eine Defensiv Position wieder und ist "beleidigt".

    Ich denke es gibt da einen ganz guten Aspekte um das Thema menschlich angenehemer zu gestalten.

    Mit den zweiten Entwickler drüber reden was man ändern könnte und mit Argumenten überzeugen. Dann den Code von Ihn selber ändern lassen. Oft ist es ja auch so das gewisse "Module" in der Regel von einen Entwickler gepflegt werden.

    Mit freundlichen Grüßen
    Thomas
    • 29 Jul 2009, 1:48 pm
  • Ralf Westphal
    Ralf Westphal    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^3: CCD Erfahrungen
    Hallo, Thomas!

    Entwicklers zu korrigieren kann aus menschlichen Aspekt doch schon mal eine heikle Sache werden.
    Da beschreibst du ein Faktum - aber das bedeutet ja nicht, dass es so sein sollte. Was wäre also zu tun, damit Änderungen nicht zu einem Konflikt führen. Nicht immer ist ein Gespräch möglich.

    Mit fällt da zweierlei ein:
    1. Es muss allen formal klar sein, dass sowas passieren kann und muss. Wo die Pfadfinderregel in einem Team gilt, ist solche "Fremdänderung" sogar eine Tugend. Das bringt mich zum zweiten Punkt:
    2. Es muss im Team eine Leitlinie geben, "wohin" Code verändert werden sollte. Da dürfen nicht soviele Meinungen wie Teammitglieder aufeinanderprallen, denn dann kommt es zum Pingpong-Spiel. A ändert nach A-Gusto, dann ändert B nach B-Gusto, dann wieder A nach seinen Vorstellungen, dann C nach C-Gusto usw. Das geht nicht. Es muss eine gemeinsame Vision geben, auf die zu alle den Code jederzeit verändern können. Eine solche Vision bietet CCD. Änderungen können (und sollen) dann immer mit Hinweis auf einen CCD-Baustein begründet werden. Da geht es nicht um "mehr schön", sondern "mehr CCD".

    Mit den zweiten Entwickler drüber reden was man ändern könnte und mit Argumenten überzeugen. Dann den Code von Ihn selber ändern lassen. Oft ist es ja auch so das gewisse "Module" in der Regel von einen Entwickler gepflegt werden.
    Auch nett, den anderen ändern zu lassen. Aber das mag viel Zeit kosten. Warum dann nicht gleich Pair Programming? ;-)

    -Ralf

     
    Mit freundlichen Grüßen
    Thomas
    • 29 Jul 2009, 8:38 pm
  • Andreas Leue
    Andreas Leue    Group moderator
    The company name is only visible to registered members.
    Re^4: CCD Erfahrungen
    Hallo Ralf,

    stimme Dir vom Ziel und Ansatz her zu...

    2. Es muss im Team eine Leitlinie geben, "wohin" Code verändert werden sollte ...
    Eine solche Vision bietet CCD...
    ...denke aber, daß die Leitlinie nur funktioniert, wenn das Team als Basis diese Gedanken auch alle mitträgt und versteht und relativ harmonisch zusammengesetzt ist - was bekanntlich nicht immer der Fall ist. CCD ist als Leitlinie/Leitplanke notwendig, aber nicht hinreichend.

    KISS bspw. läßt sich wunderbar gegen viele der anderen CCD-Bausteine ausspielen und wurde in der Vergangenheit auch immer wieder im großen Stil, bevorzugt von Seiten der terminverantwortungsnäheren Menschen oder weniger begnadeten Entwickler gegen allerlei "eher komplizierte" Tugenden (OLOA, LoD, Test Driven, etc. etc.) ins Feld geführt.

    Ich meine sogar fast, man sollte KISS und YAGNI nur paßwortgeschützt veröffentlichen, wobei das Paßwort auf der Innenseite der weißen Armbänder eingeprägt ist ;-)

    Viele Grüße,
    Andreas
    • 02 Aug 2009, 12:12 pm
  • Ralf Westphal
    Ralf Westphal    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^5: CCD Erfahrungen
    hi, andreas!

    das ist ein interessanter aspekt: KISS gegen CCD im einsatz. hm... "leute haltet die programmierung einfach! keine unnötige anwendung von CCD prinzipien!" :-)

    und ich stimme dieser anwendung von CCD auf sich selbst durchaus zu. nicht jedes prinzip muss sofort angewendet werden, code muss nicht immer bei 100% "CCDkonformität" sein. YAGNI gilt auch in bezug auf CCD-bausteine: manche refaktorisierung muss nicht (jetzt) unternommen werden, weil unklar ist, wann man von ihr profitiert.

    allerdings besteht immer die gefahr, dass man sie eben auch nicht unternimmt, wenn man sie braucht. daher ist das so eine sache mit dem aufschieben der refaktorisierungen.

    eine gesunde selbstdisziplin kann also niemandem abgenommen werden: anforderungen umsetzen und CCD bausteine anwenden muss sich die waage halten. keines darf dem anderen geopfert werden.

    das ist dann auch die allgm kritik an der obigen anwendung von KISS. KISS so verstanden gibt alles andere zugunsten von KISS auf. das (!) kann nicht sein. CCD definiert ein wertesystem. in dem ist produktionseffizienz aber nur ein wert. wenn ich immer nur KISS, KISS, KISS anwende, dann bin ich im augenblick vielleicht effizienz - aber mittelfristig leiden evolvierbarkeit, korrektheit und reflexion. und auch zukünftige produktionseffizienz.

    ergo: wer immer nur "KISS!" ruft, dem muss man gleich die frage stellen, wie er´s denn mit den anderen werten hält.

    -ralf
    • 02 Aug 2009, 8:20 pm