Artikelformat

Denn sie wissen nicht was sie tun

Neulich habe ich ja schon das Buch „The Art of readable Code“ empfohlen. Nun habe ich einen weiteres schlechtes Beispiel zu bieten das vielleicht nicht passiert wäre wenn…

Ich darf jetzt in der Arbeit ein Linux-Anwendungsprogramm pflegen dessen bisherige Maintainer dank einer Entlassungswelle nicht mehr in der Firma sind. „The knowledge has left the company“ wie es so schön heißt. Und die letzten Tage hatte ich dann die Gelegenheit, mal in den Sourcecode zu schauen. Es war schaurig.

Der Sourcecode liegt nämlich auf einem Team Foundation Server, einer agilen Entwicklungsumgebung für Visual Studio von Microsoft. Das war erst mal ein Problem, denn als Linux-Nutzer habe ich natürlich keine Windows-Plattform um damit was zu machen. Zum „Glück“ gibt es ein Eclipse-Plugin welche einem auch von Linux aus den Zugriff auf die Sourcen erlaubt. Also habe ich mir das mal auf den lokalen PC geholt.

Das Ding ist hauptsächlich in C++ geschrieben. Ein simples Zeilenzählen in allen Quelldateien bringt es dann auch auf knapp 300.000 Codezeilen, also eigentlich ein ganz dicker Brocken. Da hofft man dann doch auf eine entsprechend umfangreiche Dokumentation.

Begleitende Dokumentation gibt es aber nicht viel, bis jetzt habe ich 2 Dateien mit insgesamt 36 Seiten ausgegraben, die mehr beschreiben, wie man den Quellcode übersetzt und die RPM-Pakete installiert.

Die Inline-Doku im Quellcode ist wieder maximal dürftig. Das Ding ist seit dem Jahr 2000 gewachsen und der Hauptprogrammierer hat es zwar geschafft, vor jede Funktion seinen Namen reinzuschreiben und das Datum wann er das verbrochen hat, aber das war es dann auch schon im Großen und Ganzen. Keinerlei Dokumentation über die Struktur, die verwendeten APIs und was man sonst halt noch so brauchen würde um den Code zu verstehen.

Das Übersetzen geht auch nicht wie unter unixoiden Systemen üblich mit „configure – make – install“ sondern man hat ein Shellskript geschrieben welches das erledigt. Ein Blick ins Script lässt einen dann schnell ahnen, dass der Programmierer aus der DOS/Windows-Ecke kommt und seine Tools nicht kennt. So finden wir definierte Funktionen wie dos2unix die man in vielen Distributionen auch schon als Pakete ausliefert. Hier kann ich vielleicht noch vestehen, dass man das so definiert weil man nicht sicher sein kann, dass dieses Tool auf der Zielplattform installiert ist, aber als ich dann sah, wie man Ausgaben in Logfiles leitet fiel ich komplett vom Glauben ab:

Jeder Shell-Skripter der sein Handwerkszeug kennt macht das so:

Das erspart das doppelte Bereitstellen des auszugebenden Textes und ist einfach „state of the art“.

Als ich dann heute nachmittag eines dieser Installationsskripte starten wollte kam die nächste Ernüchterung. Das was das Eclipse-Plugin da aus dem Team Foundation Server extrahiert hat ist ein Dateibaum dessen Dateien alle „read-only“ sind. Innerhalb von Eclipse kann ich die Dateien trotzdem ändern und Eclipse merkt dann auch, dass sich was geändert hat und bietet an, das auf den Server zurückzuspielen.

Aber ausführbare Dateien unter unixoiden Systemen brauchen das „x“-Bit in den Rechten und das fehlt flächendeckend. Bei so was bekommt man einfach Bauchweh und wünscht sich, dass man die Sourceverwaltung halt nicht in so einem microsoft-spezifischen Tool hat sondern in dem was in der OpenSource-Welt „state of the art“ ist. Aber klar, wenn der ursprüngliche Programmierer bislang nur für Windows programmiert hat wird er diese Denkmuster weiter haben wenn er was für Linux programmieren soll.

Ok, das mit den x-Bits ist keine Katastrophe, mache ich halt einen baumweiten grep auf das Dashbang-Muster und markiere die gefundenen Dateien als ausführbar. Und dann werde ich sehen, welche weiteren Überraschungen dieser Code für mich bereit hält.

Im Zweifelsfall bleibt immer noch die Flucht in die Klapsmühle.. 🙂

P.S.: Nicht dass jetzt ein falscher Eindruck ensteht, die Microsoft-Toolchain und der TFS sind sicher ein mächtiges Werkzeug für die Programmentwicklung für Windows. Aber Linux-Applikationen darauf entwickeln zu wollen ist ungefähr so wie wenn ich eine Schraube mit dem Hammer in ein Brett „schrauben“ will.

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5,00 von 5)

Loading...

Autor: Rainer

Diplom-Informatiker, Baujahr 1961, Vater von 2 Kindern, Hundehalter, Sportschütze und Vereinsvorstand, Hobbymusiker (mit zweifelhaftem Erfolg), politisch interessiert, Leseratte, Freizeit-Philosoph und letztlich Blogger.

Kommentare sind geschlossen.