Beim Programmieren ist es wichtig, dass man den Dingen ordentliche Namen gibt. Seien es Klassen, Funktionen oder Variablen. Am besten ist es, wenn man die Namen so wählt, dass man sofort sieht, wozu die Funktion, Klasse oder die Variable gut ist bzw. bei Funktionen was sie machen. Das hilft anderen sehr dabei, den Code zu verstehen.
Sehr ähnliche Namen sollten vermieden werden. So lassen sich beispielsweise iValue und i_Value kaum auseinander halten. Das wird über kurz oder lang sicher zu Problemen führen. Bewährt hat es sich auch, bei Variablen den Typ voranzustellen. So sind die Variablen aus dem obigen Beispiel Integervariablen.
An eine sinnvolle Benennung sollte man sich aber nicht nur bei der Programmierung halten. Auch die Ebenen in Photoshop, InDesign oder Illustrator sollte man immer so benennen, dass man auch in mehreren Wochen noch weiß, was in den Ebenen enthalten ist. Dabei kann auch eine sinnvolle Gruppierung der Ebenen helfen.
Bei der Definition von Elementen einer Webseite sollte man vermeiden, Teile der Seite mit Top, Left oder Bottom zu bezeichnen. Das führt dann unter Umständen dazu, dass ein Menü, welches bisher unter der Bezeichnung Left auch auf der linken Seite positioniert war nach einem Umbau der Webseite auf ein horizontales Menü unter der Bezeichnung Left auf der Webseite zu Oberst angezeigt wird. Besser ist es Bezeichnungen wie navigation zu verwenden.
Sprechende, aussagekräftige Namen sind sehr wichtig. Schon einige Wochen nach der Fertigstellung kann man sich an die Programmierung nicht mehr richtig erinnern und dann ist es umso wichtiger schnell zu erkennen, was eine Funktion macht, welche Werte eine Variable aufnimmt oder mit welcher Ebene welche Einstellungen vorgenommen wurden. Daran sollte man sich immer halten, sei das Projekt auch noch so klein. Übrigens hilf es auch dabei Dateien wieder zu finden, wenn man sie in einer logisch benannten Ordnerstruktur ablegt und auch die Dateinamen gut wählt.
Hillbilly kann man wohl ganz gut mit Landei oder Hinterwäldler übersetzen. Was allerdings dazu geführt hat, dass er als initialer Wert für eine Variable Einzug gefunden hat ist nicht ganz klar, hat aber ein Schmunzeln bei mir ausgelöst.
Gestern habe ich einige liegengebliebene Artikel auf einer Webseite eingefügt. Diese Webseite wird mit joomla! 2.5.* betrieben und zeiget an, dass es ein Update geben würde. Als ich mir angesehen habe, welche Neuerungen enthalten sind ist mir erst wieder so richtig bewusst geworden, dass am 31.12.2014 der LTS (Long Time Support) für joomla! 2.5.* ausläuft. Das heißt, mir stehen in den nächsten Wochen einige Umstellungsarbeiten bevor. Aktuell betreue ich 14 Webseiten mit mehr oder weniger Pflegeaufwand. Fünf dieser 14 Webseiten werden noch von einem jommla! 2.5.* angetrieben.
Auf einer läuft der Adventskalender und auf Grund der bevorstehenden Umstellung habe ich mich gestern mal rangemacht, die Komponente auf joomla 3.3.* umzusetzen. Und natürlich hat es nicht so einfach geklappt und ich muss noch einiges anpassen. Wenn ich es geschafft habe gibt es an dieser Stelle eine Beschreibung mit den durchzuführenden Änderungen.
Viele Wege führen nach Rom – wer kennt dieses Sprichwort nicht. Und natürlich gibt es auch in der Informatik viele Wege ein Problem zu lösen. Aber man sollte sich bei der Umsetzung schon an anerkannte Standards und Verfahren halten.
Dabei helfen zum Beispiel die Entwurfsmuster oder auch Design Patterns von Erich Gamma (http://de.wikipedia.org/wiki/Entwurfsmuster). Dann gibt es Grundsätze, die jeder kennen sollte. Und um einen solchen Grundsatz soll es hier genauer gehen. Aktuell haben wir hier Werkstudenten, die ein Werkzeug zur grafischen Anzeige von Messwerten programmieren. Dieses liest eine Vielzahl von in der Datenbank gespeicherten Messwerten aus einer Datenbank und stellt sie grafisch aufbereitet dar. Um die Laufzeit zu optimieren, werden zunächst nur so viele Reihen gelesen, wie in der Oberfläche auf einer Tabellenseite angezeigt werden können. Unter der Tabelle gab es eine Schaltfläche mit der die nächsten 100/500 oder 1000 Reihen gelesen werden können. Bei einem ersten Test klicke ich darauf und wundere mich, dass ich nicht 500 mehr Reihen sehe sondern nur 13. Auf Nachfrage erfahre ich, dass die nächsten 500 Reihen aus der Datenbank gelesen werden und die gelesenen Daten dann nach den Messwerten gefiltert werden, die betrachtet werden sollen. Und diese kamen in den 500 gelesenen Reihen eben nur 13-mal vor.
Das verstößt gegen einen wichtigen Grundsatz bei der Arbeit mit Datenbanken: „Lese immer nur die Daten, die Du brauchst – filtere die Daten nicht im Nachhinein“. Darauf angesprochen stoße ich zunächst auf Unverständnis er sagt aber, dass er es ändere. Als er mir die neue Version zeigt klicke ich auf den Button und ich habe 523 mehr Reihen. Auf meine Nachfrage sagt er, dass er jetzt so lange alle Reihen einliest, bis er die gewünschte Messwertanzahl erreicht. Leider ist eine Punktlandung nicht möglich. Das kann doch nicht sein denke ich und weise ihn noch mal auf den Grundsatz hin. Er behauptet steif und fest seine Lösung sei performanter. Wir stellen dann allerdings fest, dass in der Datenbank ein Index fehlt. Nach dem Anlegen werden die Abfragen, die die Daten gleich filtern schnell ausgeführt. Aber er beharrt immer noch auf deinem Standpunkt, seine Lösung sei die bessere. Also versuche ich es ihm so klar zu machen: Ein Lagerarbeiter bringt auch nicht erstmal alle Schrauben an den Tresen um dann die auszusortieren, die er Kunde gar nicht haben wollte. Nein, er holt nur die, die er tatsächlich braucht.
Neben dem hier genauer betrachten Grundsatz gibt es noch zahlreiche weitere. Die sollte man kennen und in der praktischen Arbeit auch anwenden.
Zum Teil 4: Mit System
Zum Teil 6: Nenne es beim Namen
Es kommt immer wieder vor, dass ein Stück Software nicht so funktioniert wie es soll. Dann muss man auf Fehlersuche gehen. Manchmal ist schnell klar, was das Problem auslöst. Ein anderes Mal ist es nicht so einfach. In den Fällen, wo sich die eigentliche Fehlerursache nicht gleich erschließt, ist es wichtig, dass man den Fehler systematisch eingrenzt.
Als völlig unbrauchbarer Ansatz hat es sich erwiesen, ins Blaue hinein Änderungen am Code vorzunehmen. Das führt in den seltensten Fällen zum Erfolg und wenn, ist oft nicht klar warum.
Also sollte man im ersten Schritt versuchen, durch debuggen oder Testausgaben die Stelle an der der Fehler auftritt einzugrenzen. Wenn man so den Codebereich, in dem der Fehler auftritt, ausfindig gemacht hat und man ihn sogar nachvollziehen kann versucht man im zweiten Schritt zu verstehen, was schief läuft um dann durch geeignete Maßnahmen den Fehler zu beseitigen.
Neben der systematischen Fehlersuche gibt es einen weiteren Bereich bei dem man mit System vorgehen sollte. Es hat sich als Vorteilhaft erwiesen, wenn man ein großes Problem, welches zunächst unlösbar erscheint, systematisch in kleine, lösbare Aufgaben aufteilt. Irgendwann hat man dann durch systematisches Lösen der Teilaufgaben die große Aufgabe umgesetzt.
Mit einem systematischen, geplanten Vorgehen, erreicht man also die Ziele schneller.