Projektstruktur für eine Python-Anwendung

1. Projektstruktur für eine Python-Anwendung
2. Ein Beispiel

Bei der Arbeit an realen Anwendungen kann die Größe der Codebasis drastisch ansteigen. Im Allgemeinen wird nicht empfohlen, monolithische Programme zu programmieren oder den gesamten Anwendungscode in einer einzigen Datei zu speichern. Der Grund dafür ist, dass ein monolithisches Programm mehr unerwartete Fehler verursachen kann. Mit zunehmender Programmgröße wird es unüberschaubar und unlesbar und fördert die Zusammenarbeit nicht.

Aufgrund solcher Probleme empfiehlt es sich, die Anwendung in kleinere Segmente oder Microservices aufzuteilen, die ihre vorgegebene Aufgabe unabhängig von anderen Diensten erfüllen. Ein solches Setup fördert nicht nur eine einfache und bessere Verwaltung, sondern auch Lesbarkeit und Produktivität. In diesem Artikel wird erläutert, wie wir unsere Python-Anwendungen im Allgemeinen für eine bessere Verwaltung, Lesbarkeit und Produktivität strukturieren sollten.

Projektstruktur für eine Python-Anwendung

Die Idee ist, das Programm in kleinere Komponenten oder Microservices aufzuteilen. Dies sind im Wesentlichen einige Verzeichnisse mit Python-Dateien, die nur die ihnen zugewiesene Aufgabe ausführen. Dies sind im Allgemeinen eigenständige Dateien, die von anderen Diensten unabhängig sind. Auf diese Weise ist es einfach, einen Dienst zu entfernen oder hinzuzufügen.

Beachten Sie, dass einige der genannten Verzeichnisse oder Segmente für jede Anwendung weltweit gelten können oder nicht, da einige Anwendungen unkompliziert sind und nicht viel Test und Verwaltung erfordern. Gleichzeitig sind einige ziemlich langwierig und robust und erfordern ständige Aufmerksamkeit und Verwaltung.

Diese Verzeichnisse und Dateien sollten in einem leeren übergeordneten Projektordner erstellt werden.

1. LICENSE: Diese Datei enthält rechtliche Informationen zu den Richtlinien für die Verwendung des Antrags und die Verteilungsdetails des Antrags.
2. README.md: Diese Markdown-Datei enthält eine kurze Beschreibung der Anwendung, ihrer Dateien, Richtlinien zum Einrichten und Ausführen der Anwendung, Richtlinien für Beiträge, wenn die Anwendung Open Source ist usw.
3. setup.py oder run.py: Diese Datei ist der Einstiegspunkt für jede Python-Anwendung. Dies bedeutet, dass wir immer dann, wenn wir eine Python-Anwendung mit einer ähnlichen Projektstruktur ausführen möchten, diese Datei einfach ausführen müssen.
4. env oder environment: Dies ist die virtuelle Python-Umgebung der Anwendung.
5. requirements.txt: Diese Textdatei enthält Informationen über die Abhängigkeiten der Python-Anwendung.
6. /<sub-application>: Dieser Ordner enthält eine eigenständige Sub-Applikation oder einen Microservice. Diese Ordner sollten eine __init__.py haben, was sie zu Python-Modulen macht. Wir finden solche Ordner in Django- und Flask-Anwendungen in Form von Anwendungen bzw. Blaupausen. Beachten Sie, dass diese Minianwendungen oder Microservices unabhängig von anderen Anwendungen dieser Art sind und daher ihre eigenen Ordner /tests, /static, /templates und models.py und forms.py haben können.
7. /docs: Dieser Ordner enthält die Dokumentation der Python-Anwendung. Von der Dokumentation wird im Allgemeinen erwartet, dass sie robust und umfassend ist, damit der Endbenutzer die Anwendung problemlos verstehen kann.
8. /tests: Dieser Ordner enthält alle Tests für die Anwendung. Da das Testen ein wesentlicher Schritt ist, bevor eine Anwendung in die Produktion überführt wird, sollte sie über ein eigenes Verzeichnis verfügen. Die Anzahl der Tests kann drastisch steigen, wenn die Anwendung oder die Funktionen wachsen.
9. /static: Dieser Ordner enthält alle statischen Dateien der Anwendung, wie Bilder, Videos, Logos und Icons. Handelt es sich bei dem Projekt um eine Webanwendung, enthält der Ordner static auch CSS- und JavaScript-Dateien. Sie finden diesen Ordner in Django- und Flask-Anwendungen.
10. /templates: Dieser Ordner enthält alle HTML-Vorlagen, die von der Python-Anwendung verwendet werden. Im Allgemeinen ist dieser Ordner für Python-Webanwendungen relevant, da das Web HTML erfordert. Auch diesen Ordner finden wir in Django- und Flask-Anwendungen.
11. models.py: Diese Datei enthält den Python-Code für Datenbankmodelle. Python-Klassen, die Datenbankmodelle darstellen, werden in dieser Datei definiert, wenn ein ORM oder eine objektrelationale Zuordnung verwendet wird.
12. database.db: Diese Datei ist die Datenbank, die die Python-Anwendung verwendet. Diese Datei wird nur benötigt oder erstellt, wenn die Anwendung eine einfache dateibasierte Datenbank wie SQLite3 verwendet.

Ein Beispiel

Angenommen, wir arbeiten an einer webbasierten persönlichen Blogging-Website. Dann sieht die Projektstruktur einer solchen Anwendung in etwa so aus.

blog/
|-- LISCENSE
|-- README.md
|-- run.py
|-- models.py
|-- database.d
|-- environment/
    |-- * files *
|-- requirements.txt
|-- users/
    |-- __init__.py
    |-- forms.py
    |-- routes.py
    |-- * files *
|-- blogs/
    |-- __init__.py
    |-- forms.py
    |-- routes.py
    |-- * files *
|-- docs/
    |-- * files *
|-- tests/
	|--	users/
    	|-- * files *
    |-- blogs
	    |-- * files *
|-- static/
    |-- users
	    |-- * files *
    |-- blogs
	    |-- * files *
|-- templates/
    |-- users
	    |-- * files *
    |-- blogs
	    |-- * files *