Sebastian Schmid bio photo

Sebastian Schmid

Student der angewandten Informatik an der HTW Berlin.
Interessen sind Linux, Latex und Python.

Github Stackoverflow

Erarbeiten einer Projektstruktur in Python.

Achtung! Hier wird ein etwas tiefergehendes Verständnis in der Softwareentwicklung vorausgesetzt.

Hinweis. Sollten dir Fehler auffallen, schreib mir einfach eine Mail.
Auch bei offenen Fragen freue ich mich über deine Nachricht.

Einleitung

Die Komplexität von Softwareprojekten ist ein wichtiges und großes Thema in der Informatik. Neben dem Entwickeln guter und effizienter Algorithmen ist dies wohl der Bereich, in dem die größten Fehler gemacht werden können.
Doch während sich ein schlecht optimierter Algorithmus in der Regel einfach austauschen lässt, trifft ein Fehler in der Architektur das Programm im Fundament. Nicht selten ist es dann einfacher, das gesamte Projekt neu zu beginnen, als die Komplexität, und die damit wachsende Unordnung, im laufenden zu verringern.
Häufig wird sich dann aus Kostengründen dazu entschieden, mit den gegebenen Umständen zu arbeiten, mit all den damit verbundenen Nachteilen. Dies bringt neben immensen Einarbeitungszeiten auch den Verlust an Qualität und Sicherheit.
Ich bin der Meinung, dass ein Großteil schlechter Software darauf zurückzuführen ist, dass in der Initialphase kein “gesundes” Konzept erarbeitet wurde. Ein Konzept, das Komplexität reduziert und dem Entwickler gerade die Werkzeuge an die Hand gibt, die er braucht um sein Problem auf die bestmögliche Weise zu lösen.

Aus diesen Gründen habe ich mich entschlossen, diesen Blog mit einer Serie zu beginnen, die sich mit dem Erstellen und der damit verbundenen Softwarearchitektur und Komplexitätsbewältigung eines Softwareprojektes beschäftigt.
Zwar bin auch ich nicht der große Softwarearchitekt, aber ich möchte auf diesem Wege selbst lernen, wo die Fallstricke und Problemfelder liegen. Deswegen bitte ich all diejenigen, die Anmerkungen und Fragen haben, Kontakt mit mir aufzunehmen. Auf diese Weise ist der Lerneffekt am größten. Und so können alle an diesem Projekt partizipieren.

Als Beispielobjekt habe ich mir einen automatischen Portscanner und FTP-Crawler für öffentliche Server überlegt. Datenerhebung in Netzwerken macht mit Python großen Spass und zwingt den Entwickler eine saubere und relativ große Thread-Infrastruktur einzusetzen.

Software-Design in Python

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Das Programm

Netzcrawling ohne Netz

Es hört sich etwas verrückt an, wenn man sagt man möchte einen Crawler für Onlinedienste schreiben; ohne aber die dafür so gut geeignete Infrastruktur des Internets zu verwenden, sondern auf entkoppelten Diensten wie FTP.

Um diese Hürde zu nehmen, werden für Testzwecke zuerst einige öffentliche Server von Open Source Projekten verwendet. Später könnte man überlegen, die IP-Adressen hierfür zufallsgenerieren zu lassen.
Wir sollten aber für unser Design im Auge behalten, dass hunderte Threads notwendig sein werden, die den IPv4 Raum nach öffentlichen FTP Servern absuchen.

Zum Testen sollten folgende Server ausreichen:

  1. http://ftp.debian.org/debian/dists/stable/
  2. https://www.python.org/ftp/python/
  3. http://ftp.vim.org/

Erste Überlegungen über den Grundaufbau

Bei dem Ganzen stellen sich am Anfang für mich folgende Probleme:

  • Die lose Verdrahtung der jeweiligen Module. Diese müssen einfach austauschbar und erweiterbar sein.
    Dies bedingt eine klare Einteilung in die jeweiligen Aufgabenbereiche.
  • Die Ergebnisse müssen gespeichert werden. Um Konflikte beim Schreiben der einzelnen Threads zu vermeiden sollte diese Aufgabe in einen speziellen Prozess delegiert werden, der sich nur um diese Aufgabe kümmert. Diese müssen soweit abstrahiert sein, dass man die Art und Weise des Speicherformates nach Außen versteckt, aber innerhalb einfach einstellen und auch konvertieren kann.
  • Bei der Unterbrechung des Programmablaufes muss das Speichern der Daten beendet werden.

Gedanken zur konkreten Modellierung

  1. Die Grundstruktur wird sich am Anfang in 3 Module untergliedern:
    1. ftp: Mit allen Paketen, die für Operationen mit dem FTP Protokoll nötig sind.
    2. net: Hier werden alle primitiven Netzwerkdienste ausgelagert.
    3. data: Kümmert sich um das speichern und konvertieren von Daten.
  2. Klassen werden genutzt wenn nötig, vermieden wenn möglich.
  3. Der Prozess zum Speichern wird über eine Abwandlung des Memento Pattern dargestellt.
  4. Der gesamte Prozess für den ftp-Login wird über eine factory abstrahiert; dies erhöht zwar die Komplexität, vereinfacht aber spätere Änderungen und das Threading.
  5. Loginversuche werden über einen logischen Baum von Methoden dargestellt, da nur gehandelt werden muss, wenn jeder Schritt bis dahin erfolgreich war.
  6. Daten werden intern als Dictionaries vorgehalten.

Wie geht es weiter?

Auf der nächsten Seite werden Verzeichnisstruktur, und die lose Verzahnung zwischen dem Datei-Memento und der Login-Infrastruktur gelöst.

Hinweis. Diese Seite exitsiert noch nicht. Nutze den newsfeed um nichts zu verpassen.