Clean Code Developer
Posts 1-6 of 6
-
Christof Hahn Premium MemberThe company name is only visible to registered members.Manchmal lohnt es sich mehrfach über ein Problem nachzudenken"
Und daher ist der erste Entwurf selten der Beste. Gerade bei der Softwareentwicklung ist das so. Ich arbeite in einem sehr speziellen Umfeld. Ich entwickele z. Z. elektronische Schließsysteme und diese sollen nicht nur 99,9999% des Jahres funktionieren sondern immer! Als kleine Zugabe müssen diese Systeme auch noch energieeffizient sein. Das heißt die eingesetzten Batterien sollen so wenig wie möglich (z. Z. jährlich in der nächsten Generation streben wir 5 Jahre an) gewechselt.
Bei diesen Systemen ist also klarer gut wartbarer und portierbarer Code überlebenswichtig. Im Gegensatz zu den meisten anderen hier im Forum arbeite ich nicht mit einer Objektorientierten Programmiersprache sondern mit C. Für meinen Arbeitgeber entwerfe ich z. Z. ein Betriebssystem, dass die obigen Anforderungen möglichst optimal umsetzt.
ClearCode-Prinzipien sind deshalb ein wichtiger Teil meiner Arbeit. Am meisten beschäftigit mich dabei die Frage, wie man diese Prinzipien in einem Team einbringt.
Viele Grüße aus Bonn
C. Hahn
- 19 Aug 2009, 9:52 pm
-
Ralf Westphal Premium Member Group moderatorThe company name is only visible to registered members.Re: Manchmal lohnt es sich mehrfach über ein Problem nachzudenken"
Hallo, Christof!
Wenn das - "klarer gut wartbarer und portierbarer Code überlebenswichtig" - wirklich bei euch so ist, dann hast du allerbeste Voraussetzungen, CCD einzuführen. Denn dann hat deine Organisation schon das Ziel, das CCD verfolgt. Dann kannst du CCD-Bausteine einführen und findest bei der Begründung immer Anknüpfungspunkte in eurem gemeinsamen Ziel.
Viel Erfolg!
Ralf
- 20 Aug 2009, 12:12 am
-
Post visible to registered members
-
Robert KopezkyThe company name is only visible to registered members.Re^3: Manchmal lohnt es sich mehrfach über ein Problem nachzudenken"
hallo stefan,
meine persönliche erfahrung hat gezeigt, dass die unterstützung für eine änderung von einem team größer ist, wenn die argumente für die änderung keine bedrohungsszenarien sind.
darum würde ich dem team gegenüber weder mit den zu erwartenden kosten aufgrund von softwarefehlern noch mit den gefahren für die nutzer argumentieren.
mein vorschlag wäre daher, die für das team als ganzes aber auch für jedes teammitglied persönlichen vorteile der angestrebten änderung in den vordergrund zu stellen.
CCD kann z.B. aus meiner sicht zu kosteneinsparungen aufgrund steigender effektifität bei änderungen führen, die die arbeitsplatzsicherheit einerseits (wobei bei dem argument bis zu einem gewissen grad auch mit ängsten argumentiert wird) und höheren einkommen für den einzelnen führen.
ein weiteres argument kann z.B. ein größerer deployment-erfolg sein (was rein inhaltlich und technisch sicher mit weniger problemen beim und nach dem deployment zusammenhängt, aber positiver belastet ist).
lg robert
- 20 Aug 2009, 08:30 am
-
Post visible to registered members
-
Robert KopezkyThe company name is only visible to registered members.
Re^5: Manchmal lohnt es sich mehrfach über ein Problem nachzudenken"
hallo stefan,
bezüglich motivatoren im allgemeinen gebe ich dir recht, dass diese nicht immer nur positiv besetzt sein können und sollen.
der wichtige unterschied für mich war nur, dass es während dem prozess einer veränderung einfacher und effiktiver ist, mit positiven motivatoren das team und die mitglieder zur kooperation zu bewegen.
in der täglichen arbeit des führens und förderns der mitarbeiter ist sicher "zuckbort und peitsche" notwendig! ;-)
lg r
- 21 Aug 2009, 08:03 am
