Kategorien
Richtlinien
So eine kurze Überschrift hatten wir glaube ich noch nie. Vielleicht ist es ja eine Hommage an das Wochenende, das mal wieder viel zu kurz war und nein, wir hatten keine vier Tage frei, weil irgendein Feiertag überall anzufinden ist, nur nicht in Hamburg. Aber was soll’s, was uns nicht tötet … ihr wisst schon. Aber wieder zurück zum Arbeitsalltag, in den wir wohl alle heute starten dürfen.
Wir arbeiten relativ häufig mit externen Agenturen zusammen und haben auch gute Erfahrungen damit gemacht. Man gibt damit natürlich viel aus der Hand, deswegen sollte man den Externen vorher Richtlinien in die Hand drücken, damit sie wissen, wie man sich guten Code vorstellt. Das können Formatierungsregeln sein oder ganze Architekturkonzepte. Wir haben zum Beispiel ein langes Dokument mit unsere Coding-Guidelines, das ich mal vor 1,5 Jahren geschrieben habe. In den 1,5 Jahren habe ich eine Sache gelernt. Richtlinien können gar nicht hart genug formuliert sein.
Nehmen wir ein Beispiel. Der erste Wurf der Richtlinien hatte eine Empfehlung, dass die Komplexität nicht zu hoch sein darf (wir hatten dafür die zyklomatische Komplexität herangezogen). Ein fester Wert war gesetzt und die Richtlinien gingen raus. Irgendwann kam das Projekt von der Agentur zurück und wir hatten jede Menge Verstoße gegen diese Regel. Da die Agentur aber schon am Limit des Budgets war haben sie diese Punkte nicht mehr umgebaut, weil sie ja laut „Vertrag“ nicht dazu verpflichtet sind. Und was soll ich sagen, sie haben Recht. Wahrscheinlich hätte ich auch so reagiert.
Was haben wir dann gemacht? Wir sind hingegangen und haben die Punkte als verpflichtend aufgenommen. Hausintern haben wir aber immer gesagt, dass wir es weiterhin als Empfehlung sehen. Dies hatte zur Folge, dass bei jedem Verstoß der interne Reviewer selbst entscheiden durfte, ob das jetzt wirklich repariert werden muss oder nicht.
Wenn ich jetzt zum Kick-Off mit den Agenturen an einem Tisch sitze, dann erkläre ich immer, dass die Richtlinien jetzt erstmal so hart sind, wie sie sind, aber wir alle Entwickler sind und wissen, wann man mal gegen Regeln verstoßen muss. Alles ist erlaubt, wenn man es argumentieren kann und es Sinn macht. Die Argumentation liegt somit aber auf der Seite der Agentur, wo sie auch hingehört meiner Meinung nach. Wir sind auch gar nicht so hart wenn es dann um Verstöße geht, denn die meisten sind gut durchdacht, da man ja verhindern will überall anzuecken.
Das kommt mir sehr bekannt vor. Die Richtlinien sollten möglichst kein „Schlupfloch“ bieten.
Ich habe die Erfahrung gemacht, dass die externen Dienstleister (Agenturen, Freelancer, etc.) sehr kreativ in der Art der Umsetzung sind, wenn ein Punkt zu viel Interpretationsspielraum bietet.
Deshalb finde ich die Art und Weise, die du beschreibst, mit diesem „Problem“ umzugehen ganz praktikabel. Letztlich haben alle ein gemeinsames Ziel und dieses sollte im Vordergrund stehen. Das der Auftraggeber das „letzte Wort“ hat ist ebenfalls korrekt. Wichtig ist, dass die Richtlinien im Rahmenvertrag festgehalten werden und bei Aktualisierung eine erneute, schriftliche Bestätigung durch den Auftragnehmer eingeholt wird.
Wir haben zusätzlich intern einen Prozess angedockt, dass wenn immer es nach Projektfertigstellung einen Punkt gab, an dem etwas nicht ganz eindeutig definiert, bzw. nicht nach unseren Vorstellungen umgesetzt wurde, die Richtlinien entsprechend erweitert wurden. Das Ergebnis der internen Besprechung und die daraus resultierende Erweiterung wurde im Anschluss dann auch mit dem Dienstleister besprochen (Erweiterung Rahmenvertrag).
Fazit:
Das Verfassen von Richtlinien ist wichtig und vor allem ein andauernder Prozess …
Besteht denn die Möglichkeit, an die von dir verfassten Coding-Guidelines heranzukommen?
Es würde mich durchaus mal interessieren, wie sowas nach jahrelanger Entwicklung aussieht. 😉
Ich schließe mich Monti an, da ich mich auch schon seit längerem mit dem Thema Coding-Guidelines beschäftige und gern mal ein Beispiel aus der Praxis sehen würde.
@Steve:
Ich denke mal, dass sich der neue Artikel (http://www.phphatesme.com/blog/webentwicklung/big-brother-is-watching-you/) damit befassen wird. 😉
Ein guter Anhaltspunkt sind die Coding Conventions von PEAR.
Ich nutze in meinen Projekte PHPCS und verwende eine angepasste Version des PEAR Standards.
Zum Beispiel wird hier festgelegt das Variablen in Camel Case geschrieben werden müssen,
wie die Klammern gesetzt werden, Einrückung, max. Zeilenlänge etc.
An manchen Stellen ist der Standard etwas veraltet, weil er sich an „Vereinbarungen“ aus den
alten C99-Zeiten hält, beispiel geschweifte Klammer immer in der nächsten Zeile öffnen oder
eine maximale Zeilenlänge von 80 Zeichen.
Da man bei PHPCS auch einen eigenen Standard definieren kann, hab ich einfach den PEAR Standard
kopiert und entsprechend auf meine Anforderungen angepasst.