Quellcode Bäume: weit oder tief

Question

Nach dem Schreiben ein paar Python Appengine-Anwendungen finde ich mich hin- und hergerissen zwischen zwei Ansätze zur Organisation meiner Quellcode-Baum: weit oder tief.

Für Konkretheit, betrachten Sie eine interne Anwendung für ein kleines Beratungsgeschäft, um Geschäftsvorgänge wie Kontaktmanagement, Projektverfolgung & Berichterstattung und Mitarbeitermanagement zu verwalten. Die Anwendung kann Schlüsselelemente wie Unternehmen, Benutzer, Kontakte, Kunden, Projekte, Arbeitszeittabellen usw. verwenden. Ohne ins Detail zu gehen, kann man sich vorstellen, dass diese Modelle die Funktionen der Website übergreifen. Dies bedeutet wahrscheinlich, dass es eine Kopplung gibt.

In diesem Beispiel ist es bevorzugt, in einem Tief Weise zu organisieren, zB:

models/ 
    people.py 
    accounting.py 
    projects.py 
    foo.py 
controllers/ 
    reporting.py 
    employeeops.py 
    accounting.py 
    crm.py 
views/ 
    ... 

oder eine weit Weise, beispielsweise durch "Anwendung":

people/ 
    models/ 
    views/ 
    controllers/ 
contact-mgmt/ 
    models/ 
    views/ 
    controllers/ 
time-tracking/ 
    models/ 
    views/ 
    controllers/ 
project-reporting/ 
    models/ 
    views/ 
    controllers/ 

Ich weiß, Jedes Design beinhaltet Trade-Offs. Wenn Sie also reagieren, können Sie Ihre Präferenz und Argumentation angeben (z. B. Annahmen, modulierende Bedenken, Rahmenbeschränkungen, Skalierbarkeitsprobleme, Überlegungen zur Codepflege, Auswirkungen der Struktur des Entwicklungsteams usw.).

Answer 1

Vorbehalt: Ich habe nicht speziell in Python gearbeitet. Nachdem das gesagt wurde ...

Breit, und ich sage dir warum: Es tut nie weh, Dinge schnell entfernen zu können. In meiner Karriere werde ich oft gebeten, Dinge hinzuzufügen und einen relativ vernünftigen Zeitplan dafür zu geben, aber wenn etwas entfernt werden muss, kommt die Bitte fast nie mit einer Wirkungsanalyse oder Zeit zum Durcheinander. Wenn Sie die wichtigsten Funktionsmodule auseinandernehmen, enden Sie normalerweise mit einem viel weniger gekoppelten Design. Es kann eine echte Nervensäge sein, aber für jene Zeiten, in denen Sie das Arbeitsauftragsmodul bis zum Ende der Woche unbedingt ausschalten müssen, ist es ein Lebensretter.

Answer 2

Zu tief eine Ordnerstruktur macht es verwirrend. Zu breit macht es verwirrend. Ich bevorzuge es, ein Gleichgewicht zwischen ihnen zu halten. An dem Projekt, an dem ich arbeite, hatten wir keine Ahnung, was wir brauchen würden, also haben wir nicht zu früh eine massive Ordnerstruktur erstellt. Schließlich haben wir nur mit 5 Dateien begonnen, also hatten wir nicht wirklich eine benötigen für eine Ordnerstruktur. Als das Projekt größer wurde, organisierten wir Dinge, um es ordentlich zu halten, als wir gingen; keine Ordner mit mehr als 10 Dateien, die Dinge eindeutig in Ordner gruppieren. Es würde ein paar Minuten dauern, um alles zu bewegen. Jetzt haben wir weit über hundert Dateien und es ist immer klar, wo die Dinge sind. Meine Empfehlung ist es, etwas Ähnliches zu tun - halte es sauber, gehe nicht zu weit mit der Tiefe oder Breite, sonst verkomplizierst du die Dinge.

Answer 3

In Ihrem Fall denke ich, das "breite" Modell ist besser. Sie sollten versuchen, Ihre Apps so zu erstellen, dass sie wiederverwendbar sind, auch wenn Sie sie nicht überall wiederverwenden möchten, da dies eine lockere Kopplung zwischen verschiedenen Apps fördert und die Wartung auf lange Sicht vereinfacht.

Answer 4

Eigentlich bevorzuge ich eine Mischung. Die Software ist in horizontale und vertikale Komponenten unterteilt.
Horizontale Komponenten sind über alle Module hinweg wiederverwendbar und stellen einen gemeinsamen Code dar, der wiederverwendet werden kann. Dieser Code ist nicht anwendungsspezifisch, sondern ist architekturspezifisch.
So habe ich Ordner für allgemeine Dienstprogramme, Frameworks, wiederverwendbare Infrastrukturbibliotheken wie Persistenz, Kommunikation, Sicherheit, Protokollierung usw.

Vertikale Komponenten sind die einzelnen Anwendungsfälle. Für jeden Anwendungsfall habe ich einen Ordner mit UI, Server und unter UI habe ich Ansichten und Controller. Das Modell wird häufig zwischen den beiden geteilt.

Wenn Ihr Projekt wirklich groß ist, haben Sie wahrscheinlich verschiedene Verantwortungsbereiche wie Bestandskontrolle, Vertrieb, Kontaktverwaltung, Berichte usw. Fügen Sie diese Ihrer Ordnerstruktur hinzu und legen Sie die Anwendungsfälle fest, die darunter gelten.

Fühlen Sie sich frei, wenn es irgendeine Wiederverwendung gibt, um irgendwelche Bestandteile in den Baum zu verschieben.