Softwareentwicklung im Team – Teil 5 – Namensgebung

Während ich mich im letzten Artikel ein wenig über das Thema Dokumentation ausgelassen habe, geht es in diesem Artikel kurz um die Namensgebung von Package- und Verzeichnisnamen.

4. Problem / Beispiel
Package- und Verzeichnis-Namen
Die Wahl des Package-Namen scheint manchmal etwas unüberlegt zu sein. So befindet sich das Package “de.abc.xyz.administration.util” in ZWEI(!) Projekten (XyzUtilities und XyzAdministration). In XyzUtilities befinden sich darüber hinaus noch “de.abc.xyz.utilities” und “de.abc.utils”. Das ist unnötig verwirrend.
Im JSP-Ordner hingegen wurden anfangs fast keine Unterordner angelegt. Hier wäre ein klein wenig mehr Struktur durchaus wünschenswert, so dass jedes “Modul” einen eigenen Unterordner erhält.
Und Ordner mit dem Namen “Backup” sollten sich auch nicht im Projekt finden. Leider scheint dieser Ordner wirklich das zu sein, was er vorgibt zu sein. Ein Backup alter Daten. Dafür haben wir das SVN, in dem auch ein Tag für diese Zwecke erstellt werden kann!

Lösungsvorschlag
Da sich ein Refactoring schwierig gestaltet, auf Grund der Spring-XML-Konfiguration, ist ein größeres Refactoring bei den (hoffentlich) bald endenden Projekten nicht gerade sinnvoll. Für neue Funktionalitäten respektive bei neuen Projekten sollte jeder ein wenig mehr Achtung walten lassen, bzw. ein Refactoring durchführen, soweit das Projekt nicht in der Endphase ist.

Vorteile
– Man findet sich leichter im Projekt zurecht und muss nicht ständig die interne Suchfunktion bemühen

Nachteile / Probleme
– hm… es muss gemacht werden!?

Aufwand
– zu vernachlässigen

Rückblickend gesehen…
Das Projekt, auf welches ich mich beim Schreiben des ursprünglichen Textes bezog, war eine relativ umfangreiche Web-Applikation. Für die, die nicht wissen, was JSPs sind, können sich ja kurz den Wikipedia-Eintrag (http://de.wikipedia.org/wiki/JavaServer_Pages) durchlesen.
Bei uns lagen fast alle JSPs (~ 100 an der Zahl) in einem(!) Verzeichnis. Bis man da die richtige Datei gefunden hatte, dauert es teilweise etwas. Erschwerend kam hinzu, dass unsere Namensgebung nicht konsistent war, und für gleiche Operationen unterschiedliche Präfixe verwendet wurden, z.B. change*, edit* und modify* zum Ändern von Datensätzen, show* und list* zum Anzeigen von Datensätzen und add*, enter*, create* und new* zum Erzeugen von Datensätzen. Ab und an wurden auch Suffixe anstatt von Präfixen oder auch mal keins von beiden verwendet.
Natürlich wäre eine konsistente Namensgebung bei den Dateinamen wünschenswert gewesen, um einen schnelleren Zugriff auf die Dateien bei der Entwicklung zu gewährleisten. Allerdings hätte das Problem schon eingedämmt werden können, indem logisch zusammenhängende Dateien (zum Beispiel sämtliche JSPs die mit Vertragsdaten zu tun haben) in einem Ordner abgelegt hätte.

Das Problem, dass wir Helferklassen in zwei Projekten (die logisch zusammengehörten) auf vier Packages verteilt haben, ist mir bis heute unverständlich. Da wurde Funktionalität teilweise zwei Mal entwickelt, weil man davon ausging, dass diese noch nicht existiert. Dabei hatte man nur eins der Packages übersehen.

Zusammenfassung
Dass das Thema Namensgebung sich nicht nur auf Ordner- und Package-Namen bezieht, sondern auch auf Klassen-, Methoden-, Variablen- und Konstanten-Namen, ist dem geneigtem Leser hoffentlich bewußt.
Die Struktur eines Projektes ist insbesondere am Anfang noch relativ volatil. Wenn also auffällt, dass die Struktur verbessert werden kann oder die Namensgebung nicht konsistent ist, sollte man sich die Zeit nehmen, um ein Refactoring vorzunehmen. Befindet sich das Projekt allerdings schon in der Endphase, sollte sorgfältig abgewägt werden, ob sich der Aufwand überhaupt lohnt. Wenn der Abgabetermin bereits in zwei Wochen fällig ist, wird ein aufwendiges Refactoring dem Kunden schwer vermittelbar sein. In einem solchen Fall wäre es sicherlich sinnvoller, das Refactoring auf einen Termin zu verschieben, der nach dem Abgabedatum liegt (unter der Voraussetzung natürlich, dass das Produkt nach dem Abgabetermin weiter entwickelt wird).
Einen weiteren Punkt, der bereits im letzten Artikel angeklungen ist: die Wahl der Sprache. Machen Sie sich auch hierüber nochmal Gedanken. In welcher Sprache sollen Variablen, etc. benannt werden? Wie wollen Sie mit domänenspezifischen Begriffen umgehen? Wenn Sie beispielsweise eine Applikation für ein Krankenhaus entwickeln und sich dafür entschieden haben, grundsätzlich in der englischen Sprachwelt zu bleiben, wie gehen Sie mit Wörtern um, die nicht zum Grundwortschatz gehören? Zum Beispiel das Wort “Krankenversicherung”. Dies könnte mit “health insurance”, “medical insurance”, “sick insurance” oder “sickness fund” übersetzt werden. Ein Mischmasch an Übersetzungen sollte vermieden werden. Hier haben Sie zwei Möglichkeiten. Entweder Sie erstellen ein “Wörterbuch”, in welchem domänenspezifische Begriffe und deren zu verwendente Übersetzung aufgeführt werden oder sie erlauben für diese Begriffe die deutsche Verwendung. Auch wenn ein Sprachenmix auf den ersten Blick abschreckend aussieht (z.B. EditKrankenkasse.java), so hat sich dieses Ansatz sich dennoch bei uns bewährt. Letztendlich ist es egal, welchen Ansatz Sie wählen, solange dieser konsistent ist.

Um es auf den Punkt zu bringen: denken Sie lieber 2 Minuten länger nach, bevor Sie einen Namen vergeben, als Wochen später in stundenlangen Refactoring-Sessions Ihren Code im nachhinein auf Vordermann zu bringen.

Ausblick
Im nächsten Artikel geht es um das Thema “Nightly Builds“.

2 Gedanken zu „Softwareentwicklung im Team – Teil 5 – Namensgebung“

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>