Skip to content

Webentwicklerinnen/ Webentwickler und Webdesignerinnen/ Webdesigner 2008

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Im Artikel zur Umfrage der Webkrauts habe ich auf die Umfrage hingewiesen, inzwischen sind die Ergebnisse online. Eine Zusammenfassung gibts auf der Seite der Webkrauts, die ausführlichen Ergebnisse auf Michael Jendryschiks Seiten, die auch schon die Umfrage selbst beherbergten. Teilgenommen haben 2803 Webworker, die sich selbst meist eher als Webentwickler oder Webdesigner bezeichnen. Wenn wir gefragt werden, was miradlo vor allem macht, dann lautet unsere Antwort bezogen darauf: miradlo befasst sich vor allem mit Webapplikationen und dem Erstellen von Webseiten. Unsere weiteren Tätigkeiten sind in diesem Fall nicht relevant. Als Tätigkeitsbezeichnung sagen wir, so wie die Mehrheit, dass wir Webdesigner und Webentwickler sind. Teilbereiche wie z.B. Softwarearchitektur, Usability und Grafikdesign erwähnen wir in diesem Zusammenhang nicht explizit. Sicherlich liegen die guten Werte, dass sich rund dreiviertel der Webentwickler um das Einhalten von Webstandards bemühen auch daran, dass die Umfrage im Bereich derjenigen, die sich für Webstandards interessieren stärker beworben wurde. Denn schaut man sich sonst im Web um, müssten daraus folgend ja rund dreiviertel der Webauftritte standardkonform sein. Leider konnte ich keine Statistik finden, wieviele deutschsprachige Internetauftritte sich an die Webstandars halten. Ich befürchte jedoch es sind bisher kaum mehr als ein Drittel.

Webentwicklerinnen und Webdesignerinnen

Laut den persönlichen Angaben liegt der Frauenanteil mit 270 "Webworkerinnen" (den Begriff nutzt Michael Jendryschik) von 2803 Teilnehmern insgesamt bei 9,63% also unter 10%. Die Webkrauts vergleichen diesen Anteil mit dem in Informatikstudiengängen. Aus meiner Erfahrung kann ich das nicht bestätigen, ich habe häufig morgens gehört: "Guten Morgen meine Herren, guten Morgen Frau Hauth". Manchmal gab es zwei Frauen in einem Semester mit rund fünfzig Studierenden, insgesamt waren es im Bereich der technischen Informatik eher noch deutlich kleinere Anteile als 10%. Insofern finde ich es schon erfreulich, dass in der Webentwicklung immerhin schon fast jede zehnte eine Frau ist.

Fish & Chips Incident-Process

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Ein anderer Titel für diesen Blog ist: „How to get a cup of coffee for free, learn about Incident management and understand the need for a security concept.“ Doch dieser Titel ist etwas lange... Ich war mal wieder „dienstlich“ in England unterwegs. Eigentlich sollte ich für meine Firma herausfinden, was man dort alles besser machen kann. Nun zumindest für das Leben habe ich etwas gelernt. Trotz, oder wegen, meines Übergewichts kann ich nicht darauf verzichten Fish & Chips zu kaufen. Natürlich mit Salt and Vinegar. Also, ich gehe in den nächsten Futterladen und finde vier Frauen und einen Mann vor. Die Personen möchte ich mit Fischfrau 1, Fischfrau 2, Fischfrau 3, Cheffischfrau und John den Fischgriller bezeichnen. Mich selbst nenne ich Kunde 1. Fischfrau 1: "Hello" Kunde 1: "Hello, one fish and chips please." Fischfrau 1: "John, one fish and chips please!" John stürzt sich an die Fritiermaschine und der Fisch wird generiert. Fischfrau 1: "3,50 please." Kunde reicht eine zwanzig-Pfund-Note. Fischfrau 1 benutzt die Registrierkasse und liefert 6,50 Pfund zurück. Außerdem schließt sie die Kasse. Kunde 1 wundert sich und erwähnt, dass er gerne noch zehn Pfund change mehr hätte. Immerhin bedeuten zehn Pfund später ungefähr drei Biere, die Kunde 1 benötigt um diesen Blog formulieren zu können.

Juchu! Wir haben einen Incident!

Fischfrau 1 erkennt, dass sie einen Fehler gemacht hat. Sie ruft nach der Cheffischfrau. Das klappt aber nicht, da Fischfrau 2 besorgt heranstürmt und sich die Sachlage erklären lässt. Das Problem lässt sich schnell und einfach eingrenzen. Kunde hat zwanzig Pfund gegeben und nur für zehn Pfund Ware und Geld erhalten. Die beiden haben eine erste Lösung erarbeitet. Fischfrau 2 fragt den Kunden 1, ob er wirklich zwanzig Pfund gegeben hat. Dieser beantwortet die Frage mit „yes“. Beide Fischfrauen rufen nach der Cheffischfrau und erklären dem Kunden „I am sorry“. Ein weiterer Kunde kommt vorbei und fragt wie lange der Fischladen heute offen hat. Fischfrau 2 sagt ihm, dass bis um halb zehn offen ist. Es wird ein weiteres „I am sorry“ dem Kunden 1 entgegen geschmettert. Dieser denkt sich noch nichts dabei, da John den Fisch fertig gebraten hat und in den Fischzwischenspeicher überführt hat. Die gesamte Aufmerksamkeit des Jägers (Kunden 1) ist nun auf den Fisch gerichtet. Eventuell kann via Telepathie der Fisch herüberwachsen? Cheffischfrau erscheint und erkennt, dass die Kasse geöffnet werden muss. Cheffischfrau: „John, I need the key!“ John liefert den Schlüssel an Fischfrau 3, die sich an Fischfrau 1, Fischfrau 2 und Cheffischfrau vorbeizwängt um die Kasse zu öffnen. Cheffischfrau generiert eine Abrechnung der Kasse. Hierzu wird der Saldo über alle vorhandenen Tagestransaktionen ausgedruckt. Fischfrau 1 steht nebenan und ist vollkommen von Scham und Schande eingewickelt. Sie kann außer '„I am sorry“ sagen' nichts mehr tun. Cheffischfrau fängt an, vor allen Gästen die Münzen, die sich in der Kasse befinden, zu zählen. Die weiteren Kunden bezahlen ohne change zu benötigen. Dreimal klappt das auch und Fischfrau 2 und 3 können die Lage unter Kontrolle halten. Beim Kunden 4 geht das schief. Er benötigt Wechselgeld. Der Betrieb muss eingestellt werden. Eine Schlange williger Fischkäufer bildet sich. Fischfrau 1 kann kaum noch atmen, generiert jedoch in regelmäßigen Abständen ein „I am sorry“. Kunde 1 beteuert, dass so etwas ja mal passieren kann. Die weiteren Kunden sehen das vermutlich anders und beginnen den Kunden 1 als alleinigen Schuldigen zu deklarieren. Cheffischrau ist mit dem Zählen der Münzen durch und macht sich an die Scheine. Kunde 1 beginnt Strategien zu erarbeiten.
  • Geld zurück geben lassen?
  • 10 Pfund abgeben und auf drei Biere verzichten? (kaum vorstellbar)
  • Weiter lächeln oder doch den deutschen Proll auspacken?
  • Einfach gehen und zwanzig Pfund abschreiben? (sicher nicht, bin Schwabe)
  • Kontrolle, ob er tatsächlich 20 Pfund übergeben hat oder ob der Fehler doch bei ihm liegt. (klingt verlockend und wird als Zwischenlösung angesehen.)
Cheffischfrau hat fertig gezählt. Alle vier Frauen und John ziehen sich nach hinten zurück und beraten die Lage. Kunde 1 hört ein paar sehr beunruhigende Worte: „I can't pay him 10 pound back!“ Nach weiterer Kontrolle kommt Cheffischfrau wieder nach vorne. „You gave us 20 pound?“ Kunde 1 bejaht. Sie zeigt die Kassenabrechnung und ihr Zählergebnis. Die Zählung ergab, dass sich 978,50 Pfund in der Kasse befinden. Die Abrechnung behauptet, dass nur 968,50 Pfund vorhanden sein sollen. Es könnte also durchaus sein, dass der Kunde 1, zehn Pfund zu wenig Wechselgeld erhalten hat. Die Entscheidung ist getroffen worden, der Kunde 1 erhält zehn weitere Pfund zurück. Fischfrau 3 fragt Kunden ob er ein "Coffee" aufs Haus haben will. Dieser bejaht. Fischfrau 2 verpackt den Fisch und fragt nach salt & vinegar. Fischfrau 1 japst ein letztes „I am sorry“. Kunde 1 wird mit seinem Fisch, Geld und Kaffee entlassen und verschwindet. Der Incident-Fall wird abgeschlossen.

Ergebnis des Incidents:

Mindestens vier Gäste sind verschwunden und entschieden sich für Diät oder einen anderen Fischladen. Der Incident verursachte 15 Minuten Stillstand im Laden. Weiterhin mussten Löhne für 5*15 Minuten bezahlt werden was somit 75 Minuten Arbeitszeit ausmacht. Ein Kaffee (Kosten ca. 50 Pence) musste mitgegeben werden. Für die 15 Minuten musste die Arbeit eingestellt werden und dennoch Raummiete, Strom usw. bezahlt werden.

Folgende Behauptung wird aufgestellt:

Wenn die 10 Pfund sofort zurückgegeben worden wären, wären die Kosten geringer gewesen. Faszinierend finde ich allerdings, dass sich Cheffischfrau nicht verzählt hat. :-) Jetzt kommt aber der Hammer! Stellt euch vor ich wäre ein Krimineller.
  • Ich weiß, wann der Fischladen zugemacht wird (halb zehn)
  • Ich weiß, dass mindestens 968,50.- Pfund in der Kasse vorhanden sind.
  • Ich komme um halb zehn mit meinem Freund Revolver vorbei und erhalte nicht nur einen Kaffee umsonst sondern auch noch 968,50 Pfund.
Daraus folgt, dass der Verlust sich um mindestens 968,50 Pfund erhöht. Der Incident Prozess führt zu sehr hohen Verlusten. Es wird den Verbrechern direkt mitgeteilt was an einem Freitag ungefähr in der Kasse ist. => Die Gefahr dass die Räuber am Freitag öfters vorbei kommen wird erhöht. Gegenmaßnahmen:
  • Zählen von Geld immer ohne direkten Blickkontakt der Kunden
  • Security Konzept ist notwendig und führt zu einem sichereren Betrieb.
  • Keine 1000 Pfund in der Kasse deponieren. Ab- und zu mal Geld entfernen und an einem sicheren Ort lagern.
  • Fünf Personen sind für den Fischladen gleichzeitig zu viel. Man kann z.B. mit drei Personen den Laden laufen lassen und die Ladenöffnungszeiten mit gleichem Personal verlängern. Die treten sich dann nicht auf den Füßen herum und haben alle ein bisschen was zu tun.
  • Die Mehreinnahmen können zu mehr Lohn für die Mitarbeiter führen.
  • Mehr Spaß an der Arbeit, da sie nicht mehr so langweilig ist.
Ich werde jetzt auf alle Fälle meinen Job kündigen und mich als Fischladen-Optimierer durchschlagen. ;-)

Barcamp Bodensee - Web-Konferenz im Mai 2008 in Friedrichshafen

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Beim Barcamp Bodensee gibt es vor allem für Studierende und Teilnehmer aus anderen Ländern als Deutschland noch Plätze. Anmelden kann man sich im Wiki des Barcamps. Das Barcamp findet vom 31. Mai bis 1. Juni 2008 in Friedrichshafen statt. Für Studenten insbesondere aus der Region bietet das Barcamp eine tolle Möglichkeit sich in lockerer Atmosphäre weiterzubilden. Aus unserer Sicht kann es kaum ein näher gelegenes Barcamp geben, daher freuen wir, Roland und ich uns darauf erstmals teilzunehmen. Aus den Anregungen, welche Themen interessant wären, hat Roland sich entschlossen die Anregung "Softwarentwicklung in verteilten Teams - Tools, Vorgehensweisen" aufzugreifen und dieses Thema anzubieten. Wenn es so interessant wird, wie es klingt, dann wird es sicherlich nicht das letzte Barcamp, an dem jemand von miradlo teilnimmt.

Ausschnitt aus der offiziellen Ankündigung

Wie sehen Konferenzen von Leuten aus, für die Weblogs und Wikis - wie Wikipedia - Alltag sind? Sie heißen „Barcamps", und ihr Programm wird von den Teilnehmern komplett selbst bestimmt und getragen. Ein solches Barcamp wird von 31. Mai bis 1. Juni 2008 in Friedrichshafen stattfinden. Gastgeber ist die Zeppelin Universität (ZU). Gerechnet wird mit bis zu zweihundert Teilnehmenden. „Friedrichshafen ist ein idealer Standort für ein Barcamp", betont der ehrenamtliche Organisator Oliver Gassner, der im Hauptberuf Kommunikationsberater ist, „ein Universitätsstandort mit Flughafen, kurzen Wegen zum deutschsprachigen Ausland und mitten in einer Technologieregion". Die Veranstalter hoffen vor allem auf internationales Publikum und auf Zustrom aus den Schulen und Hochschulen des Umlandes und der Anrainerstaaten. (...) Ein Eintritt übrigens fällt bei Barcamps nicht an. (...) Die Barcamp-Idee entstand vor zweieinhalb Jahren in den USA. Weitere Informationen zum Barcamp Bodensee unter http://barcampbodensee.mixxt.eu

Episode 6: Grenzen des Refactorings ::: Softwareprojekte

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Zu Episode 1 wurde ein Kommentar geschrieben der mir zeigte das auch noch andere Mitstreiter das Problem des Refactorings aktiv angehen. Die Aussage „Andererseits weiß ich, dass wenn ich die Firma verlasse, dann werden die Projekte andere nach mir übernehmen und wieder alles reverseengeneeren müssen. ...wenn ich das Unternehmen verlasse, muss von vorne begonnen werden“ fand ich sehr passend. Mit Refactoring kann man nicht die Welt retten. Ein Softwaresystem ist für mich wie ein lebender Organismus. Unsere Haut wird beispielsweise alle sieben Jahre erneuert. Bei Software verhält sich das im Prinzip genauso.

Orlando war mal wieder auf einer Schulung

Ok, da war er schon in Episode 3 und das hat auch seinen Grund. Orlando ist Single und liebt es in Hotelzimmern herumzuhängen. Da das Familienunternehmen zur Zeit noch nicht in mehreren Ländern vertreten ist, ist es für ihn die einzige Möglichkeit das Jet-Set-Gefühl zu erleben. Bei der Schulung wurde der Model Driven Architecture-Ansatz besprochen. Wieder kam er freudestrahlend zurück und wollte das Erlernte sofort ausprobieren. Das ist auch eine typische Orlando Eigenschaft. Er nimmt gerne Neues an und versucht so viel wie möglich gleich zu implementieren. Da es sich bei dem, von Hans, Karl und Orlando, betreuten System um ein hochriskantes, produktives System handelt, ist diese Freude an Neuem für Hans und Karl nicht unbedingt nachvollziehbar. Zuweilen sind Orlandos Kollegen sonderbar altmodisch und wollen vor allem ein überlebensfähiges, stabiles System haben. Vielleicht liegt das an den Betonschuhen die am Ausgang von den schweren Jungs abgestellt wurden... Wie dem auch sei. Hin- und wieder werden Hans und Karl von Orlando überredet etwas Neues zu implementieren. Die Drei wollten erreichen, dass die Entwicklung auf Dauer gesehen immer stabiler und sicherer wird. Deshalb schauten sie sich ihr System genauer an und überlegten ob Model Driven Architecture eventuell eingeführt werden kann.

Keine Architektur?

Karl schaute sich die bisherigen Architekturkonzepte an. „Also im Moment sind wir mit einem Mischmasch zwischen prozeduraler Programmierung und objektorientierter Programmierung konfrontiert. Wenn wir das ändern wollen, müssen wir das ganze System am Besten wegwerfen und neu bauen.“ Die drei waren sich hier sehr einig. Ein Neubau würde jedoch einem langanhaltenden Tauchgang im Familienteich nahe kommen. „Vielleicht können wir uns wenigstens eine Architektur überlegen wie es aussehen sollte und das als unsere Strategie definieren. Dann könnten wir beim Review darauf achten in die Richtung der Strategie zu arbeiten“, bemerkte der geschulte Orlando. Hans nickte zustimmend. „Das klingt schon eher machbar. Wir werden also mit dem Refactoring keine endgültige Lösung finden. Wir werden die, zur Zeit erkannten Fehler und Missstände, aufdecken und korrigieren können. Das System wird also nie fertig werden.“ Orlando überlegte: „Ich glaube, dass ist eine normale Eigenschaft in komplexen Systemen. Jede neue Idee führt zu einer Änderung und diese Änderung erfordert neue Vorgehensweisen. Ich glaube das Geheimrezept liegt im Changemanagement und in der Umsetzung der Strategievorgaben. Lasst uns zuerst einmal eine Strategie für die nächsten drei- bis fünf Jahre definieren. Wir sollten dringend mit Giuseppe reden um zu erfahren was er alles vor hat. Dann können wir unsere IT-Bemühungen entsprechend auslegen.“ Vielleicht habt ihr euch schon hin- und wieder gefragt warum Firmen viel Geld für Enterprise Architektur ausgeben. Ich habe im Moment das Vergnügen mit den Architekten eng in einer Gruppe zusammen arbeiten zu können. Die Kollegen produzieren im Prinzip (außer Papier und endlosen Telefongesprächen ;-) ) nichts. Doch der Gewinn für die Firma ist, dass sie sich über die weiteren Jahre Gedanken machen. Es ist wichtig die IT-Landschaft, wie jede andere Prozesslandschaft, über die Jahre hin proaktiv zu bewirtschaften. Unsere drei Freunde haben aus Angst vor Betonschuhen bisher nur reagiert. Mit dem Handwerkzeug Reverse Engineering, haben sie erreicht sich über Wasser zu halten und nicht zusammen mit ihrem alten System zu sterben. Doch um wirklich eine gute Zukunft zu haben, kommen sie um eine Strategie und eine sinnvolle Planung nicht herum. Es wird Zeit das wir eine Koordination in die Geschichte bringen! Um ehrlich zu sein, ich bin gespannt wo dieses Blog noch hinführt...

Wörter und Zeichen eines Beitrags zählen : TinyMCE in Wordpress anpassen

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Mal möchte man Beiträge nur veröffentlichen, wenn sie eine Mindestanzahl an Wörtern haben, z.B. bei trigami-Rezensionen, oder man will einen Beitrag in mehrere aufteilen, sobald eine bestimmte Anzahl an Wörtern überschritten wird. Wer daher ab und zu mal Wörter oder Zeichen eines Beitrags zählen möchte, kann sich natürlich einfach den Text in ein Textverarbeitungsprogramm oder einen Editor auf dem Rechner kopieren, die diese Funktion haben. Sei es der OpenOffice.org Writer oder ein Editor wie KWrite, alternativ Microsoft Word oder ähnliches, dort gibt es diese Funktion bereits. Will man diesen Umweg vermeiden, dann lässt TinyMCE, der in Wordpress integrierte WYSIWYG-Editor ebenfalls anpassen.

Anleitung Wörter zählen im Wordpress-Editor

Um innerhalb von Wordpress Wörter zählen zu lassen, gibt es ein Plugin. Für den genutzten Editor TinyMCE gibt es das Plugin "charcount". Damit lassen sich die Wörter eines Artikels zählen. Angezeigt werden: die Anzahl an Wörtern und die Anzahl an Zeichen, sowohl mit, als auch ohne Whitespaces (Whitespaces sind alle Leerzeichen, Absätze usw.) Das Ganze klappte bei mir wie folgt:
  • Das Plugin charcount runterladen
  • entpacken
  • ins Verzeichnis /wp-includes/js/tinymce/plugins/ kopieren
  • die Datei /wp-includes/js/tinymce/tiny_mce_config.php an zwei Stellen anpassen:
    • dem Array plugins charcount hinzufügen: $plugins = array('charcount');
    • dem Array mce_buttons charcount hinzufügen: $mce_buttons = apply_filters('mce_buttons', array('bold', 'italic', 'charcount',));
  • alles hochladen
  • den Editor eventuell mit STRG und neu laden, aktualisieren
  • der neue Button "123 ABC" wird angezeigt.
  • Dieser Beitrag hat dann:
    • Wörter: 224
    • Zeichen ohne Leerzeichen: 1570
    • Zeichen mit Leerzeichen: 1803
Getestet in Wordpress 2.3, viel Spaß und Erfolg damit.

Aktualisiert Februar 2009

Ab der Version WordPress 2.7 werden die Wörter von Haus aus gezählt und nach jedem Speichern unterhalb des Eingabefensters des Editors angezeigt. Für eine Anzeige auch von einzelnen Zeichen ist auch weiterhin ein Eingriff nötig.

Softwareprojekte Episode 5 ::: Coderefacturing und Lavacode Beseitigung

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Begonnen habe ich mit der Vorgeschichte und den Episode 1, Episode 1, 2, 3 und 2, 3 und 4 in diesem Teil geht es um Coderefacturing In Episode 3 (Refacturing kann helfen) habe ihref="http://miradlo.net/bloggt/index.php?79-s""> 3 und 4 in diesem Teil geht es um Coderefacturing In Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefhref="http://miradlo.net/bloggt/index.php?80-s""> 4 in diesem Teil geht es um Coderefacturing In Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefen schon einige Wochen. Im Schnitt schafften sie zehn Klassen pro Woche und mittlerweile konnten sie schon diverse Probleme und Schwachstellen ausloten und flicken. Orlando war gerade dabei einen Observer zu putzen. Im Dateisystem fanden sich folghref="http://miradlo.net/bloggt/index.php?79-s"">Episode 3 (Refacturing kann helfen) habe ich schon ein bisschen über Lavacode und Reviewzyklen gesprochen. Jetzt möchte ich ein paar Beispiele, wie Lavacode aussieht und wie man ihn wegputzen kann, aufzeigen. Die Review-Sessions von Hans, Karl und Orlando liefen schon einige Wochen. Im Schnitt schafften sie zehn Klassen pro Woche und mittlerweile konnten sie schon diverse Probleme und Schwachstellen ausloten und flicken. Orlando war gerade dabei einen Observer zu putzen. Im Dateisystem fanden sich folgende Dateien:
  • lavaklassen
  • TestDummyModel Eine Unit-Testklasse mit der das DummyModel auf Funktion überprüft wurde.
  • BaseUIElement Der Observer mit dem das Subjekt überwacht werden soll.
  • TestBaseUIElement Ratet mal ;-) Ist wohl eine Testklasse.
  • BaseModel Beinhaltet die Basis-Modell Information und schlussendlich die echte Subjekt-Methode.
Um das BaseModel testen zu können, wurde ein TestBaseModel eingeführt. Das DummyModell wurde nur dazu benötigt um die protected-Methoden der BaseModelklasse testen zu können. Der Aufwand, um DummyModel und TestDummyModel entwickeln zu können, betrug in etwa einen Arbeitstag. Jetzt kommt aber der Hammer: Die Wartung von DummyModel und TestDummyModel kostete zwei Stunden. Im zweiten Jahr wuchsen die Wartungsaufwände auf zwei Tage an. Das bedeutet, dass die Wartung mehr kostete als die ursprüngliche Herstellung. Wie konnte das passieren? DummyModel wurde nicht nur für den Test von BaseModel verwendet, sondern wurde in vielen anderen Testszenarien als einfache Lösung angesehen, die protected-Methoden von BaseModel zu verwenden.
  • lavaexplosion
Eine Änderung am DummyModel verursachte nun enorme Kosten bei den Testklassen.

Was kann man da besser machen?

Ok, zuerst kann man mal über ein sauberes Konzept und „wir programmieren nur gegen Schnittstellen“ und all die schönen Regeln beherzigen. Manchmal sieht man aber den Klassenwald vor lauter Methoden nicht mehr. Lavacode entsteht, niemand kann ihn 100% verhindern. Wenn aber so ein Problem erkannt wurde, muss man handeln. Orlando griff in die Tasten und entfernte das DummyModel. Das Testen der protected-Methoden löste er durch eine Wrapperklasse im TestBaseUIModel und die Testklassen wurden so umgebaut, dass sie sich wieder an Schnittstellen halten und keine Wartungsexplosion zu erwarten ist. Karl hatte an einem nebligen Freitag ein Problem beim Review. „Jungs schaut mal her: Diese Methode hier verursacht das Problem, dass wir an zwanzig Stellen im Programm Abhängigkeiten schaffen. Das ganze ist nicht modular sondern vernetzt. Wenn ich das jetzt aber ändern soll werde ich nicht fertig und außerdem müssen wir das extrem gut testen. Was sollen wir machen?“ Termine drücken im Familiengeschäft immer. Wenn die drei den nächsten Release vergeigen ist mindestens einer der Drei bei Fred. Dementsprechend sind Klaus, Orlando und Hans etwas vorsichtig beim kompletten Umstellen der Systemkomponenten. Hans schaute sich das Problem an: „Also gut, wir schaffen das jetzt nicht. Geh doch durch alle dir bisher bekannten Komponenten durch und schreibe ein TODO hinein. Wir analysieren das Thema über die nächsten Wochen und falls wir dann glauben, dass wir es schaffen können, putzen wir den Code.“ Diese Idee beruhigte die Nerven der drei gestressten Entwickler doch sehr. Vier Review-Zyklen später war das Problem vollständig analysiert und sie konnten ohne Familienteich die Abhängigkeiten auflösen. Wenn beim Codereview festgestellt wird, dass ein größerer Aufwand vorhanden ist, muß dies vermerkt werden. Der Projektleiter muss eine Issue-Liste führen und neue Anforderungen und Probleme dort hinterlegen. Es werden immer Problemstellungen vorhanden sein, die nicht sofort gelöst werden können. Die schlechteste Alternative ist diese einfach zu verdrängen. Wenn im Sourcecode dokumentiert ist, dass noch Nacharbeiten notwendig sind und Zeit und Aufwand für diese Nacharbeiten im Projekt budgetiert worden sind, stellen diese notwendigen Korrekturen kein Problem dar.

Abendwolken : geändertes Design auf miradlo bloggt

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Am 12. April war bei uns unser Tag der Ofentür;-) dafür gab es einige Tage das dazu passende Design. Inzwischen ist dieser Aktionstag abgeschlossen, mehr dazu in einem eigenen Beitrag in den nächsten Tagen.
  • Screenshot Designmiradlo Tag der Ofentür
Wie gewohnt also wieder einmal ein Designwechsel, dieses Mal halt ein bisschen schneller als gewohnt. Da das Ofentür-Design sehr ablenkend ist, wollte ich es nicht zu lange online lassen.