- März, 2008
-
Softwareprojekte Episode 3 ::: Refactoring kann helfen
Diese Geschichte über Softwareprojekte startete mit der Vohref="http://miradlo.net/bloggt/index.php?69-s"">Vorgeschichte, Episode 1, und Episode 2, in diesem Teil geht es darum, dass Refactoring gegen die bisherigen Schref="http://miradlo.net/bloggt/index.php?70-s"">Episode 1, und Episode 2, in diesem Teil geht es darum, dass Refactoring gegen die bisherigen Schwierigkeiten helfen kann. Die drei Nachfolger von Fred heißen Karl, Orlando und Hans. Orlando war auf einer Schulung und lernte dort das ein permanenter Review-Prozess den Schmerz mit der IT lindern kann. Nach der Schulung kam er völlighref="http://miradlo.net/bloggt/index.php?78-s"">Episode 2, in diesem Teil geht es darum, dass Refactoring gegen die bisherigen Schwierigkeiten helfen kann. Die drei Nachfolger von Fred heißen Karl, Orlando und Hans. Orlando war auf einer Schulung und lernte dort das ein permanenter Review-Prozess den Schmerz mit der IT lindern kann. Nach der Schulung kam er völlig glücklich und aufgeregt nach Hause und nahm Karl und Hans mit zum Picknick am Familienteich. „Wir haben ja mitbekommen, dass eine ständige Erweiterung des Systems außer in den Teich nirgends hinführt. Wir spüren jetzt schon seit Wochen, dass die Änderungen immer gefährlicher werden. Das Refactoring kann uns, glaube ich, sehr viel helfen.“ Hans verstand bisher noch nicht, was ihnen das Refactoring helfen könnte. „Theorien sind ganz nett, aber wenn wir Mist bauen, sitzen wir ein paar Meter tiefer hier im See und brauchen uns keine weiteren Sorgen machen. Hier geht es im wahrsten Sinn des Wortes um Kopf und Kragen. Ich habe noch keine Lust abzutreten und deshalb musst du mir schon mehr erzählen, wie das gehen kann.“ Karl nickte zustimmend und Orlando erläuterte die Vorgehensweise: „Wir wenden jede Woche ein paar Stunden auf um den vorhandenen Code zu analysieren. Jede Funktion, jede Variable und jeden Kommentar überprüfen wir, ob der vernünftig dokumentiert, wirklich benötigt oder durch einen einfacheren Code ersetzt werden kann.“ Karl verschluckte beinahe seine gelbe Rübe am Stück und mußte erst einmal kräftig würgen. „Du willst an den bestehenden Lava Code ran? Das ist doch Wahnsinn und ein direktes Ticket in den Teich!“ „Es ist gefährlich, aber wir haben so eine Chance auf Dauer stabiler zu werden und ein wartbares System hinzubekommen.“ Orlando bemerkte: „Ok, wir haben keine Chance also nutzen wir sie!“ Die drei machten sich mit zitternden Fingern ans Werk. In Entwicklungsprojekten führe ich im Schnitt einmal die Woche einen Codereview und Coderefactoring durch. Dabei nimmt ein Mitarbeiter den Code eines anderen Mitarbeiters und kontrolliert folgende Eigenschaften:- Wird der Code wirklich benötigt? Eine einfache Kontrolle ist, ob auf den vorhandenen Code noch referenziert wird. Das kann man mit einfachem Suchen und Ersetzen feststellen.
- Gibt es genügend Testfälle (Unit Tests) für den Code?
- Kann die Dokumentation verstanden werden?
- Kann der Code einfacher gestaltet werden?
- Sollte der Code durch einen anderen ersetzt werden?
-
Blogroll und Archiv aktualisiert ::: Links in Artikeln
Ich habe inzwischen mal die Blogroll geputzt. Einige Links passten thematisch besser an anderen Stellen, beispielsweise die zu Wordpress stehen jetzt im Glossar Blogs. Wieder mal ergänzt habe ich auch das Glossar zu Webapplikationen, dieses Mal unter anderem um einige Links.
-
IE8 und das Metatag für Internet Explorer ::: geniale Neuigkeiten von Microsoft I.
Im Artikel Webdesign mit Webstandards oder für Microsofts Internet Explorer? habe ich ja bereits über die Diskussion bezüglich des geplanten Metatags berichtet. Der Grund für dieses Tag ist, dass gewährleistet werden muss, dass auch ältere Webseiten von aktuellen Browsern, in diesem Fall, dem IE8 (Internet Explorer 8), noch korrekt angezeigt werden können. Das neue Metatag ermöglicht explizit anzugeben, ob eine Seite so angezeigt werden soll, wie sie der, wohl tatsächlich standardkonforme, IE8 darstellt oder ob sie so ausgegeben wird, wie es eine ältere Version getan hätte. -
Blog für Mobiles, Handys und PDA usw optimieren ::: Blog4Mobile.de-Rezension
Diese Rezension befasst sich mit dem Online-Dienst Blog4Mobile.de, den es nicht mehr gibt. Kaputte Links habe ich entfernt, den Bericht lasse ich sonst so stehen, wie er ursprünglich war. Die Idee damals war gut, ist mittlerweile jedoch überholt.
Der Dienst bietet an, ein existierendes Blog für Mobiles, wie Handys und PDAs anzupassen, eins von mehreren Layouts zu wählen und das eigene Logo zu nutzen. Anschließend bekommt das Blog, in diesem Fall miradlo bloggt, eine Adresse auf handyblogger.mobi. Außerdem wird das Blog einer Kategorie zugeordnet und im Verzeichnis dort geführt, für dieses Blog unter Technik. , damit ist das Blog dann für Mobiles optimiert erreichbar. Zumindest vorerst ist der Dienst kostenlos. Die Einrichtung war recht einfach.
-
Softwareprojekte Episode 2 ::: Ein möglicher Versuch
Die Vorgeschichte und Episode 1 :::Episode 1 ::: So klappts nicht mit der Software beschrieben die Problematik, hier folgt ein möglicher Versuch. Die drei Nachfolger von Fred lernten sich, mehr schlecht als recht, in den von Fred erzeugten Code ein und das Familienunternehmen konnte weiter operativ tätig sein. Karl, einer der drei Nachfolger, formulierte seine täglichen Problemstellungen wie folgt: „Wir nehmen den nächsten Auftrag entgegen und skizzieren den möglichen Ablauf. Dann schauen wir welche Daten wir aus dem Altsystem benötigen und versuchen, wann immer möglich, nur lesend auf die Daten zuzugreifen. Wenn das nicht geht, kopieren wir die benötigten Daten in einen neuen Datenspeicher und replizieren in regelmäßigen Abständen die Originaldaten. Auf diese Weise müssen wir am bestehenden System nichts ändern. Die neuen Datenstrukturen beschreiben wir, damit wir später noch verstehen was die Komponenten tun.“ In gewachsenen Strukturen wird häufig das bestehende System nicht weiter entwickelt, da niemand genau weiß, welche Auswirkungen eine Änderung am System haben wird. Karl und seine Kollegen setzen auf diese Vorgehensweise. Ein Problem dabei ist, dass die Systeme permanent anwachsen und nicht mehr benötigter Code stehen bleibt. Es handelt sich um den Ansatz eines Anti-Patterns das Lava Code genannt wird. Alter, nicht mehr gewarteter Code bleibt bestehen und im Fehlerfall kann nicht nachvollzogen werden was von diesem Code noch benötigt wird. Mögliche Symptome für das Bestehen von Lava Code sind:
- Die Kosten für Wartung und Fehlerkorrektur steigen stetig an.
- Die Integration neuer Funktionalitäten wird immer komplexer und risikoreicher.
- Code ist vorhanden, der im eigentlichen Sinn keine Aufgaben mehr wahrnimmt.
- Ein Technologiewechsel wird immer unwahrscheinlicher, da das Migrieren von der alten Technologie auf die Neue zu gefährlich und teuer wäre. Viele Firmen müssen daher steinalte, nicht mehr supportete Hard- und Software einsetzen, um ihre IT-Systeme weiter betreiben zu können. Die Folge sind Systemausfälle, hohe Wartungskosten und kaum noch Weiterentwicklung der Systeme.
-
phpbb Forum installieren und einrichten auf dem Server
Wie bei aller Software für einen Webauftritt, ist der Start einer Installation die lokale Umgebung. Nach dem Herunterladen des phpbb-Forums ins passende lokale Verzeichnis des Webauftritts, auf dem es laufen soll, beginnt die Installation.Lokale Installation des Forums
- entpacken des Pakets in ein neues Verzeichnis, z.B. forum
- Rechte ändern für folgende Verzeichnisse und Dateien:
- cache
- files
- store
- config.php
- falls eigene Avatare genutzt werden sollen auch images/avatars/upload
- im Webbrowser aufrufen: http://localhost/forum dort die Installationsanleitung durchlaufen und die entsprechenden Einträge machen, lokal meist:
- Datenbankhost: localhost
- Datenbankname: name_des_webauftritts
- Datenbankuser: root
- Datenbankpasswort: leer lassen
- alle anderen Einträge, wie Datenbanksystem, Prefix usw. klappten mit der Voreinstellung bzw. sind selbsterklärend wie die eigene E-Mailadresse und ähnliches
- Design ändern
- je nachdem wie das angepasste Design aussehen soll, bietet sich ein anderes Theme als Grundlage an
- für das von mir gewünschte Design bot sich subsilver2 an
- einige Bilder liessen sich besser aus dem prosilver Theme anpassen
- Vorgehen der Anpassungen
- alle nötigen Bilder in ein Sicherheitsverzeichnis kopieren, im gewünschten Grafikprogramm, in meinem Fall Gimp, wie gewünscht anpassen, jedoch die Größe beibehalten, die die Grafiken im gewählten Theme haben.
- unter: forum/styles/subsilver2/theme/ findet man die Datei stylesheet.css
- von oben nach unten durch die Datei gehen und zunächst auf den eigenen Formatierungsstil anpassen hilft einen ersten Überblick zu bekommen.
- die im Stylesheet genutzten Farben betrachten und überlegen welche Farben mit ähnlichen Helligkeitswerten passen dazu aus der gewünschten Farbenpalette. In einem weiteren Durchlauf diese Farben nach und nach anpassen. (Bei Designs in negativen Farben, also z.B. helle Schrift auf dunklem Hintergrund muss sorgfältiger auf die Abstufungen geachtet werden, sonst erschwert es das Lesen)
- nach Einfügen der Bilder und den Farbänderungen können erste Foren und Nutzer angelegt werden usw. Dabei fallen nebenbei die Farbfehler auf, die noch angepasst werden müssen.
- wenn alles passt wie gewünscht, kann anschließend live installiert werden:
- endgültiges Installieren auf dem Webserver
- nach dem Hochspielen der Daten müssen die Rechte meist nochmals angepasst werden, siehe lokale Installation
- die Installationsroutine erneut durchlaufen, dieses Mal die fürs Web korrekten Daten eingeben
- das Design muss natürlich nicht erneut angepasst werden
- eine Überprüfung im Validator sollte ergeben, dass alles ok ist
- spätestens jetzt muss das Design und die Funktion des gesamten Forums in verschiedenen Browsern geprüft werden
-
Softwareprojekte Episode 1 ::: So klappts nicht mit der Software
Diese recht umfangreiche Einleitung soll, nach der Vorgeschichte, auf das Problem gewachsener Softwaresysteme hinführen. Ein monolitisches, nicht wartbares System entsteht nicht innerhalb von wenigen Tagen sondern wird durch viele Einflussfaktoren gebildet. Gründe hierfür können unter anderem sein:- Schlechte oder nicht vorhandene Dokumentation
- Keine Architektur und keine Planung für eine durchgängige Architektur
- Nicht verstandene Konzepte
- Stolz
- Keine Betriebskonzepte
Er überlegte kurz wie er das lösen will:
„Ich baue eine Eingabemaske mit der Giuseppe seine schweren Jungs erfassen kann. Da gibt er einen Namen, das Gewicht des Jungen und seine ihm zustehenden Prozente ein. Das Ganze speichere ich ab. Wenn Geld reinkommt, wird der Betrag dem jeweiligen schweren Jungen zugewiesen und über eine einfache Prozentrechnung bekommt der schwere Junge seinen Betrag.“ Gesagt, getan. Keine vierhundert Zeilen Code später hatte Fred sein System fertig. Er gab es Giuseppe und der war hell begeistert. „Eccelente! Ich kann endlich meine schweren Jungs sinnvoll verwalten. Jetzt habe ich aber noch ein Problem. Ich kann gar nicht sehen, welche schweren Jungs bisher bei mir arbeiten. Mach mir noch eine Anzeige um alle Jungs darstellen zu können.“ Und wieder war Fred glücklich, dass IT so einfach ist. Dreihundert weitere Zeilen Code und er lieferte eine Liste, mit der Giuseppe alle Jungs anzeigen lassen konnte. „Hm, das ist nicht schlecht. Aber ich möchte auch wissen wieviel jeder Junge im vergangenen Monat an Geld eingebracht hat.“ Also wieder in den Keller und schnell noch eine Liste basteln in der die Gelder der Jungs aufgelistet wurden. „Ja das ist schon brauchbar. Ich habe aber ein Problem. Ein paar der schweren Jungs fühlen sich ungerecht behandelt. Ich möchte jetzt wissen wann ich bei welchem Jungen die Prozentsätze angepasst habe.“ Fred setzte mittlerweile wegen der Schokoladenzufuhr an Gewicht an und glich sich allmählich an die schweren Jungs an. Sein System war nun schon recht komplex. Er musste aus dem bestehenden Code nun die Prozentsätze herausziehen und in eine Historie einbauen. Da Giuseppe ziemlich ungeduldig war, arbeitete er zwei Nächte durch und sah nun aus wie ein geübter Hacker auszusehen hat: Bleich, blutunterlaufene Augen und sich irgendwie nur noch am Kaffeebecher haltend. Die Zusammenarbeit mit Giuseppe ging ein paar Monate in diesem Modus weiter. Giuseppe stellte eine Aufgabe, Fred setzte sie um. Das Geldwäschesystem hatte nun mehrere hundert Komponenten, die Programmteile waren sehr unübersichtlich und Fred baute mehr Fehler ein, als er korrigieren konnte. Kurz vor Giuseppes Geburtstag machte Fred einen fatalen Fehler. Giuseppe wollte eine neue Funktion und Fred sagte: „Ich arbeite jetzt schon seit einem Jahr für dich. Ich möchte mehr Geld von dir haben. Ich bin der einzige der dein Geldwäschesystem versteht und bin somit sehr wichtig für deine Familie.“ Giuseppe antwortete: „Mein Junge, du verstehst das nicht ganz richtig. Niemand droht mir und niemand fordert von mir etwas. Ich verteile die Gaben, niemand sonst.“ Fred kam nicht mehr zur Arbeit und eine Woche später trat im Geldwäschesystem ein Fehler auf. Keine Gelder konnten mehr an die schweren Jungs ausgezahlt werden. Die fanden das nicht sonderlich nett und steckten Fred in Betonschuhe. Fred versank im Familienteich und konnte nicht lange genug die Luft anhalten. Er liegt vermutlich immer noch am Grund und isst heute keine Pizza mehr. Für die Familie waren die Probleme jedoch nicht gelöst. Wer sollte das Geldwäschesystem wieder zum Laufen bringen? Wie können die schweren Jungs bezahlt werden? Giuseppe organisierte drei neue Familienmitglieder die sich um das Geldwäschesystem von Fred kümmern sollten. Sie erreichten, dass das System wieder Gelder auszahlte. Aber sie klagten über diverse Probleme:- Die Programmstrukturen sind unübersichtlich
- Der Code ist nur unzureichend dokumentiert
- Eine Architektur ist nicht festzustellen
- Jede Änderung verursacht irgendwo anders einen Fehler
- Es ist besser neue Funktionen mit neuen Datenstrukturen zu schreiben als die alten zu verwenden
- Wichtige Komponenten, wie Zugriffskontrolle und Backup, sind nicht vorhanden
- Die Familie ist im Prinzip von Freds Wissen abhängig. Die erstellte Software kann als Legacy Code angesehen werden. Fred kann die Software aus begreiflichen Gründen nicht mehr warten.
- Die Familie hat sich in eine Abhängigkeit begeben, da sie nicht dafür sorgte, dass das Wissen von Fred auf andere Familienmitglieder übertragen wurde.
- Durch die nicht vorhandene Dokumentation und Architektur wird es den drei neuen Familienmitgliedern sehr schwer fallen neue Funktionen anzubringen und das System zu warten.
- Offensichtlich ist es nicht sehr ratsam sich gegen Giuseppe aufzulehnen
- Er war stolz und sich nicht darüber im Klaren das jeder Mitarbeiter ersetzbar ist.
- Seine Vorgehensweise ohne Dokumentation und Betriebskonzept ein komplexes System zu erstellen, war definitiv nicht brauchbar, um das System für längere Zeit betreiben zu können.
Seite 2 von 2, insgesamt 13 Einträge
...zuletzt schrieb: