Clean Code Developer

Clean Code Developer

Posts 11-12 of 12
  • Ralf Westphal
    Ralf Westphal    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^5: erste Schritte
    hallo, martin!

    unser Team ist tatsächlich geteilt. Im Prinzip sogar in 3 Standorte. Zum einen sind wir in unserer eigenen Firma in 2 nebeneinanderliegende Gebäude aufgeteilt und der Kunde ist geographisch noch weiter entfernt. Innerhalb der Firma treffen wir uns einmal täglich zu einer kurzen Besprechung um uns auszutauschen.
    aha, ein wesentlicher hinweis! ihr macht also nicht nur organisatorisch verteilte entwicklung, sondern auch geografisch. das ist natürlich völlig ok und auch nicht zu vermeiden. linux wird auch so entwickelt :-)

    aber ich denke, der schmerz, den du beschreibst, lässt sich eben darauf zurückführen: je weiter räumlich und kulturell auseinander teamteile sind (oder eben die verschiedenen teams), desto schwieriger ist es, an einer sache zusammen zu arbeiten. im großen könnt ihr es auch nicht aussuchen: an der applikation arbeitet ihr zusammen. aber im kleinen... könnte es da nicht anders gehen? warum müssen solche verteilten teams an derselben klasse, an derselben assembly arbeiten? womöglich gleichzeitig, so dass dateien im repo zusammengeführt werden müssen.

    das halte ich für bedenkenswert. ccd bietet ja bausteine, die es leichter machen: die komponentenorientierung und die aufteilung von code in werkbänke und das open-close-prinzip.

     
    Was den Kunden angeht, gibt es einen Ansprechpartner auf unserer und einen auf Kundenseite. Abstimmung gibt es aber fast außschließlich, was die Aufgaben angeht, die wir erledigen sollen. Was der Kunde konkret am SourceCode macht wird uns nur schemenhaft mitgeteilt.
    vielleicht ist dieses symptom ein hinweis darauf, dass ihr auch gar nicht in deren sourcecode schauen solltet? warum den code nicht so organsieren, dass es euch einfach nicht zu interessieren braucht? OCP, SoC, SRP, Contract-first Design... das alles hilft dabei - und die schlechte laune ist wie weggeblasen ;-)

    nicht "die müssen unsere konventionen einhalten, damit wir deren quellcode besser verstehen", sondern "wir müssen den code so strukturieren, dass uns deren quellcode nicht interessiert".


     
    Die gemeinsame Schnittstelle in Sachen Code ist die SourceCode-Verwaltung, auf die alle Teamteile Zugriff haben.
    das ist ja absolut ok. da soll auch alles zusammenlaufen. allerdings würde ich raten, es deutlich im repo zu trennen, woran die einen und die anderen arbeiten.

    denn ansonsten gilt auch conway´s law hier: so wie die organisation strukturiert ist, so ist ihr produkt strukturiert. dagegen wehrt ihr euch noch. das macht wund, sich gegen ein gesetz zu wehren. wenn es - aus welchen gründen auch immer - diese 3 organisationsteile gibt, dann sollten die sich deutlich im code widerspiegeln. alles andere führt zu spannungen. also: entweder code umstrukturieren, so dass die 3 teams ganz natürlich damit arbeiten können. oder die teams umstrukturieren entsprechend dem code, d.h. es muss ein team werden, weil anscheinend der code heute versucht wird so zu behandeln.


     
    Absprachen, die wir mit den Entwicklern auf Kundenseite treffen haben oft nur kurz Bestand, da der Abteilungsleiter auf Kundenseite sich nicht an sein "Geschwätz von gestern" gebunden fühlt und Dinge anweist, die unseren Absprachhen widersprechen.
    das ist kein teamverhalten. ist das gut oder schlecht? das hängt vom anspruch an den code ab. wenn man im code darauf angewiesen ist, dass absprachen eingehalten werden, was seine interna angeht, dann ist es schlecht. wenn man den code so stark entkoppelt, dass solche wetterwendischkeit quasi unsichtbar für andere ist, dann ist es ok.


     
    Das ist die eine Seite, die wir nicht direkt ändern können. Auf der anderen Seite sind nur Teile unseres eigenen Teams dazu bereit, sich auch mal außerhalb der normalen Geschäftszeiten sich mit dem Thema Clean Code außeinander zu setzen und die Disziplin aufzubringen, sich an derartige Regeln zu halten. Nur mit gutem Zureden kommen wir da leider nicht weiter und es fehlt die Unterstützung von Vorgesetzten um dieses Ziel anderweitig durchzusetzen.
    ich bin auch nicht dafür, viel zeit außerhalb der arbeit in fortbildung zu stecken. mal ne zeitschrift lesen oder ein buch. das ist ok. oder mal eine user group besuchen. 3-5 std die woche höchstens. ansonsten muss der weg nach ccd innerhalb der arbeitszeit gefunden werden. das buch mit scrum und user stories, das ich in einem anderen posting empfohlen habe, gibt tipps, wie man soetwas in form eines kundenutzens formulieren kann.


     
    Der "willige" Teil des Teams hat sich jetzt soweit abgestimmt, dass wir für uns eine Zeit lang versuchen wollen, unser Bestes in Sachen Clean Code zu geben, soweit es unter diesen Bedingungen möglich ist, in der Hoffnung, dass unsere Kollegen die Vorteile sehen und diesem Weg folgen.
    ich wünsche viel erfolg! geht einfach in kleinen schritten vor! nehmt euch nicht zuviel vor.

    cheerio!

    ralf


     
    Viele Grüße
    Martin
    • 14 Aug 2009, 11:29 am
  • Thomas Ohlrogge
    Thomas Ohlrogge
    The company name is only visible to registered members.
    Re^3: erste Schritte
    Hallo Ralf,

    vorab großen Dank für die umfangreichen Informationen. In unserer Firma wollen wir zukünftige Projekte auch über Scrum realisieren. Die von Dir vorgeschlagenen Bücher haben wir uns bereits bestellt. Doch eine Frage, die immer wieder auftaucht ist, kann man dem Kunden über agiles Projektmanagement, wie beispielsweise Scrum, eine Aufwandsschätzung mit einer ungefähren Zeitangabe geben, wann ein gefordertes Projekt umgesetzt ist. Viele Kunden verlangen dies verständlicherweise auch. In statischen Projektanalysen kann man dies ermitteln, wobei die Erfahrung gezeigt hat, dass eine Punktlandung fast unmöglich ist.

    Gruß

    Thomas

    "deshalb überlegt doch mal, ob ihr euren traum nicht ändert. träumt doch mal von der einführung von timeboxes ohne fixen scope. wie wäre das? das ist (für den kunden) gewöhnungsbedürftig, aber viiiel realistischer. dieses buch kann ich dazu grad empfehlen:

    http://www.amazon.de/Scrum-User-Stories-Ralf-Wirdemann/dp/34....

    ein wenig scrum-vorwissen ist dafür allerdings nützlich. wer das noch nicht hat, der kann vorweg dies lesen:

    http://www.amazon.de/Scrum-Produkte-zuverlässig-schnell-entw...

    beide bücher von hanser sind nicht nur schön anzufassen, sondern auch gut zu lesen, finde ich."
    • 19 Aug 2009, 09:10 am