Kategorien
Sind Restriktionen der richtige Weg?
Irgendwie habe ich euch in den letzten Artikeln ziemlich oft um eure Meinung gebeten. Da das irgendwie ganz gut geklappt hat, möchte ich doch heute mal wieder drauf eingehen. Wir machen es wie immer, ich bringe erstmal meine wirren Gedanken zu „Papier“ und dann dürft ihr loslegen und in den Kommentaren rumdiskutieren.
Gehen wir aber einfach mal ein „paar“ Jahre zurück. Da habe ich bzw. wir angefangen Coding Guidelines aufzustellen. Wir haben bis ins kleinste Detail definiert, was wie auszusehen hat. Ich glaube das ganze Manifest hatte 10 Seiten. Junge waren wir stolz, denn jetzt wird alles besser. Wir haben danach auch mit dem PHP_CodeSniffer hantiert, um Verletzungen gehen diese Regeln automatisiert zu finden und gegebenenfalls anzumahnen. Alles ganz toll.
Dann einige Zeit später hatten wir das „Glück“, dass wir Fabien Potencier für drei Tage im Hause hatten und natürlich haben wir auch mit ihm über solche Guidelines geredet. Dabei war seine Meinung relativ klar, Guidelines ja, aber stasiartiges Verfolgen nein. Da ich natürlich alles in Frage stelle, was ein Franzose so von sich gibt, fand ich das natürlich anfänglich einen doofen Ansatz. Aber ein wenig später habe ich mich dann doch überzeugen lassen. (Das mit dem Franzosen sollte übrigens nur ein Witz sein). Hat eh nichts gebracht, die paar Verstöße, die neu dazu kamen sind eh nicht ins Gewicht gefallen, so dass wir sie hätten verfolgen können.
In diesem Fall ist es also so, dass man gerne Regeln definieren soll, die auch jedem klar sind, aber dass man nicht jeden Verstoß sofort ahnden muss. Wir sind ja keine Code-Nazis. Oje muss ich jetzt laut Jugendschutzgesetz den Beitrag wegen dem N-Wort auf 18 stufen? Egal. Wird schon keiner merken.
Gehen wir aber nochmal zum Symfony-Menschen und die Art, wie er mit Restriktionen umgeht. Vielleicht haben ja einige mitbekommen, dass das Symfony-Framework sich dazu entschieden hat alle seine Methoden auf mindestens protected von der Sichtbarkeit her zu legen. Finde ich zum Beispiel eine ganz ganz fiese Idee. Auf diese Art, wird überhaupt keine Restriktion für die Erweiterung des Frameworks geschaffen. Jeder kann und wird erweitern, wo er nur will. Ich kenne das auch Projekten, in denen ich gearbeitet habe. Das wird ziemlich schnell so ausarten, dass keiner der Framework-Anfänger noch updaten kann, weil Schnittstellen angefasst wurden oder ähnliches. Dabei ist Information-Hiding doch so ein tolles Prinzip.
Hier haben wir also einen anderen Fall. meiner Überzeugung nach muss zum Beispiel klare Regeln definieren, wie es zu nutzen ist, sonst landet man irgendwann in der Wartungshölle, da man ja nur mit öffentlichen Schnittstellen zu kämpfen hat und bei jeder Änderung im Kern oder irgendwo aufgepasst werden muss, was man damit anrichtet. Ich bin ja mal hingegangen und hatte eine Projektwerkstatt zusammengeklöppelt, in der ich so etwas wie ein Schichten-Model einführen und validieren wollte.
Um auf meine anfängliche Frage zurück zu kommen. Man kann wohl nicht beantworten, ob Restriktionen der richtige Weg sind, weil so eine Pauschal-Aussage schwer zu treffen ist. Ich würde aber ganz klar eine Architektur definieren, an die man sich halten MUSS. Da führt kein Weg vorbei. Bei allem anderen kann man dann von Fall zu Fall entscheiden.
Ich denke das hängt ganz von der Lebensdauer / Wartung / Flexibilität des Projekts ab.
Wenn ich ein Softwareprodukt auf 10 Jahre Lebensdauer schreiben soll, und das natürlich nicht alleine, dann muss ich schon sehr genau auf die Architektur und viele einzelne Designschichten/Domainschichten einführen.
Und das sollte ich als Architekt machen, und mich nicht blind auf die Frameworks verlassen, wer weiß, wird z.B. Symfony in 5 Jahren überhaupt noch weiterentwickelt, oder es gibt vl bessere Alternativen am Markt (naja, Sympony wirds schon noch geben 😉 )
Wenn ich Projekte habe die nicht ganz so flexibl sein müssen (weil Anfos sich nie mehr, oder sehr selten ändern) kann eine schlanke Architektur, ohne viel Designrichtlinien schneller zum Projekterfolg beitragen.
Was Coding-Standards angeht muss man mal definieren wie weit diese gehen.
Wenn der Standard nur vorsieht das Variablen klein und Klassen groß geschrieben werden und Interfaces mit I begonnen, dann sehe ich das eher als eine Guideline. Und Guidelines sind, wie der Name sagt, Leitfäden, keine Regeln. Da hats überhaupt keinen Sinn diese zu verfolgen, und dem Juniordeveloper mit der Rute zu drohen. Beim Code-Review einfach mit ihm durchgehen und ihm diese nochmal ins Gedächtnis rufen.
Dank guter Refactoring-Tools sind das meistens grade mal 5 min Arbeit.
Wenns um Richtlinien zwecks der Architektur geht, ists gerade in PHP ne gute Frage wie man es löst… Kein Compiler der dir auf die Finger klopft, und die Unittests tun sich auch schwer herrauszufinden ob die Architektur eingehalten wurde.
Jedoch ist eine zu strenge Architektur manchmal auch unflexibel oder umständlich zu Bedienen. Und sie hemmt den Programmierer dabei, besser zu werden. Wenn er sich selbst etwas Gedanken machen kann um die Flexibilität seiner Lösung, wird er zwar nicht über Nacht zum Architekten, aber in einigen Jahren vielleicht.
Jüngere Programmierer muss man eher im Zaum halten, die sind so oft übereifrig, und tun sich dann weh 😉
Senior Developer sind oft schon etwas zu ruhig oder bedacht um auch mal eine neue Architektur zu verwenden/entwerfen.
Fazit.: Coding-Nazis nein. Architektur-Nazis nur wenns erforderlich ist 😉
das ist wie auf einer einsamen insel: desto weniger menschen dort leben desto weniger gesetze, du schreibst restiktionen, werden benoetigt.
desto mehr menschen, je groesser die insel, desto mehr regeln werden gebraucht.
warum war java so erfolgreich im business und enterprise?
es hat schon im kern so viele restriktionen die alle befolgen und lernen muessen. und alle schreien sogar hurra fuer die ganzen zwaenge denen sie unterworfen werden, siehe typisierung.
php ist dagegen wie eine bunte blumenwiese. aber auch da: desto mehr ochsen ueber die wiese laufen desto mehr zaeune braucht man.
Ich möchte mal ein Gegenbeispiel zu Symfony aus der Java Welt anbringen. Ich bin in einem GWT Projekt und dort müssen wir, wie das wohl immer wieder vorkommt, spezielle Widgets nutzen, die GWT so nicht bietet. Im Grunde könnte man diese Anpassungen relativ klein halten, jedoch sind sehr viele Dinge in GWT private und somit nicht ereichbar. Das führt dazu, dass man komplizierte Workaround programmiert oder was mE noch schlimmer ist, den GWT Source in eine Klasse kopiert und die 3 Zeilen anpasst. Wenn man im Internet etwas forscht, sind wir damit nicht alleine.
Ich denke, der Mittelweg muss das Ziel sein. Einerseits will ich nicht alles zugreifbar haben, andererseits aber auch Platz für Erweiterungen halten. Man was nie, wer eine Komponente wie und wofür nutzt. Insbesondere bei einem Framework.
Bei einem Einzelprojekt ist meine Meinung aber eher die, dass man nur publiziert, was notwendig ist. Im Wartungsfall muss eben ein Refactroing durchgeführt werden.
Die Wartbarkeit macht in Enterprise Projekten 50% des Projekterfolges aus. Diese wird auch zum grossen Teil durch die Einhaltung der Code Guidelines erreicht. Was machen diese für einen Sinn, wenn man sich nicht daran halten muss; das ist wie eine freiwillige Geschwindigkeitsbegrenzung auf Strassen. Wenn es Lücken in den Guidelines gibt muss man diese eben im Team ansprechen und schließen. Selbst bei Projekten in sehr kleinen Teams würde ich nie ohne Guidelines arbeiten, da die Einarbeitung von neuen Teammitgliedern und Erweiterungen bzw Wartung nach zig Monaten Betrieb unökonomisch wären. Ich spreche da aus Erfahrung, da ich jetzt noch PHP Software mit seit mehr als 10Jahren in Betrieb und völlig chaotisch ist warten muss.
Wie immer in der Softwareentwicklung gilt auch hier das Mantra #1: It depends
Aber ich bin auch dafür, dass man immer ein minimum an Guidelines haben und diese auch einhalten soll.
Je grösser die Laufzeit, Komplexität und die Anzahl der Mitarbeiter ist, desto detaillierter und strenger sollten diese Guidelines sein.
Man sollte bei Guidelines bzw. der Erstellung dieser aber auch darauf achten, dass man sich nicht in Diskussionen verzettelt. Jeder Programmierer in einem Team sollte in der Lage sein Entscheidungen hinzunehmen und nach ihnen zu arbeiten, auch wenn er nicht zu 100% mit ihnen konform geht.
Sonst artet das am Ende dahingehend aus, dass man sich in jedem Teammeeting darüber unterhält, ob Variablen nun nach Schema A oder Schema B benannt werden. Und das ist dann im Endeffekt teurer, als ein Verstoß gegenüber diesen Guidelines.
(Ist jetzt nur ein etwas extremes Beispiel.)
Vorab: Restriktionen haben nichts mit dem negativen Begriff „Code-Nazi“ zu tun. Ich halte den Begriff eh für falsch und einfach unangebracht (aber das würde jetzt zu weit gehen). Allenfalls mag es „Code-Monks“ geben (in Anspielung an Mr. Monk).
Grunsätzlich sehe ich die Sache wie Tom.
Stellt euch doch einmal die Frage, weswegen ihr Empfehlungen oder Restriktionen aufstellt. Ich vermute, dass ihr glaubt, dadurch euer Ziel X zu erreichen.
Daraus folgt: Ihr glaubt, wenn ihr diese Empfehlung nicht ausgesprochen oder diese Restriktion nicht aufgestelllt hättet, dass ihr nie euer Ziel X erreichen werdet.
Andernfalls ist mit euch wahrscheinlich nur ein Jurist verloren gegangen, der Spaß daran hat, Gesetze zu entwerfen 😉
Ein konkretes Beispiel:
MiAsin brachte zuvor Java ins Spiel. Wie er glaube ich auch, dass Java u.a. deswegen im Enterprise-Segment so erfolgreich ist, weil Java einen gewissen Standard einfach erzwingt (über die Vorteile von Standards müssen wir hoffentlich nicht sprechen – wer über Restriktionen spricht, sollte wissen, weshalb überhaupt…).
In unserem Beispiel konsumiert unsere Anwendung einen XML-RPC-Dienst. Hierfür verwenden wir eine Bibliothek, welche uns den XML-RPC-Zugriff schön abstrahiert.
In PHP würden wir bspw. Zend_XmlRpc verwenden. Klappt auch alles ganz toll, unsere Anwendung ist ein Erfolg. Doch plötzlich ist der von unserer Anwendung konsumierte XML-RPC-Dienst tot. Was passiert? Wir bekommen eine Ausnahme aus Zend_HttpClient! Leider haben wir damit überhaupt nicht gerechnet. Wir reagieren zwar schön auf alle Eventualitäten die bei der Verwendung von Zend_XmlRpc direkt auftreten können, aber an Zend_HttpClient hat niemand gedacht. Weshalb auch? Wir kennen das komplette Zend Framework gar nicht – woher sollen wir wissen, dass Zend_XmlRpc denn auch Zend_HttpClient verwendet. Ja gut, der Konstruktor kann eine Zend_HttpClient-Instanz als Parameter verwenden, aber der ist optional. Da wir also keinen HttpClient übergeben, interessieren wir uns dafür also nicht weiter.
Ein wie ich finde typischer Fall. Uns hat niemand gesagt, dass eine Zend_HttpClient-Ausnahme bei der Verwendung von Zend_XmlRpc durchschlagen kann. Eigentlich sollte Zend_XmlRpc nach meinem Architektur-Geschmack fremde Ausnahmen auch abfangen, um soetwas gleich zu verhindern. In dem Falle betrachtet Zend die Klasse Zend_HttpClient aber wohl nicht als „fremd“ und sieht dazu keinen Grund.
Anders in Java:
Hier müsste die XML-RPC-Klasse die Ausnahme, die die HttpClient-Klasse werfen kann, fangen oder dem Verwender mitteilen, dass es diese Ausnahme weiterreicht. Ansonsten baut Java nicht.
Für mich als Nutzer der Klasse liegt der Vorteil auf der Hand: Mir ist sofort bekannt, was ich zu erwarten habe und auch was meine Aufgabe ist (nämlich auf die möglicherweise weitergereichte Ausnahme des HttpClients zu reagieren).
Um auf den Anfang zurück zukommen: Den Entwicklern von Java war es offensichtlich wichtig, dass das Verhalten einer Klasse klar dokumentiert wird. Der Compiler stellt dies sicher.
Noch ein Beispiel aus dem Leben, Verkehr hatten wir ja schon:
Eine rote Ampel bedeutet, dass ich dort stehen bleiben muss. Ein anderer Verkehrsteilnehmer verlässt sich darauf, wenn dieser bei grün meine Spur kreuzt.
Da dies nicht erzwungen wird – sprich ich kann trotz roter Ampel in die Kreuzung hereinfahren – passieren leider häufig Unfälle.
Anders bei der Bahn: Heutige moderne Signalanlagen haben technische Systeme die dafür Sorgen, dass ein Zug, wenn er denn ein rotes Signal überfahren hat, sofort eine Notbremsung einleitet. Nur dadurch kann das eigentlichen Ziel (Die Strecke X muss frei bleiben, da dort nun Zug Y aus der entgegen gesetzten Richtung fahren soll) verlässlich erreicht werden.
Das führt mich zu meinem Fazit:
Wenn ich etwas habe, was ich als Restriktionen bezeichne, deren Einhaltung aber nicht sicherstelle, dann sind die Restriktionen überflüssig.
Wenn ich also wie in Manuels Beispiel mir erhofft hatte, durch die Vorgabe „Jedes Interface muss mit einem I beginnen“, dass jeder im Team gleich erkennt, welche Klasse gar keine Klasse sondern ein Interface ist, dies aber nicht erzwinge, darf ich mich anschließend nicht wundern, wenn ich dieses Ziel nicht erreicht habe und sich alle im Team darüber aufregen, ständig die Falsche Datei ect. zu öffnen (ganz abgesehen vom Kunden, der glaubte, sich auf die Restriktionen verlassen zu können und erst noch bitter merken wird, dass seine Vorstellung von Restriktionen (die bei ihm Anforderung sein können) scheinbar ganz andere sind…)
Ich hab die bisgerigen Comments nur überflogen, deshalb kommt das vielleicht doppelt. Aber einfach so reingeworfen:
Code is art.
Restriktionen sind der richtige Weg!
Code Guidelines sind dafür da damit man den Kram wartbar halten kann, und meistens verhindern sie auch richtige Schwachsinnsformatierungen.
Wenn Leute sich dadurch eingeengt fühlen dann sind die Guidelines nicht richtig vermittelt worden. Das gilt aber eigentlich für jede Regelung die man in einem Unternehmen oder sonstiger Gruppe aufstellt. Stichwort „richtig kommunizieren“
Solche Regeln sollen allen die ihnen unterworfen sind das Leben bzw den Alltag einfacher machen auch wenn es den einzelnen mal mehr mal weniger einschränkt.
Wenn man sich als Chef/Teamleiter/Vorbeter/Papst aber halt hinstellt und wie letztgenannter absolutistisch die Regeln als sinnvoll damit erklärt, dass man sie halt höchstpersönlich ausgesprochen hat und es Wahrheit ist weil alles wahr und gut ist was man höchstmajestätisch von sich gibt, dann hat der vernünftige aufgeklärte Mensch wenig Anlass dem Glauben zu schenken und sofern nicht drastische Sanktionen drohen auch wenig Anlass sich daran zu halten.
Wenn aber zu jeder Regel eine Erklärung folgt, warum es damit gut und besser wird bzw warum es ohne die Regel schlechter wird/ist, dann folgt eben jener vernünftige Mensch meistens gerne der Regel.
Manchmal ist die Begründung auch nur: „Weil es einen Standart geben muss und auf diesen hier haben wir uns halt geeinigt und nun ist er ja auch schon überall, also wenn wir den ändern müssen wir alles anpassen; da muss die Änderung, die Du einbringen willst, schon einiges gutes bringen damit das gerechtfertigt ist.“ Aber auch die lässt sich gut verstehen (finde ich).
Den besten Ansatz hab ich von einem Ex-Chef, der wußte zu jeder Regel immer zu bennen, wen man damit verletzt wenn man sie mißachtet. Und wenn es beim nicht-ausgeschalteten Monitor nur die Natur (und ganz gering die Stromrechnung der Firma war), aber es kam einem nichts willkürlich vor.
Wir alle akzeptieren doch jeden Tag hunderte von Regeln die uns auferlegt sind durch Gesetzesbücher, zumind die meisten davon akzeptieren wir wohlwollend. Wer wünscht sich schon das StGB wäre auf 10 Gebote reduziert? Oder abgeschafft?
Und andererseits, je genauer und ausführlicher Regeln definiert sind, um so einfacher ist es zu tun was erwartet und benötigt wird. Um so weniger muss man immer wieder fragen wie herum man es nun machen soll, gerade wenn man irgendwo neu ist. Gerade in der letztgenannten Situation ist das oftmals gerade sehr angenehm wenn man auf ein wohldefiniertes Regelwerk stößt.
Codingstandards sind nichts anderes als Betriebsstandards, die es schon seit Ewigkeiten gibt. Und die müssen kontrolliert werden. Optimal mit PHP_CodeSniffer, was jedoch bei einer Einführung bzw. Umstellung der Codingstandards nur begrenzt oder garnicht geht, weil man vor jeder kleinen Änderung am alten Code erstmal die ganze Datei umformatieren muss. Reviewing sollte aber auf jeden Fall stattfinden. Damit können dann auch Regeln geprüft werden, die die Architektur betreffen.
Das Insel-Argument von MiAsin kann ich so nicht vertreten. Sicher ist das in der Praxis oft so, aber weil Entwickler von der Insel in die Großstadt wechseln und umgekehrt – oder die Software von der Großstadt auf die Insel ausgesourced wird – sollten die sich Regeln nicht nach der Menge der Entwickler oder nach den Überzeugungen einzelner Softwarearchitekten richten.
Gute Grundlage für innerbetriebliche Standards sind meine ich das Framework, das vorrangig verwendet wird und Best Practice, die sich aus vielen öffentlichen Projekten ermitteln lässt.
Und ein bisschen eigen(willig)er Stil schadet nicht. Ich seh ganz gerne auf ohne Diff, wer in einer Klasse wo zuletzt gearbeitet hat 😉