Wie stellt man sicher, keinen schlechten Code zu produzieren?

Eine Frage, die in Projekten immer wieder auftaucht. Warum? Weil beispielsweise das Management möchte, dass schneller entwickelt wird. Die Basis-Architektur der Software nicht mehr zeitgemäß ist oder die Dokumentation fehlt. Ken Schwaber macht immer wieder deutlich, dass die Software-Entwickler für die Qualität des Codes verantwortlich sind. In seinen Büchern, sowie auch in einer älteren Präsentation Canary in a Coal Mine, versucht er ein Bewußtsein dafür zu schaffen. Ziel ist es, Verständnis und Professionalität zu steigern, um schlechtem Code und aufwendige Wartungsarbeiten vorzubeugen. Solides Handwerk und Nachhaltigkeit, sieht er als die Schlüssel zum Erfolg. Wie schon berichtet, kommt die Entwicklung des Software Craftsmanship dieser Forderung nach. Der Titel, der kürzlich auf InfoQ erschienenden Präsentation From good to great Developer, unterstreicht nochmals die Aktualität des Themas.

Auf der anderen Seite spielt die Definition of Done eine wesentliche Rolle, um den Anspruch an gutem Code gerecht zu werden. Done definiert, was ein Projektteam damit meint, wenn es sich auf die Fertigstellung einer Story verpflichtet. Die Definition sollte entsprechende – mit dem Team verabschiedete und abgestimmte – Richtlinien enthalten, die festhalten wann Fertig auch wirklich fertig ist.

Kelly Walters hat hierfür eine 10 Punkte Liste aufgestellt:

Code produced (all ‚to do‘ items in code completed)
Code commented, checked in and run against current version in source control
Peer reviewed (or produced with pair programming) and meeting development standards
Builds without errors
Unit tests written and passing
Deployed to system test environment and passed system tests
Passed UAT (User Acceptance Testing) and signed off as meeting requirements
Any build/deployment/configuration changes implemented/documented/communicated
Relevant documentation/diagrams produced and/or updated
Remaining hours for task set to zero and task closed