Wie man Projekte im Team nachvollziehbar strukturiert

Symfony-Projekt mit Struktur
Kommentare

Das Symfony Framework, aktuell Symfony2, mag ja unbestritten seine Vorteile haben, aber in der Dokumentation werden Regeln für die Nachvollziehbarkeit des Codes wenig bis gar nicht angepeilt. Was ich damit sagen will, ist, Symfony2 hält Entwickler nicht per se dazu an, sich an gewisse Regeln zu halten, so dass gerade wenn ein Projekt im Team gestemmt wird, der eine Entwickler einfach in den Code eines anderen springen kann und direkt nachvollziehen kann, was gemacht wurde.

Ergo: Man muss sich die Regeln selber machen und dann auch einhalten. Denn aus Fehlern lernen oder Learning by Doing mag nachhaltig sein, aber es kostet einfach zu viel Zeit und somit auch Geld.

Doch wie soll man das Regelwerk erstellen, auf welcher Basis? Man könnte zum Beispiel schauen, wie es andere gemacht haben und deren Vorgehen an das eigene Projekt anpassen. Paweł Barański hat beschrieben, wie in seinem Unternehmen ein Bundle strukturiert wurde.

  1. Die Anzahl der Directories ist begrenzt.
  2. Das First-Level-Directory ist generisch.
  3. Falls nicht schon in der Directory-Beschreibung spezifiziert, muss die Klassen-Definition in einem Folder platziert werden. Dieser muss die Struktur der Symfony- oder Folder-Struktur der entsprechenden Komponente wiedergeben, die mit der Klasse verbunden ist. Der Main Folder der Klasse muss dem Namen der Komponente entsprechen.

Als Grundlage diente ein Basic Bundle, generiert über den Task generate:bundle. Daraus ergeben sich dann diverse Folder, wie /Command für Symfony Tasks oder /Event für Event-Klassen, die dann wiederum in Directories platziert werden sollten, die ihre Implementierung beinhalten.

Für Doctrine gelten wesentliche Grundsätze wie etwa die Regel „‘flush‘ nur vom Controller oder den Commands “ oder „Tabellen-Namen werdem im Plural und klein geschrieben, Wörter werden mit Underscores getrennt.“ In Sachen Twig gilt etwa, dass alle das gleiche Tag verwenden müssen. Bei den Services und Parametern müssen sowohl der Vendor als auch der Name des Bundle benutzt werden. Damit Services und Parameter leichter zugeordnet werden können, sollen die Service Argumente und Methods Calls einer nach dem anderen in service.yml gelistet werden, dabei gilt es zu entscheiden, ob man Single-line oder Multi-line Calls macht.

Die ausführliche Beschreibung könnt ihr euch auf der Website anschauen.

Unterm Strich, sagt Barański, habe das Regelwerk dazu geführt, dass sich die Fragen danach, was man wo platzieren soll reduziert haben und es ein Leichteres ist, neue Teammitglieder in den Prozess einzuführen. Eine zusätzlich integrierte Code Review macht es möglich, sofort festzustellen, wenn die Regeln gebrochen werden.

 

Aufmacherbild: Hand writing Know The Rules von Shutterstock / Urheberrecht:Ivelin Radkov

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -