Projektmanagement

[Bashar]

Ich würde nicht allzuviel Energie auf das komplette Neuschreiben verwenden. Wie Marcus schon sagte, auch wenn der Code noch so scheiße aussieht, die Autoren werden ja keine kompletten Idioten gewesen sein ... wenn ihr irgendwann was neues habt, ist überhaupt nicht gesagt, dass es auch besser ist. Ich steh oder stand grade selbst in einer solchen Situation, und finde den Artikel hier ziemlich augenöffnend:
http://www.joelonsoftware.com/articles/fog0000000069.html

They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

[Harrison Bergeron]

Vielleicht kommt ihr mit Refactoring weiter. In dem Buch von Martin Fowler werden Wege aufgezeigt vorhandenen Code, der zwar funktioniert, aber schlecht entworfen ist, zu verbessern.

Mir hat das Buch bei einem ähnlichen Problem sehr geholfen.

[ Dieser Beitrag wurde am 02.07.2003 um 10:36 Uhr von Harrison Bergeron editiert. ]

[Artchi]

Das der Chef/Kunde alles so schnell wie möglich fertig haben will, ist normal. Davon würde ich mich nicht beeindrucken lassen. Wenn er eine Anforderung hat, dann reagiert umgehend und sagt "Heute wird das nichts!". Ihr müsst mit eurem Chef REDEN, das ist ganz wichtig. Auch wenn man als Berufsanfänger denkt "Wie wird er wohl reagieren? Nein, das kann ich nicht..." Doch, traut euch! Solange ihr das in einem anständigen und verständlichen Ton sagt, wird er es akzeptieren. Wenn er nachfragt, warum, dann erklärt ihm das.

Vorallem würde ich ihn darüber aufklären, wie der aktuelle Stand ist. Nämlich das alles ein Flickwerk ist. Er selbst sieht vielleicht das ganze nur aus der Sicht des Users und nicht des Coders. Wie soll er also wissen mit was ihr euch da rumplagt?

[Marc++us]

Natürlich hast Du recht, daß man dem Chef die Situation erklären muß.

Aber gerade bei einem Chef, der technisch nicht so drin ist, besteht hier die Möglichkeit wunderbar in die von Bashar angesprochene Falle reinzulaufen:

- Engagierter Entwickler überzeugt Chef von Notwendigkeit des Redesigns
- Chef nickt ab
- Engagierter Entwickler stolpert über die von mir angesprochene Eisbergfalle
- Projekt scheitert
- Chef glaubt nie mehr was

Das komplette Redesign ist eine Hop-oder-Top-Strategie ohne Zwischenziele. Maximaler Gewinn, höchstes Risiko. Langer Weg im Dunklen und dann erst kommt das Licht.

Womit wir übrigens beim Fixing von solch altem Code auch sehr gute Erfahrung gemacht haben ist Pair-Programming. Zwei Leute, die gleichzeitig den alten Code analysieren und erweitern. Hat vor allem unter extremen Zeitdruck zu sehr guten Ergebnissen geführt.

Ich denke mal einige der hier vorliegenden Fallstricke sind sehr schön in http://www.c-plusplus.net/titelanzeige.php?ISBN=3827317096 angesprochen. Shade, da solltest Du gerade mal in Deiner Projekt- und Personallage (2 Leute) reinsehen, könnte wertvoll sein.

[HumeSikkins]

Vielleicht kommt ihr mit Refactoring weiter

So hört sich die Beschreibung für mich nicht an. Refactoring ist nur sicher möglich, wenn man sehr gute Unit-Tests hat.

Ein Satz wie:

letztens haben wir einen Bug entdeckt, der eigentlich schon mal gefixt war.

deutet aber darauf hin, dass es keine Unit-Tests in einer derartigen Qualität gibt.

Das wäre also etwas, was ich auf jeden Fall Stück für Stück ändern würde. Ganz wichtig dabei auch: Unit-Tests für bereits gefundene Bugs. So das immer geprüft werden kann, ob ein Bug nicht heimlich wieder reingekrabbelt ist.
Aber Achtung: ich habe nur theoretisches Wissen, keine praktischen Erfahrungen.

[Harrison Bergeron]

Original erstellt von HumeSikkins:
Refactoring ist nur sicher möglich, wenn man sehr gute Unit-Tests hat.

Ist richtig. Die Unit-Tests würden dann während der Refaktorisierung für die jeweiligen Komponenten geschrieben werden. Ich denke es lohnt sich Refactoring zumindest in Betracht zu ziehen.

[Gerard]

Original erstellt von Bashar:
**http://www.joelonsoftware.com/articles/fog0000000069.html
**

und was ist mit der win2000 story?

ahja und dann habe ich noch eine idee, wie wäre es wenn man seine komentare als sprachaufzeichnung speichern würde?

[Shade Of Mine]

danke fuer eure Antworten.

Wir haben heute PHPDocumentor (das PHP aequivalent zu Doxygen) in Betrieb genommen um ne halbwegs ordentliche Doku zu bekommen.

Unser Chef hat das OK gegeben dass wir eine gewisse zeit mit source code verbesserung verbringen duerfen. allerdings hat er klar gestellt dass mindestens 70% der Entwicklerzeit fuer seine todolisten aufgebracht wird.

er will sich das mal anschauen wie weit es das bringt. also muessen wir uns ranhalten

Neuschreiben kommt nicht in Frage - da gibts garantiert kein OK vom Chef - und wir wollen uns das auch nicht antun. denn das system laeuft endlich stabil!

@Marc++us:
Extreme Programming - Das Manifest
habe ich schon gelesen - und es hat uns auch viel gebracht, allerdings suche ich momentan n buch das sich mehr mit den grundlagen beschaeftigt. wie schreibt man Unit-Tests, etc.

Ein grosses Problem das unser Projekt hat, ist naemlich dass es _sehr_ komplex ist und es zuviele optionen und verschiedene user berechtigungen etc. So dass wir nie alles testen koennen

Unit-Tests waeren da interessant, doch wie schreibt man Unit-Tests fuer n Programm mit GUI?

Man darf auch bei altem Code der angesprochenen Art nicht vergessen: eine Funktion vereinbart eine Schnittstelle - es geht was rein, es geht was raus. Solange man dies sicherstellt, hat man im Inneren alle Freiheiten.

leider haengen im kern unseres projektes alle funktionen ueber globale variablen zusammen.

gibt es da irgendwelche ansaetze dies zu eliminieren?
wir verwalten globale variablen zwar nicht mehr global, sondern haben sie mit gettern und settern ausgestatt (sie stecken in einem globalen array auf das man mittels getter und setter zugreift, es gibt kein 'global $value' mehr, sondern nur noch get_globale_varibale("section","value"), ueber diese sektionen haben wir die globalen variabeln aufgeteilt, aber prinzipiell haben sich dadurch leider keine grossen erfloge eingestellt :() - kann man da irgendwie einen schritt weiter gehen?

groesstenteils sind ja wir an dem chaos schuld, aber anscheinend lernt man nur aus fehlern

[Marc++us]

Original erstellt von Shade Of Mine:
**leider haengen im kern unseres projektes alle funktionen ueber globale variablen zusammen.

gibt es da irgendwelche ansaetze dies zu eliminieren?
**

*lol*

Kenne ich. Eines der Programme legt ein Array aus structs mit zur Laufzeit 48 MB Daten an. Da sind sämtliche Zustände drin enthalten.

Unsere Vorgehensweise lief ähnlich ab, das globale Zeugs in Singletons zu packen, diese in C-Aufrufe zu wrappen und dann erst mal definierte Schnittstellen zu haben. Über die Fehlermeldungen beim Compilieren konnt man so erstmalig entdecken, wer worauf zugreift. Für die Struktur hat's auch nix gebracht, war nur gut für das Verständnis. :o

Weil viele neue Sachen muß man weiterhin in diese Struktur dazu packen. Nur einige Randfunktionen konnte man ganz neu "modern" aufbauen.

Die Sache mit den Unit-Tests kannst Du für solche Dinge übrigens haken, weil die Funktionen immer auf den kompletten Datenbestand gehen... das kannst Du separat gar nicht testen.

Und noch was: verschwendet nicht zu viel Zeit auf die Doku. Wenn ich das richtig verstehe, wollt Ihr jetzt eine Kommentar-Doku machen, damit Ihr bei den nächsten Änderungen es leichter habt. Erscheint mir ungeschickt. Ich würde mir etwas rausnehmen, das ich ändern will, und diesen Pfad im Programm analysieren und kommentieren. Aber nur diesen, und Kommentare nur entlang des Analysepfads im Rahmen der Änderung. Denn der andere Ansatz ist frustrierend, und sobald Du Änderungen machst wirst Du feststellen, daß die Kommentare nicht genau und exakt genug waren. Kommentiere dort, wo Du arbeitest. Das andere bläßt nur noch mehr Luft in die Ruine.

Aber zum Trost: mit so einer Kommentarvorgehensweise habe ich 1997 auch mal 4 Wochen Zeit verloren, die mir nachher bei Änderungen doch nichts brachten.

[Harrison Bergeron]

Original erstellt von Shade Of Mine:
**wie schreibt man Unit-Tests, etc.

(...)

Unit-Tests waeren da interessant, doch wie schreibt man Unit-Tests fuer n Programm mit GUI?
**

Test Driven Development by Example von Kent Beck
als Draft: http://groups.yahoo.com/group/testdrivendevelopment/files/

Im CppUnit-Paket sind mehrere Beispielprojekte und auch ein Tutorial drin: http://cppunit.sourceforge.net/ http://cppunit.sourceforge.net/cppunit_cookbook.html#cppunit_cookbook

Testen von Programmen mit GUI sollte kein Problem sein. CppUnit bietet sog. TestRunner für MFC, Qt und Konsole, ist aber prinzipiell unabhängig von der GUI.

[Shade Of Mine]

@Harrison Bergeron:
das ist aber n PHP Projekt - aber trotzdem danke fuer die links, da laesst sich sicher viel lernen!

@Marc++us:
danke!
wir werden uns daran halten.

[Harrison Bergeron]

Original erstellt von Shade Of Mine:
@Harrison Bergeron:
das ist aber n PHP Projekt - aber trotzdem danke fuer die links, da laesst sich sicher viel lernen!

Pardon, hab ich überlesen. Macht aber nichts. Testing Frameworks gibt es mittlerweile für die meisten Sprachen.
http://sourceforge.net/projects/phpunit/

[Marc++us]

Mir ist nicht ganz klar, wieso Du so auf den Unit-Tests rumreitest.

Die funktionieren doch nur, wenn die Testvektoren bekannt sind, und das Projekt unterteilt ist.

Bei einem wie von Shade beschriebenen Projekt sind weder Testvektoren bekannt (wenn's nicht mal Kommentare gibt...) noch ist das Projekt so zergliedert, daß es für die Tests vorbereitet ist.

Diese Monsterprojekte mit riesigen globalen Variablensätzen sind gerade der worst case für Unit Tests, da man alles initialisieren muß um auch nur Teile zu testen.

[Harrison Bergeron]

Tut mir leid, dass es sich nach drei Postings schon nach "rumreiten" anhört. Ich wollte nur eine Möglichkeit aufzeigen. Und da ich ihm unter einer falschen Annahme den Link zu CppUnit gepostet habe, wollte ich nochmal auf das PHP-Framework hinweisen. Nur der Vollständigkeit zuliebe.

Ob Refactoring bzw. Unit-Testing das richtige Mittel für dieses Projekt ist kann ich nicht beurteilen. Du bist offensichtlich sehr sicher, dass es nicht sinnvoll ist. Wahrscheinlich fehlt mir einfach deine Erfahrung (oder Informationen) für eine Ferndiagnose.

Ich habe bei einem ähnlichen Problem gute Erfahrungen damit gemacht und wollte das einfach weitergeben. Zugegeben, ich bin sogar etwas begeistert davon Deswegen reite ich so darauf rum.

Was meinst du genau mit Testvektoren?

[Marc++us]

Für die Unit-Tests hast Du doch auch Eingabemengen bzw. Wertebereiche, also eine Datenbasis für den Test [bei so großen Datenmengen kannst Du ja nicht alle Werte und Varianten vollständig kombinieren]. Das meinte ich mit den Testvektoren.

Normal kennst Du eine Menge an Datenvektoren für den Test einer Funktion, und wenn eine andere Implementation das gleiche Ergebnis liefert ist die Funktion wohl identisch. Naja... vereinfacht gesagt. Bei solchen Monsterprogrammen ist es aber doch wegen der verworrenen Architektur und der Seiteneffekte globaler Variablen oftmals gar nicht sauber erkennbar, welche Werte zur Testmenge einer Funktion gehören.

Und man schafft es kaum, isolierte Bereich zu instanziieren und darauf Tests zu machen, weil das alles so verwachsen ist, daß man nicht an einzelne Dinge herankommt.

Ich habe (leider) solche Programme im Pflegebestand, das sind Prozeßvisualisierungsanwendungen für Maschinensteuerungen. Da laufen Funktionen teilweise wirklich auf 100 Variablen inkl. damit verbundener gewollter Seiteneffekte. Ich frage mich wie das zu isolieren wäre, daß man einen Unit-Test machen kann.