• Vorträge

    Viele Vorträge, die auf Konferenzen gehalten werden, landen irgendwo im Internet. Wir haben sie für euch zusammengesucht.

    • Reverse Requirement Engineering

    von am 25. August 2010

    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.

    Nils Langner

    Auch wenn Ihr es mir nicht glauben werdet, aber ich habe nichts gegen PHP. Ich rege mich einfach nur gerne auf. Ok so schlimm ist es auch nicht. Eigentlich wollte ich schon immer einen Blog haben und da ...

    Zum Profil von Nils Langner

    12 Kommentare »


    • Norbert
      am 25. August 2010 um 08:05 Uhr

      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. :)


    • Daniel
      am 25. August 2010 um 08:58 Uhr

      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.


    • butzi
      am 25. August 2010 um 09:45 Uhr

      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?


    • stietze
      am 25. August 2010 um 10:00 Uhr

      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


    • butzi
      am 25. August 2010 um 10:24 Uhr

      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.


    • Lars Ebert
      am 25. August 2010 um 11:06 Uhr

      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.


    • Don
      am 25. August 2010 um 11:10 Uhr

      Redet ihr hier von Anwendungen a la WordPress oder ähnlichen prähistorischen PHP-Monstern?
      Ich sage nur “deprecated”…


    • Don
      am 25. August 2010 um 11:16 Uhr

      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!


    • Nils Langner
      am 25. August 2010 um 11:53 Uhr

      @Don: Wahrscheinlich ein wenig von beidem ;)


    • kostaki
      am 25. August 2010 um 14:28 Uhr

      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 ).


    • tk
      am 25. August 2010 um 18:31 Uhr

      @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.


    • SITS
      am 26. August 2010 um 11:47 Uhr

      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…

    RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

    Hinterlasse einen Kommentar

    Werbung
    PHP Magazin
    Ausgabe 02/2010

    Dieses Mal mit Artikeln zu den Themen OpenSocial und Apache Shindig, Graphentheorie, Smarty3

    t3n
    Ausgabe 19

    Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...

    PHP Journal
    Ausgabe 2/2010

    PHP & Windows optimal nutzen, die besten PHP-CMS im Überblick, Google-API mit Zend Framework nutzen.

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.