Kategorien
Reverse Requirement Engineering
Es ist wieder so weit. Es wurde ein neuer Ausdruck erfunden oder zumindest wurde er geprägt. Dabei geht es eigentlich um eine Begründung, warum man in vielen Softwareprojekten so schlecht Refaktorieren kann und warum ein Rewrite auch nicht immer klappen muss.
Computerprogramme entwickeln irgendwann ein Eigenleben. Meistens beginnen sie zwar strukturiert und wahrscheinlioch sogar mit sauber aufgeschriebenen User Stories oder Use Cases, irgendwann kommt man aber in den Wartungsbetrieb. Dort kommt es sehr häufig vor, dass man auf Zuruf noch eine Kleinigkeit ändert oder ein Feature einbaut. In den meisten Fällen werden diese Änderungen nicht dokumentiert und wenn, dann nur im Ticketsystem. Es dauert nicht lange, bis das System genau so viele dokumentierte, wie undokumentierte Bestandteile hat. Ist ja eigentlich nicht schlimm, das System kann dennoch stabil laufen.
Begeben wir uns aber mal in die Situation, dass wir einen Teil einer Applikation neu schreiben müssen. Vielleicht weil der existierende Sourcecode unwartbar geworden ist. Wie geht man jetzt vor?`Angefangen wird mit der Dokumention, die man noch irgendwo findet. Dort wurden die grundsätztlichen Verhaltensweisen beschrieben. Ist ja schon mal ein Anfang. Dann fängt das richtig fiese an. Man muss sich durch die Applikation klicken, um das tatsächliche Verhalten der Anwendung rauszufinden. Da fallen dann wohl ein paar Features raus, die man ja nachprogrammieren muss. Wenn man jetzt noch nicht alles zusammen hat, was man für einen Relaunch braucht, dann geht es in den Source Code. Hier ist es wohl am schwierigsten die Anforderungen rauszulesen, aber es ist möglich.
Joa das war’s dann. Reverse Requirement Engineerung und ich hasse es.
Das Problem an der Sache ist mE die Wartungsphase. Diese wird von der Softwareentwicklung getrennt betrachtet und die Vorgehensweisen und Rollen die in zur Entwicklungszeit existieren werden über den Haufen geworfen.
Ich denke man muss hier ebenso gewissenhaft wie in der Entwicklung vorgehen und schon sollte das Thema „Reverse Requirement Engineerung“ gar nicht aufkommen.
Und übrigens ich finde das auch ganz schrecklich. 🙂
Das kenn ich auch. Kennt jemand ein Projekt, am besten mit Kundenbeteiligung, bei dem die Doku vorbildlich gepflegt wird? Wäre schön, wenn es ein Tool gäb, das sich in Ticketsysteme einhakt und Doku baut oder ein Ticketsystem, das irgendwie dabei hilft.
Wie schön, wieder ein Fremdwort für Schlipsträger die nicht wissen was dahinter steckt, aber es ist bestimmt cool…. Ist es nicht und man sollte es wieder abschaffen! 🙂
Ich hab auch gerade genau diese Phase hinter mir, was ich mich allerdings Frage, warum Code Review nicht als Bezeichnung für diese Aktivität ausreicht?
Gottogott,
genau vor diesem Problem stehe ich gerade, bis auf die Tatsache, das NULL Dokumentation vorhanden ist und man eigentlich alles mit Ausprobieren herauskriegen muss. Weiterer Nachteil ist, dass irgendwo irgendwelche undokumentierten Quelltext rumfliegen, die dann mittels Include eingebunden werden, in denen Variablen vorkommen ala $angebotsabfragecode = „xxx“; und man nicht weiß, wo $angebotsabfragecode benötigt wird, et cetera.
Das Problem bei der Sache ist, dass der Kunde gerne neue Features in Auftrag gibt, jedoch die Phase des Refactorings (die definitiv ansteht) immer weiter nach hinten verschiebt. Irgendwann ist das System unwartbar. Ist schon kurz davor. Könnte kotzen.
Sorry musste mir bei diesem Thema mal schnell den Frust von der Seele reden. Irgendwer ne Idee, wie ich da jetzt am besten rangehe, sodass Chef & Kunde die Notwendigkeit erkennen?
Grüße
Verkauf es unter falschem Deckmantel. Sowas bekommt man sonst nur sehr schwer durch.
Versuch es mit Performanceproblemen zu begründen, ideal wenn sogar welche bestehen.
Alternativ kann auch herhalten, dass durch die PHP Weiterentwicklung neue Funktionen und Verhaltensweisen nutzbar geworden sind, die den Code vereinfachen. Besonders Praktisch wenn rein funktional gearbeitet wird und bisher auf Klassen verzichtet wurde.
Sofern das Rad gern neu erfunden wird, kann auch ein Framework als Begründung herhalten. Es kostet halt am Anfang Zeit, aber hinten raus lohnt es sich …
Sowas funktioniert eigentlich immer.
Ja, das Problem hatte ich auch schon einmal. Schön, dass es jetzt auch einen schön nerdigen Namen dafür gibt. Danke für den interessanten Beitrag.
Redet ihr hier von Anwendungen a la WordPress oder ähnlichen prähistorischen PHP-Monstern?
Ich sage nur „deprecated“…
PS: Nils, willst du uns mit diesem „Artikel“ nur ein neues Buzzword beibringen oder dir den Frust von der Seele schreiben?
Falls Letzteres: nur zu, hau alles raus, was dich frustet!
@Don: Wahrscheinlich ein wenig von beidem 😉
Vor solchen Problemstellungen stehe ich eigentlich die ganze Zeit. Aktuell bewährt sich gerade das separieren von Webseitenteilen. Die einzelnen Units bleiben dabei überschaubarer und man kann Teilbereiche neu machen. Außerdem muss man nicht auf Gott und die Welt Rücksicht nehmen, was den Code sehr viel einfacher macht.
Zum Chef Thema: Performance (am besten wenn mal wieder der Server hängt oder die Seite ewig zum laden braucht), SEO (Google hat ja nun auch die Ladegeschwindigkeit als Ranking Faktor. Wenn wir also eine schnellere Seite haben, bekommen wir mehr Besucher) und aktuell sehr gut Serverumzug (Die alten Systeme über zusetzen ist aufwändiger als sie neu zu bauen :P).
@Norbert/Wartungsphase
Sehe ich genauso. Softwarewartung ist leider sehr teuer im Vergleich zum sichtbaren Nutzen und damit dem Kunden nur schwer zu vermitteln. Ich musste leider auch dazu übergehen, einen Teil der Wartung immer bei Featurewünschen mitzubetreiben, weil sich dort anfallende Arbeiten einfach leichter rechtfertigen lassen. Ist kein schönes Gefühl, aber wenigstens hat man halbwegs die Sicherheit, das das System überschaubar bleibt.
Optimierung (Schlagwort Google) ist auch immer ein guter Grund. Schließlich legt Google ja Wert auf Performance, knappen Quellcode etc., was ja oft Abfallprodukte von Refactoring sind. Davon, dass Kunde und Entwickler den Fokus auf die gleichen Dinge setzen, können wir uns wohl getrost verabschieden.
Schönes neues Wort für ein uraltes Problem 😉
Ich hatte gerade mehrere Wochen das Vergnügen mit so einem „gewachsenen“ Projekt. Hoffentlich nicht so bald wieder…