Projektmanagement
-
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.
-
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?
-
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
-
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.
-
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.
-
@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.
-
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/
-
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.
-
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?
-
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.