Developers Shame Day
Heute ist der von Cem eingeleitete “Developers Shame Day”! Ich werde euch von einem Projekt berichten, das ich in meiner Ausbildung umgesetzt bzw. erweitert habe. Das ich damit angefangen habe ist nun ca. 3 Jahre her und zuletzt habe ich vor nicht einmal einem Jahr damit zu tun gehabt. Da ich die originalen Sources hier nicht veröffentlichen kann/darf, werde ich das äußerst hirnrissige Prinzip erklären das dahinter steckte.
Ich wurde damit betreut ein bestehendes Projekt zu erweitern. Zu einer bestehenden Maske sollte ich ein paar Felder hinzufügen und dafür sorgen das diese richtig gespeichert werden und der Benutzer das ganze trotzdem noch leicht und intuitiv verwenden kann. Für mich hörte sich das einfach an und ich habe nicht eine Sekunde einen Gedanken daran verschenkt mir erst den alten Code anzuschauen und zu überlegen, ob es überhaupt sinnvoll ist das Programm zu erweitern.
Eines der Konstrukte in dem Code die mir direkt negativ aufgefallen sind, war die Art und Weise wie die Masken geöffnet, geleert, gefüllt und gespeichert werden. Das komplette Programm benutzt AJAX für das laden und speichern der Masken. Naja. Für das Laden und Speichern der Daten der Masken. Klicke ich auf einen Termin um ihn zu öffnen, wird ein AJAX Request an eine PHP Datei geschickt. Diese ruft die Daten aus einer MSSQL Datenbank ab und speichert diese in ein Array.
array(2) {
[0]=>
array(3) {
['id']=>
int 1
['vorname']=>
string(4) "Dave"
['nachname']=>
string(6) "FooBar"
}
}
Diese Daten werden dann nicht etwa in JSON gewandelt oder ähnliches. Sie wurden teilweise einfach so wie sie waren zurückgesendet. Teilweise ging das wohl schief, dann ist man einfach hingegangen und hat vor dem absenden der Daten folgendes gemacht:
implode(";;",$array);
Leider wurde das nicht immer gemacht, deshalb sorgte das schnell für Verwirrung.
Die Daten wurden dann vom Javascript in Empfang genommen und dort ggf. wieder in ein Array umgewandelt. Dann wurden die einzelnen Felder der Maske über ein einfaches getElementById ermittelt und befüllt. Und vielleicht ist euch gerade noch etwas aufgefallen. Ja. Jedes einzelne Feld hatte eine ID. Und einen Namen. Diese waren identisch.
Das speichern der Daten verlief genauso. Nur andersrum.
Aber nun bin ich ins Spiel gekommen. Anstatt direkt zu sagen “Hey, das sieht scheiße aus, das müssen wir neu machen!” habe ich mich hingesetzt und diesen großen Ball of Mud noch ein bisschen größer gemacht. Viel größer.
Aus den “paar” Felder die hinzugefügt werden sollten wurden im Nachhinein > 50. So wuchs die Zahl der Felder der Maske von vorher ca. 100, auf ca. 170 Felder an. Leider sind später immer wieder kleine Fehler aufgetreten die mir das Leben schwer gemacht haben und die ich durch eine andere Vorgehensweise hätte vermeiden können. Im IE6 hatte ich z.B. das Problem, das die URL durch die ganzen GET Parameter bzw. den einen langen GET Parameter, zu lang wurde und nicht mehr korrekt aufrufbar war. Es wurden einfach Daten abgeschnitten. Andererseits war das komplette Programm im IE so langsam, das man es auf einer normalen Büro Maschine gar nicht verwenden konnte. >30 Sekunden auf eine Reaktion des Programms warten ist dann doch ziemlich happig…
Die Maske selbst war durch eine Tabnavigation in 9-10 Unterbereiche unterteilt, die je nach Terminart nicht einmal verwendet wurden. So kam es vor, das man bei einer Terminart nur 4 Tabs benutzen konnte. Trotzdem wurden alle Felder geleert und durch nichts gefüllt. Sehr performant.
Im Nachhinein hätte ich die Daten gar nicht erst separat übergeben, sondern mir die Maske besser im PHP zusammengebaut und dann komplett über Javascript übergeben. Bei 170 Felder oder mehr ist das sicherlich die schnellste und eleganteste Methode. Aber als ich das dann auch mal gemerkt hab, war es auch schon zu spät…
