Projektmanagement

[Shade Of Mine]

Hallo Leute!

Ich habe ein paar Fragen was das handhaben von grossen Projekten betrifft.

Erstmal ne Beschreibung der Situation:
Wir sind nur 2 Programmierer, ein Freund von mir und ich (beide 18)

Mehr programmierer gibt es zwar in der Firma, aber die gehoeren zu anderen Abteilungen -> dh, hoechstens das jemand von denen aushilft wenn bei uns Not am Mann ist.

Der Kern des Projektes (eine Art Scriptsprache fuer Webanwendungen) wurde nicht von uns geschrieben. Der Code ist mies, redundant, jede Funktion hat Seiteneffekte, globale variablen en masse.

Alles was wir dazu geschrieben haben, haben wir zwar etwas besser geordnet, weniger seiteneffekte, etc. aber dennoch versteht niemand mehr den source code

Das System laeuft stabil - nach langen langen bugfixen.

Nun stellt sich uns die Frage:
lohnt es sich das system besser zu strukturieren? sollen wir uns hinsetzen und ne ordentliche doku schreiben? (unnoetig zu sagen, dass es quasi keine kommentare im source code gibt)

Bzw. fragen wir uns wie man an solche Projekte rangehen soll:
der Chef sagt: wir brauchen feature A, waere praktisch wenn du es bis heute abend schaffst.

Dann bleibt uns eigentlich keine zeit dafuer uns ein gutes konzept zu ueberlegen. Was sollen wir dann machen? Dem Chef sagen: da muessen wir erstmal ein konzept entwerfen, dauert wahrscheinlich bis uebermorgen bis das feature steht. - nur wie wird er das aufnehmen?

eine sachen sich sehr voreilig eingebaut worden, die uns momentan doch ziemlich schwer im magen liegen - feature neu implementieren oder einfach lassen (und hoffen dass wir es nicht mehr anfassen muessen)?

gibt es irgendwelche tricks wie man so einen riesigen flickenteppich vermeiden kann?

und noch ne Frage:
letztens haben wir einen Bug entdeckt, der eigentlich schon mal gefixt war.
wir haben zwar ne CVS History, aber das hat uns nix geholfen da wir nicht wussten seit wann es den bug wieder gab.
wir fanden im source code dann den bugfix (waren nur ein paar zeilen) - doch dieser fix war auskommentiert.

einer von uns beiden wird den bugfix auskommentiert haben (da sind wir uns ziemlich sicher, doch wissen wir nicht mehr wer oder warum)
unsere angst: diese bugfix hat nen neuen bug verursacht der irgendwann dadurch gefixt wurde, in dem man ihn auskommentiert hat.

wie kann man solche situationen vermeiden?

ich weiss, das sind viele Fragen
theoretisch haben wir 2 jahre lang 'Projektmanagement' in der schule gehabt, aber sowas hat uns niemand beigebracht. wir sind beide 18 und es ist unser erstes wirklich grosses (und professionelles) projekt. am programmieren haperts ja nicht, da sind wir gut genug, aber am drum herum verzweifeln wir manchmal.

es gibt auch keine wirkliche ansprechperson die sich mit der materie von diesem projekt gut genug auskennt - die firmen philosohie ist naemlich immer nur junge, freie mitarbeiter zu beschaeftigen (und die gehen dann irgendwann weg)

[junix]

Naja grundsätzlich würd ich in der Situation mal mit dem chef besprechen, was man machen könnte. Präsentier ihm das Problem, eine Lösung und eine Aufwandsabschätzung für ne Lösung. Konstruier vielleicht auch noch ne alternative welche eine "fliessende Lösung" ermöglicht (schreib ich gleich unten mehr dazu).

Die sauberste Lösung wird sicher sein, das ganze von grund auf neu zu konzipieren und entsprechend zu implementieren. Dies braucht allerdings ZEit und da ihr ja das "Tagesgeschäft" nicht einfach stillegen könnt, wird diese Lösung vermutlich ins HIntertreffen geraten.

Was eine - in meinen Augen - elegante Lösung darstellt, ist eine schrittweise Migration: Zunächst wird ein Konzept erarbeitet, wie man den neuen Aufbau haben möchte, und wie man die alten Teile einbinden will. Neues wird nun nach den neuen Richtlinien implementiert und wenn immer Hand an einige Teile des alten Codes gelegt werden müssen, wird dieser migriert und überarbeitet. Das geht solange, bis der alte Code weg ist und man das "Klammergebilde" mit dem man den alten Code eingebunden hatte, entfernen kann.

Nur so eine THeorie die du dir vielleicht durch den Kopf laufen lassen kannst.

Was du aber auf jeden Fall machen solltest, ist deinen Chef mit dem Problem aufzusuchen. Vorzugsweise allerdings, wenn du Lösugnsvorschläge in der Pfanne hast. Sie müssen nicht ausgereift sein, einfach Ideen. Präsentiere ihm diese, dann kann er die Strategie festlegen und sich entscheiden, welchen Ansatz man verfolgt. Vielleicht verlangt er auch, dass man genauere Aufwandsabschätzungen macht für alle Lösungen, aufgrund derer er dann diese Entscheidung fällen kann. Da es sich allerdings in meinen Augen hier klar um eine strategische Entscheidung handelt, würde ich den Chef auf keinen Fall aussen vor lassen.

-junix

[virtuell Realisticer]

Hmmm...woher kenn ich deine Situation...ahja, mir geht es naemlich _genau_so
wie dir!

Ich soll ein vorhandenes Programm umschreiben (DOS -> Win). Mindestens 85% - 90%
unkommentiert.

Also, wie ich es im Moment mache: (keine direkte Hilfe, aber vielleicht hilft
es dir doch ein wenig weiter)

ohnt es sich das system besser zu strukturieren? sollen wir uns hinsetzen und ne
ordentliche doku schreiben? (unnoetig zu sagen, dass es quasi keine kommentare
im source code gibt)

Dokumentation ist lebenswichtig!!!! Ich nutze jetzt auf der Arbeit Doxygen und
versuche alles ein wenig zu dokumentieren, auch aeltere Funktionen.
Das nimmt viel Zeit weg und man sollte anfangs darauf achten, zumindest
alles _neue_ zu dokumentieren (aeltere dinge dann, wenn man grad etwas daran
machen muss). Wenn du das ne Zeitlang durchhaelst und anfaengst auch aelteres
zu dokumentieren, wirst du vielleicht sogar schon in ein paar Wochen sehr sehr
froh darueber sein. Du wirst es garantiert nicht bereuen.

Bzw. fragen wir uns wie man an solche Projekte rangehen soll:
der Chef sagt: wir brauchen feature A, waere praktisch wenn du es bis heute
abend schaffst.

Dann bleibt uns eigentlich keine zeit dafuer uns ein gutes konzept zu
ueberlegen. Was sollen wir dann machen? Dem Chef sagen: da muessen wir erstmal
ein konzept entwerfen, dauert wahrscheinlich bis uebermorgen bis das feature
steht. - nur wie wird er das aufnehmen?

Mein Chef draengt mich auch, dass ich doch endlich etwas mehr zeigen soll,
aber er muss sich damit abfinden, dass ich nicht Gott bin. Zum glueck bist
du nicht allein, hab zwar en Ausbilder, der macht aber mehr Support fuer die
alte Version und ich programmiere im Moment alleine an unserem Programm.

gibt es irgendwelche tricks wie man so einen riesigen flickenteppich vermeiden
kann?

Dazu kann ich leider keine Tipps geben. Wie willst du sowas vermeiden, wenn es
teilweise schon vorhanden ist?

letztens haben wir einen Bug entdeckt, der eigentlich schon mal gefixt war.
wir haben zwar ne CVS History, aber das hat uns nix geholfen da wir nicht
wussten seit wann es den bug wieder gab.
wir fanden im source code dann den bugfix (waren nur ein paar zeilen) - doch
dieser fix war auskommentiert.

einer von uns beiden wird den bugfix auskommentiert haben (da sind wir uns
ziemlich sicher, doch wissen wir nicht mehr wer oder warum)
unsere angst: diese bugfix hat nen neuen bug verursacht der irgendwann dadurch
gefixt wurde, in dem man ihn auskommentiert hat.

wie kann man solche situationen vermeiden?

Nutzt ihr kein RCS? Waere vielleicht hilfreich, denn dann kann man die
Kommentare durchgehen und evtl. sehen, warum wer was zu welchem Zeitpunkt
geaendert hat (natuerlich nur in Stichpunkten)

Mehr kann ich dazu im Moment leider nicht sagen, hoffe ich konnte dir ein
wenig weiterhelfen. Das is ne bloede Situation, in der du dich befindest,
leider muss ich sagen, dass ich diese Situation auch kenne, da ich mich
ebenfalls in einer solchen befinde.

Vielleicht kann man sich ja mal des oeffteren austauschen

mfg
v R

[Shade Of Mine]

Original erstellt von virtuell Realisticer:
Nutzt ihr kein RCS? Waere vielleicht hilfreich, denn dann kann man die
Kommentare durchgehen und evtl. sehen, warum wer was zu welchem Zeitpunkt
geaendert hat (natuerlich nur in Stichpunkten)

Wir haben CVS im Einsatz, aber unsere Kommentare sind alle entweder
bugfix
kleinigkeit
...

also sinnlos.
ja, natuerlich sind wir selber schuld, aber am ende vom tag wissen wir halt nichtmehr was wir wo gemacht haben

sollten wir lieber jede aenderung sofort commiten? waere das besser? auch wenn man nachher dann noch nen bug findet und ein file dann halt 5 mal hintereinander commiten muss?

ansonsten ist es schoen zu hoeren, dass wir nicht alleine zu bloed fuer sowas sind :p

[Shade Of Mine]

Original erstellt von junix:
Da es sich allerdings in meinen Augen hier klar um eine strategische Entscheidung handelt, würde ich den Chef auf keinen Fall aussen vor lassen.

unser Chef ist eher der meinung, dass etwas weiter gehen soll
die kunden zahlen nicht schlecht dafuer, und es gibt wuensche fuer features, dass wir fuer jahrhunderte genug zu tun haben.

klar werden wir es mit unserem chef besprechen, aber erst wenn wir wissen was wir wollen (bzw. was ihr sagt was wir sollen)

denn von uns hat ja keiner ne ahnung

[junix]

Mir fällt grad auf ich hab da nur auf einen Aspekt geantwortet... Noch einige Kommentare zum Rest:

Es ist wie vR sagt: Nur wenn man etwas sauber konzipiert, vermeidet man den Murks. Wenn dein Chef also drängt, leg ihm dar, wieso du erst eine Konzeptphase brauchst. Vielleicht beziehst du ihn intensiver in den Entwicklungsablauf ein, indem du ihm mehr feedback gibst, wo du grad stehst. Stell ihn vor die einfache Wahl: Clean and (almost) Bugfree oder Quick and Dirty. ist ne Milchbüchchenrechnung: Je länger du vor dich her wurschtelst und dann ncohmals hundert fehler suchen musst, desto teurer wirds für ihn. Die Erfahrung zeigt, dass die Zeit welche man bei einem Q&D-Hack für die Fehlersuche aufwendet übersteigt meist die ZEit welche man für ein Konzept eingesetzt hätte.
Konzept heisst auch nicht immer 10 Tage Konzeptierungsphase, sondern kann eine Skizze bedeuten, ein Struktogramm. Es ist im Prinzip eine etwas verlängerte Phase des Nachdenkens vor der IMplementation.
"Any idiot can write code!" Der Unterschied zwischen Softwareentwicklung und Programmieren ist der, dass man bei der Softwareentwicklung nicht nur aufs Codieren lossteuert, sondern eben erst mal konzipiert und mal Abläufe durchspielt um zu sehen ob das überhaupt geht wie mans wollte.

Was die Doku betrifft, so stimme ich auch mit vR überein: Lebenswichtig! Wenn du dich über eine Funktion im alten Code schlau machen musstest, dann schreib dir deine Erkenntnisse auf. Wir hatten hier doch schonmal nen Thread von Winzler glaub ich, in dem die Frage wie man sich in ein fremdes Projekt einarbeitet gestellt wurde. Da hab ich schonmal was dazu geschrieben. Auch hier wieder: Die Zeit die du reinsteckst ist Initialaufwand und wird von mal zu mal kürzer. Ansonsten macht du den Schritt "Einarbeiten" mehrfach. Das ist frustrierend und auch nicht wirtschaftlich.

Mit einer verbesserten Dokumentation würden dann auch solche Probleme wie das Entfernen von Bugfixes und so weiter minimiert. Was du schilderst deutet definitv auf ein zu schlecht dokumentiertes Projekt hin.

Richtzeit für Doku ist (bei uns zumindest) etwa 20-25% des gesamtaufwands. Du siehst also wie die Doku gewichtet wird. Und bisher hat das noch niemand bereut. Klar, Zeit ist Geld, aber ich denke, dass ja auch nicht features schlag auf schlag und tag auf tag implementiert werden müssen? Nutze die "Pausen dazwischen" für einen Cleanup im (Teil-)Projekt. Reserviere dir die Zeit schon vorab, wenn du das Feature auf die Liste nimmst. Es müsste eigentlich auch hier jeder ein Einsehen haben.

-junix

[virtuell Realisticer]

sollten wir lieber jede aenderung sofort commiten? waere das besser? auch wenn man
nachher dann noch nen bug findet und ein file dann halt 5 mal hintereinander
commiten muss?

Also in meinem Projekt (umschreiben unserer Software) setze ich _noch_ kein RCS
aus folgendem Grund ein: Da ich den Aufbau teilweise neu strukturiere, bin ich
im moment _sehr_ viel in den Dateien kreuz und quer unterwegs. Wenn ich dann
eine Basis habe, von der man sagen, kann, es laeuft jetzt mehr oder weniger,
werde ich dann anfangen RCS einzusetzen, da man ansonsten, wie von dir
angedeutet, sehr viel kommentieren wuerde.

Aber ihr koennt es doch einfach mal ausprobieren (ne Woche) und dann schauen,
wieviel ihr wirklich Kommentare schreibt (saetze werden ja nur in Stichworten
geschrieben, sonst wird es wirklich zuviel). Wenn es wirklich viel zu viel wird,
muesste man sich was anderes einfallen lassen.

mfg
v R

[junix]

Original erstellt von Shade Of Mine:
unser Chef ist eher der meinung, dass etwas weiter gehen soll

Wie les ich da so schön zwischen den Zeilen? "So kanns nicht weitergehen"? (o;

Ne im Ernst. Machs mal wie ichs oben beschrieben habe. Geh zum chef mit den Worten "So gehts nimma, wir verplempern wichtige Zeit für das alte System, die wir uns mit einem Redesign sparen könnten. Die klare Folge: Schnelleres implementieren der Features da übersichtlicher... bla text schwätz plauder".

Wenns wirklich so katastrophal ist wie du sagst, dann muss unbedingt ein Redesign her... ... und wie oben gesagt. Die Priorität der Doku muss bei euch klar erhöht werden.

-junix

[junix]

Original erstellt von Shade Of Mine:
ja, natuerlich sind wir selber schuld, aber am ende vom tag wissen wir halt nichtmehr was wir wo gemacht haben

Dann macht euch notizen. Du hast ja das Problem offensichtlich erkannt. Jetzt ist der nächste Schritt eine Lösung auszuarbeiten. Beschreib hald den Bugfix den du gemacht hast etwas detailierter. Wenn du etwas rausschmeisst um den Bug zu fixen, schreib ne Zusatzzeile mit wieso und warum. Wenn du ne Änderung einfügst, dann mach ne Zusatzzeile mit was und weshalb. Jeweils mit Datum, Uhrzeit und verantwortlichem (sprich wers war)... Und schreib in die Metadaten von den Sourcen was vernünftiges. Dazu sind die Metadaten da...

-junix

[Marc++us]

Hauptprobleme beim Vorschlag eines kompletten Austauschs der Software sind:

a) die Totzeit
b) erneute Testphase
c) fehlendes Pflichtenheft und das Eisbergproblem

zu a)

In der Zwischenzeit gibt es kein lauffähiges System - angenommen Änderungen sind notwendig, das neue System ist noch nicht fertig, muß das alte dann doch weiter geändert werden? Wer macht das?

zu b)

Wenn das Ersatzsystem fertig ist, wird es lustigerweise trotzdem nicht auf die gleiche Zuverlässigkeit kommen wie das alte System, bis die Testphase durchlaufen ist. Kann dieser Einbruch in der Verfügbarkeit akzeptiert werden?

zu c)

In bestehenden mehrfach gefixten Systemen liegt das Problem versteckt, daß dort oftmals Erfahrungswissen für das System eingepflegt wurde, das nirgendwo (auch nicht im Plichtenheft) erfasst wurde. Da das System nicht dokumentiert ist, gibt es auch keine Möglichkeit das schnell zu sehen. Auf dieses versteckte Wissen stößt man erst, wenn das Ersatzsystem entwickelt wird und man plötzlich gewisse Abweichungen vom alten System bemerkt. Dann kommen dann solche Dinge wie "oha, hatte sich dabei doch was gedacht". Dies führt zu allerhand Verzögerungen und wirft Terminpläne leicht um.

Firmenpolitisch besteht das Problem, daß sich schleichende Wartungskosten - obwohl höher - im Regelfall besser verkaufen lassen als Redesigns. Hier wird ein großer Block auf einmal fällig, der nicht ins Konzept paßt. Jeden Monat aber einige 1000 EUR bereit stellen fällt oftmals leichter gemäß "das muß halt sein". Für die Arbeitszeit des Bugfixens wird immer Geld da sein, da dies dann unter Kundendruck geschieht. Für das Redesign gibt's keinen Kundendruck, sondern nur interne organisatorische Gründe und das Argument, daß man dadurch mittelfristig Geld spart. Dies ist aber sehr schwer beweisbar, falls die Firma dieses Erfahrungswissen nicht besitzt.

Die Weichen sind also für ein komplettes Redesign schlecht gestellt.

Solche Projekte gibt's in jeder Firma... wir haben einige C-Leichen, die über Jahre portiert und "gepflegt" wurden auch immer noch im Regal stehen. Der Grundansatz war hierbei immer der, daß versucht wurde im alten Programm "Cluster" zu erkennen, also zusammen gehörende Funktions- oder Modulblöcke. Bei notwendigen Änderungen haben wir dann neue Funktionen implementiert, indem wir die Sachen in C++ realisiert und C-Wrapper für die Klassen bauten. Auf ähnliche Art und Weise haben wir einen Teil der beliebten globalen Strukturen eliminiert, so daß man auch ordentlich debuggen konnte. Weiterhin war hilfreich, Tracemöglichkeiten in das Programm einzubauen, so daß man ein Protokoll über den Programmlauf erhält. Im Fehlerfalle war man nicht mehr so blind. 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.

[Gerard]

implementier doch etwas und erst danach kanns du es redesignen, (nicht das komplete system)

zu den bugfix:
als ihr ihn auskommentiert habt hättet ihr euch schon denken können das ihr in zukunft damit nix anzufangen weist, schreibe das nähste mal wenigstens ein paar stichworte hin
oder lösche den kommentar (ich wette der code ist voll von aukommentierten sachen)
wenn ihr code auskommentiert dann verpasst den ding ein verfals datum, jeden morgen startet ihr dann so ein programm das euch die alten eier raussucht und falls ihr euer ok gebt es irgend wo archiviert

[ Dieser Beitrag wurde am 02.07.2003 um 08:17 Uhr von Dimah editiert. ]

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