Codequalität verbessern

[Balo]

Hallo!

Ich wurde in meiner Firma damit beauftragt die Codequalität allgemein zu verbessern. Teilweise wird hier grauenhafter Code geschrieben. Methoden mit 100ten Zeilen und fernab jeglicher Objektorientierung.

Ich habe jetzt einige Regeln (Codeanalysis / FxCop) eingeführt. Das wird die Sache bestimmt etwas verbessern, aber der Weisheits letzter Schluss ist es auch nicht.

Ich könnte natürlich zu den Leutern einzeln hingehen und mit ihnen ihren Codedurchsprechen. Ich befürchte nur, dass mein Chef das nicht bezahlen möchte (kostet ja einiges an Zeit).

Ich suche also nach kreativen Denkanstößen wie ich die Codequalität in der Firma mittel-/langfristig verbessern kann.

Grüße!

[flashpixx]

Ich würde einfach mal bei dem Problem anfangen, dass eben den Code schreibt. Außerdem kannst Du nicht erwarten, dass Du von heute auf morgen die Probleme lösen kannst.

Die gängigste Methode ist ein Style-Guide zu entwickeln und die Mitarbeiter darauf hin zu schulen. Du entwickelst also ein verbindliches Regelwerk, wie neuer Code produziert wird. Jeder Code, der neu erzeugt wird, muss diesem Regelwerk entsprechen. Mit der Zeit sollte dann auch bestehender Code diesen Richtlinien angepasst werden.

100 Zeile Code in einer Methode können durchaus ihre Berechtigung haben, aber sie müssen eben dann dokumentiert und den Regeln entsprechen.

Bearbeitet 3. Dezember 2010 von flashpixx

[Klotzkopp]

Beteilige die Mitarbeiter am Erstellen von Styleguides, das erhöht die Akzeptanz solcher Regelwerke. Vielleicht kannst du Codefragmente rumschicken, zu denen die Mitarbeiter sagen können, was ihnen gefällt, und was sie verbessern würden. Frag die Mitarbeiter nach Vorschlägen, wie man eine Qualitätskontrolle umsetzen könnte.

[flashpixx]

Beteilige die Mitarbeiter am Erstellen von Styleguides, das erhöht die Akzeptanz solcher Regelwerke.

Da schließe ich mich an, vor allem ist das aus meiner Sicht der wichtigste Punkt, denn die Mitarbeiter müssen dieses Regelwerk umsetzen, d.h. wenn Du es nicht schaffst, dass es akzeptiert wird, dann wirst Du auch nie zu einem Ziel kommen

[lbm1305]

Ggg. kannst Du Dir auch die 4teilige Webcastserie "Codequalität" von Golo Roden ansehen. Zu finden im Webcast-Archiv auf msdn-online.de

Beim Thema 100 Zeilen in eine Methode und dokumentieren bin ich anderer Ansicht. Eine Methode sollte genau eine Aufgabe haben. Bei 100 Zeilen sind es mehr als eine Aufgabe. Durch gutes Refactoring kann diese Methode gewiss in mehrere Methoden zerlegt werden. Und durch selbstbeschreibende Benamung braucht man dann auch keine Dokumentation (Inlinecode).

Hier kann man sicherlich anderer Meinung sein. Ich persönlich handhabe es ohne Inline-Dokumentation.

[flashpixx]

Eine Methode sollte genau eine Aufgabe haben.

Full Ack

Bei 100 Zeilen sind es mehr als eine Aufgabe. Durch gutes Refactoring kann diese Methode gewiss in mehrere Methoden zerlegt werden.

Im Normalfall würde ich sagen, ja, aber ich habe hier definitiv zwei Sonderfälle wo ich ca 120 Zeilen habe, die zu einer Methode gehören (eine Pseudo-Newton Methode für eine Sammon-Map einer MDS).

Dies ist ein Sonderfall und auch so ind er Doku bzw im Code vermerkt.

Und durch selbstbeschreibende Benamung braucht man dann auch keine Dokumentation (Inlinecode).

Sofern man das konsequent durchhält. Ich nutze gerne Doxygen, weil ich dann direkt den Code kommentieren kann. Gerade bei einer Umstellung würde ich die Benamung in der Doku vermerken, so lange bis nicht alle Codeteile wirklich dem Style Guide entsprechen.

[lilith2k3]

Clean Code Developer - Clean Code Developer

Mit schicken Armbändern