Hallo
Unsere Zweigstelle soll ein Softwareprojekt, welches eine andere
Zweigstelle durchgeführt hat übernehmen und gewisse Änderungen /
Verbesserungen durchführen.
Es handelt sich um embedded C Code (16Bit Mikrocontroller) für ein
Steuergerät. Ca. 15.000 Zeilen Code... Benutzt werden viel Pointer...
Ein Bekannter von mir hat inoffiziell mal über den Code geschaut und
meinte das das schon alles recht kompliziert ist... einiges auch
umständlich... Er rät sogar den Originalcode zu vergessen und alles neu
zu schreiben.. seiner Meinung nach wäre das schneller...
Die Reihenfolge ist ein wenig seltsam da wir zur Zeit noch gar keine
Programmierer haben. Diese (zwei) werden jedoch gerade gesucht.
Ich selber habe nicht viel Ahnung von Software, Programmierung usw. soll
jedoch sicherstellen das das Projekt ausreichend dokumentiert ist und
die Programmierer relativ zügig loslegen können.
Ich hab schon bei der Zweigstelle ein wenig nachgefragt und deren
Antwort ist mehr oder weniger ... schau doch einfach im Quellcode... Ich
kann die Jungs ein wenig verstehen... die sind auch nicht wirklich
glücklich mit dem was das Management da bestimmt hat.
Was würdet ihr in so einem Fall erwarten (Dokumentation, usw.) und
speziell beachten?
LG
>Er rät sogar den Originalcode zu vergessen und alles neu>zu schreiben.. seiner Meinung nach wäre das schneller...
Das sagt jeder, der ich kenne, wenn man ihm Software im Quellcode
vorliegt.
In 50% der Fälle macht man das dann.
In 10% wäre es wirklich notwenig gewesen.
Wichtig ist doch, dass die Software richtig übergeben wird. Dass sich
beide mal ein paar Stunden zusammensetzen und der Aufbau besprochen
wird. Geht besser als Dokumente durchzulesen.
Als Entwickler würde ich erwarten:
- Source muss kompilierbar sein
- Dokumentation muss vorhanden sein
- darf keine bekannten Bugs haben resp. müssen gefixt werden vorher
- Entwicklungsumgebung muss sichergestellt sein
- Repository muss eingerichten sein (von euch)
- Testsystem muss vorhanden sein
so, das auf die Schnelle...
Grüsse,
René
Softworker schrieb:> Wichtig ist doch, dass die Software richtig übergeben wird.
… und dass die Leute hinterher für Rückfragen verfügbar sind. Die
kommen erfahrungsgemäß garantiert irgendwann.
Ansonsten kann man nur sehen, ob der Code zumindest sinnvoll
kommentiert worden ist, also nicht so:
1
zaehler++;/* zaehler hochzählen */
sondern so:
1
/*
2
* Diese Funktion bekommt ein mumble als Eingabe, verarbeitet es
3
* entsprechend dem Algorithmus aus Meyer: Kleines Einmaleins, S. 25,
4
* und gibt das Ergebnis in foobar zurück, der auf ein Feld von
5
* hmptzig 32-bit-Ganzzahlen zeigen muss.
6
*
7
* Als Hilfsfunktion wird dooboo() aufgerufen, globale Variablen
8
* werden nicht geändert.
9
*
10
* Ein Rückkehrwert von 0 bedeutet Erfolg, andernfalls waren Fehler
Jörg Wunsch schrieb:> sondern so:
Wobei ich das dann aber im Doxygen-Format bevorzugen würde, so daß man
sich aus dem Code eine verfünftige Doxygen-Doku erzeugen lassen kann.
Dann braucht man auch solche Aussagen nicht:
> * Als Hilfsfunktion wird dooboo() aufgerufen, globale Variablen> * werden nicht geändert.
Die werden nämlich eh von Doxygen schon erzeugt.
Generell würde ich, wenn ich fremden Code übernehmen soll, erstmal
doxygen mit sätmlichen Optionen eingeschaltet darüber laufen lassen.
Rene H. schrieb:> Als Entwickler würde ich erwarten:>> - Source muss kompilierbar sein> - Dokumentation muss vorhanden sein> - darf keine bekannten Bugs haben resp. müssen gefixt werden vorher> - Entwicklungsumgebung muss sichergestellt sein> - Repository muss eingerichten sein (von euch)> - Testsystem muss vorhanden sein>> so, das auf die Schnelle...
Auf sowas würde ich in meinen kühnsten Träumen hoffen. Erwarten würde
ich es nicht.
Jörg Wunsch schrieb:> * Als Hilfsfunktion wird dooboo() aufgerufen, globale Variablen> * werden nicht geändert.
wer soll denn so etwas pflegen? Was ist wenn dooboo eine globale
Variabel ändert. Oder die hilftsfunktion foo() die in dooboo()
aufgerufen wird?
Rolf Magnus schrieb:> Wobei ich das dann aber im Doxygen-Format bevorzugen würde
Das ist natürlich nice to have, keine Frage.
Peter II schrieb:> wer soll denn so etwas pflegen?
Das gehört für mich zu einer ordentlichen Softwareentwicklung
dazu. Ist auf jeden Fall viel sinnvoller als zeilenweise einzelne
Kommentare, die völlig offensichtliche Dinge „dokumentieren“.
Jörg Wunsch schrieb:>> wer soll denn so etwas pflegen?>> Das gehört für mich zu einer ordentlichen Softwareentwicklung> dazu. Ist auf jeden Fall viel sinnvoller als zeilenweise einzelne> Kommentare, die völlig offensichtliche Dinge „dokumentieren“.
aber doch bitte nicht so etwas wie Unterfunktionen. Das Hilft niemand
und man müsste es bis in die unter-unter-unter funktion durchziehen. Und
wenn man dann etwas in einer zentralen Unterfunktion ändert dann muss
man also doku Texte anpassen?
Nein ich bin dagegen, Doku ja, aber nicht so.
Kid Rock schrieb:> Hallo>> Unsere Zweigstelle soll ein Softwareprojekt, welches eine andere> Zweigstelle durchgeführt hat übernehmen und gewisse Änderungen /> Verbesserungen durchführen.>
das klingt nach: das Gerät funktioniert bereits --> ist doch super.
> Es handelt sich um embedded C Code (16Bit Mikrocontroller) für ein> Steuergerät. Ca. 15.000 Zeilen Code... Benutzt werden viel Pointer...> Ein Bekannter von mir hat inoffiziell mal über den Code geschaut und> meinte das das schon alles recht kompliziert ist... einiges auch> umständlich... Er rät sogar den Originalcode zu vergessen und alles neu> zu schreiben.. seiner Meinung nach wäre das schneller...>
Das wird dir vermutlich jeder erfahrene Softwareentwickler raten. Diesen
habt ihr aber noch gar nicht.
> Die Reihenfolge ist ein wenig seltsam da wir zur Zeit noch gar keine> Programmierer haben. Diese (zwei) werden jedoch gerade gesucht.> Ich selber habe nicht viel Ahnung von Software, Programmierung usw. soll> jedoch sicherstellen das das Projekt ausreichend dokumentiert ist und> die Programmierer relativ zügig loslegen können.>
Das ist ganz normal. Es wird davon ausgegangen, dass bei genügender
Dokumentation einfach nahtlos weitergemacht werden kann. Selbst wenn
ausreichend Doku verhanden wäre kann nicht einfach aufgesetzt werden.
Und das hier...
> Ich hab schon bei der Zweigstelle ein wenig nachgefragt und deren> Antwort ist mehr oder weniger ... schau doch einfach im Quellcode... Ich> kann die Jungs ein wenig verstehen... die sind auch nicht wirklich> glücklich mit dem was das Management da bestimmt hat.
... sagt doch schon, dass es keine Doku gibt. Nur den QuellCode halt.
:-(
Du kannst ja mal ein "Understand"-Projekt für den Code aufsetzen, und
schauen, was es dir "erzählt" (Modulabhängigkeiten, Komplexität, etc.).
Dann siehst du vielleicht schon weiter.
Software Projekte "einfach" uebernehmen ist viel teurer als erwartet und
dauert viel laenger als erwartet. Denn man macht die Arbeit eigentlich
nochmals.
Jörg Wunsch schrieb:> Rolf Magnus schrieb:>> Wobei ich das dann aber im Doxygen-Format bevorzugen würde>> Das ist natürlich nice to have, keine Frage.
Doxygen oder was vergleichbares ist für mich nicht nur nice to have.
Peter II schrieb:> Jörg Wunsch schrieb:>>> wer soll denn so etwas pflegen?>>>> Das gehört für mich zu einer ordentlichen Softwareentwicklung>> dazu. Ist auf jeden Fall viel sinnvoller als zeilenweise einzelne>> Kommentare, die völlig offensichtliche Dinge „dokumentieren“.
Das mit Sicherheit. Generell sollte man "inline" nicht dokumentieren,
was_ der Code tut oder _wie er es tut, sondern warum er gerade das
tun soll, bzw. warum er so geschrieben ist, sofern sich das nicht von
selbst ergibt.
> aber doch bitte nicht so etwas wie Unterfunktionen.
Wie gesagt erstellt einem Doxygen sowas schon automatisch. Dann auch mit
einer Liste von Funktionen und Variablen, die die Funktion nutzt und
graphischem Calltree und Verlinkung. Das ist durchaus hilfreich, wenn
man sich da immer schön weiterklicken kann. Und da es automatisch
generiert ist, kann man sich diese Doku jederzeit aus den aktuellen
Sourcen erzeugen, so daß nix veraltet ist und keiner das explizit
pflegen muss.
Meiner Meinung nach kann man auch zuviel kommentieren. Bevor man einen
inline-Kommentar schreibt, sollte man sich immer erst überlegen, ob man
den Code auch so formulieren kann, daß der Kommentar überflüssig wird.
Denn irgendwer vergisst immer mal, einen Kommentar anzupassen, und ein
falscher Kommentar ist schlimmer als gar keiner.
Fremde Quelltexte zu übernehmen ist viel schwieriger, als etwas neu zu
Programmieren. Fremden Code ganz ohne Dokumentation zu übernehmen ist
erst recht aufwändig. Wenn dann die alten Entwickler nicht mehr
ansprechbar sind, wird es zum Glücksspiel.
Neu schreiben ist einfach, sofern GENAU weiß, was das Programm tun soll.
Nicht selten kann man die Kosten erst abschätzen, wenn die Übernahme
bereits so gut wie erledigt ist. Danach kann man dann die Aufwände der
gewünschten Änderungen abschätzen.
> Er rät sogar den Originalcode zu vergessen und alles neu> zu schreiben.. seiner Meinung nach wäre das schneller...
Das kenne ich, ist leider oft so - viel zu oft.
> Ich selber habe nicht viel Ahnung von Software, Programmierung usw.> soll jedoch sicherstellen das das Projekt ausreichend dokumentiert> ist und die Programmierer relativ zügig loslegen können.
Um deine Aufgabe zu erfüllen, wirst DU das Projekt übernehmen müssen.
Sonst ist ja keiner da. Danach kannst DU es an die neuen Programmierer
übergeben.
Wenn du es nicht kannst, dann sag das deinem Chef besser, bevor der
Zieltermin vorbei ist und er dann mit leeren Händen da steht. Dann ist
es womöglich besser, dass er die alten Entwickler zusammen trommelt,
damit sie die Übergabe machen.
Erstmals vielen Dank für die vielen Kommentare...
Zusammensetzen geht leider nicht... Die eine Abteilung ist in
Deutschland, wir sind in Singapur.
Ich bekomme das leider nur teilweise mit aber ein Kollege hat mir
gesteckt das der ursprüngliche Entwickler in Deutschland unsere Firma
bald verlassen wird. Noch ein negativ Punkt.
Entschuldigung ich komme von der Hardwareseite... Was ist Doxygen? Hab
ich schon mal von gehört aber noch nie gesehen...
Danke nochmals für die Kommentare
Kid Rock schrieb:> Was ist Doxygen?
Na komm, Gugel hasts du auch in Singapur. ;-)
http://www.doxygen.org/
p.s.: Man könnte auch eine Hardwareentwicklung damit dokumentieren,
VHDL zumindest steht in der Liste der unterstützten Sprachen drin. :)
if (job->getDate()!=0 && job->getDate()->toLong()>0) {
3
...
4
}
Hier scheint es so, dass der Job ausgeführt werden soll, wenn das Datum
gesetzt ist. In Wirklichkeit geht es aber in der Geschäftslogik darum,
den Job nur dann auszuführen, wenn er von der DB geladen wurde. Und aus
irgendeinem kruden Grund dient das Datum dazu, zwischen "von DB geladen"
und "nicht von DB geladen" zu unterscheiden. Sowas kommt ja leider vor,
das kann man nicht immer einfach so abändern, wie man das gerne möchte.
Besser finde ich jedoch lesbaren Code, zum Beispiel so:
@ Stefan Us (stefanus)
>Fremde Quelltexte zu übernehmen ist viel schwieriger, als etwas neu zu>Programmieren.
Jain.
> Fremden Code ganz ohne Dokumentation zu übernehmen ist>erst recht aufwändig. Wenn dann die alten Entwickler nicht mehr>ansprechbar sind, wird es zum Glücksspiel.
Es ist viel Arbeit.
>Neu schreiben ist einfach, sofern GENAU weiß, was das Programm tun soll.
Quark. Damit kann man ja mal fix immer mehrere tausend bis sowiviel
Arbeitsstunden wegschmeißen. Das ist weder ökonomisch noch praktikabel.
Denn wir reden hier nicht von kleinen 1 Mann Hobbyprojekten!
>> Er rät sogar den Originalcode zu vergessen und alles neu>> zu schreiben.. seiner Meinung nach wäre das schneller...>Das kenne ich, ist leider oft so - viel zu oft.
Tja, die Frage ist, ob es WIRKLICH gerechtfertigt ist. Denn das Syndrom
"not invented here" geht überall rum.
Ein Quelltext muss nicht immer den persönlichen Vorlieben entsprechen,
um dennoch gut zu funktionieren.
>> Ich selber habe nicht viel Ahnung von Software, Programmierung usw.>> soll jedoch sicherstellen das das Projekt ausreichend dokumentiert>> ist und die Programmierer relativ zügig loslegen können.
Tja, klingt mal wieder nach einem saftigen Managementfehler. Für so eine
Aufgabe braucht man Leute mit Erfahrung. Denn sonst muss dieser die
Erfahrung erst sammeln. Das wird teuer und zeitaufwendig!
>Wenn du es nicht kannst, dann sag das deinem Chef besser, bevor der>Zieltermin vorbei ist und er dann mit leeren Händen da steht. Dann ist>es womöglich besser, dass er die alten Entwickler zusammen trommelt,>damit sie die Übergabe machen.
GENAU!
Kid Rock schrieb:> Unsere Zweigstelle soll ein Softwareprojekt, welches eine andere> Zweigstelle durchgeführt hat übernehmen und gewisse Änderungen /> Verbesserungen durchführen.Kid Rock schrieb:> Die Reihenfolge ist ein wenig seltsam da wir zur Zeit noch gar keine> Programmierer haben. Diese (zwei) werden jedoch gerade gesucht.Kid Rock schrieb:> Ich selber habe nicht viel Ahnung von Software, Programmierung usw. soll> jedoch sicherstellen das das Projekt ausreichend dokumentiert ist und> die Programmierer relativ zügig loslegen können.
Klingt bekannt, die meisten SW Projekte schlagen fehl im Sinne "dauern
viel laenger als gedacht", "zu teuer", "die SW leistet nicht was sie
soll" etc. pp.
http://en.wikipedia.org/wiki/Death_march_%28project_management%29
Ich hab auch mal ein Projekt geerbt, von einem Kollegen, der die Firma
verlassen hat.
Ich hab zwar ne Weile gebraucht, aber ich hab erfolgreich Erweiterungen
einbauen können, ohne den Code komplett verstehen zu müssen.
Der Code mußte sogar zweimal wegen Abkündigung der CPU angepaßt werden.
15.000 Zeilen hört sich zum Glück nicht riesig an.
Ich würde darauf achten, dass es eine High-Level-Doku gibt. Also was tut
das Ding überhaupt (Use Cases), wie tut es die und wie sieht die
Architektur aus.
Dann noch ein bisschen im Code stöbern, ob an kritischen Stellen
sinnvolle Kommentare stehen und ob allgemein Benennung sinnvoll und
Coding Conventions eingehalten sind.
Neuschreiben ist spaßiger als in fremdem Code herumzuwühlen. Gerade
Programmierer fordern das schnell. Sinnvoll ist es aber nur selten, denn
warum soll der zweite Versuch so viel besser werden als der Erste. Außer
natürlich, der jetzige Code ist wirklich Müll, aber auch da ist
Refactoring oft sinnvoller.
Ich würde als Doku eine Übersicht erwarten. Ggf. eine kleine Grafik, wie
die einzelnen Module zusammenarbeiten, wo die Einsprungpunkte (im
embedded Fall halt nur die main() :-) ) sind und wo Interrupts angreifen
etc.
Basiert das Projekt auf einem RTOS, wirds denke ich etwas einfacher, da
Programmteile dann leichter logisch voneinander zu trennen sind.
In einzelne Funktionen einlesen kann man sich dann immernoch, wichtig
ist zunächst, dass man einen Überblick bekommt, was wo passiert.
Stefan Us schrieb:> Besser finde ich jedoch lesbaren Code, zum Beispiel so:> bool jobIsLoadedFromDB=job->getDate()!=0 && job->getDate()->toLong()>0;> if (jobIsLoadedFromDB) {> ...> }
Besser gleich eine eigene Funktion draus machen. Das wird sicher nicht
die einzige Stelle sein, wo man das braucht.
Stefan Us schrieb:> Doxygen erzeugt sowas aus Kommentaren (wenn sie richtig formatiert> sind): http://stefanfrings.de/qtwebapp/api/index.html
Wobei hier nur ein kleiner Teil der Möglichkeiten genutzt wird. Es kann
noch viel ausführlichere Doku produzieren.
Falk Brunner schrieb:>>Neu schreiben ist einfach, sofern GENAU weiß, was das Programm tun soll.>> Quark. Damit kann man ja mal fix immer mehrere tausend bis sowiviel> Arbeitsstunden wegschmeißen. Das ist weder ökonomisch noch praktikabel.
Das kann es durchaus sein. In solchem Code sind oft jede Menge Altlasten
drin, die heute gar keiner mehr versteht, außer dem, der das mal
programmiert hat. Wenn der nicht verfügbar ist, braucht man unter
Umständen mehr Zeit, den (heute teilweise nutzlosen) Code zu verstehen,
als ihn neu zu schreiben. Ganz davon abgesehen ist das auch eine prima
Gelegenheit, das mal aufzuräumen.
Und die Zahl an Stunden, die in den Code im Laufe der Jahre geflossen
sind, entspricht ja nicht der Zeit, die man bräuchte, um ihn neu zu
schreiben.
Es hängt allgemein vom Einzelfall ab und ist - wie oben schon
geschrieben wurde - vorher leider sehr schwer einzuschätzen, was
einfacher ist.
> Denn wir reden hier nicht von kleinen 1 Mann Hobbyprojekten!
Nun sind 15.000 Zeilen aber auch nicht das riesige Megaprojekt, bei dem
ganze Abteilungen jahrelang an Teilmodulen arbeiten.
Kid Rock schrieb:> Zusammensetzen geht leider nicht... Die eine Abteilung ist in> Deutschland, wir sind in Singapur.
Helft nur mit, Arbeit von Deutschland nach Asien auszulagern.
Ihr schafft euch damit noch selbst ab.
Kid Rock schrieb:> Unsere Zweigstelle soll ein Softwareprojekt, welches eine andere> Zweigstelle durchgeführt hat übernehmen und gewisse Änderungen /> Verbesserungen durchführen.>> Es handelt sich um embedded C Code (16Bit Mikrocontroller) für ein> Steuergerät. Ca. 15.000 Zeilen Code... Benutzt werden viel Pointer...> Ein Bekannter von mir hat inoffiziell mal über den Code geschaut und> meinte das das schon alles recht kompliziert ist... einiges auch> umständlich... Er rät sogar den Originalcode zu vergessen und alles neu> zu schreiben.. seiner Meinung nach wäre das schneller...
Ein Software-Projekt zu übernehmen bedeutet ja nicht nur, den Code zu
übernehmen. Sondern auch:
-die Anforderungsspezifikation zu übernehmen
-die Architekturspezifikation zu übernehmen
-die Designspezifikation zu übernehmen
-die Testspezifikation zu übernehmen
Sofern diese denn überhaupt existieren. ;-)
Auch die Hardware sollte so beschrieben und dokumentiert sein, dass man
erneut ein funktionsfähiges Gesamtsystem erzeugen kann. Selbst die beste
Software läuft nun mal nicht auf dem Papier.
Das Wichtigste sind am Ende die Anforderungen. Nach diesen wird die
Software bzw. das gesamte System entwickelt, und gegen diese wird
getestet. Wenn die Anforderungen nicht aufgeschrieben sind, oder in
einer beschissenen Qualität vorliegen, dann gute Nacht. Das artet in
einem entsprechend hohen Aufwand für Reverse Engineering und/oder fürs
Nachspezifizieren aus. Ich spreche da aus Erfahrung.
Rolf Magnus schrieb:> Jörg Wunsch schrieb:>> Rolf Magnus schrieb:>>> Wobei ich das dann aber im Doxygen-Format bevorzugen würde>>>> Das ist natürlich nice to have, keine Frage.>> Doxygen oder was vergleichbares ist für mich nicht nur nice to have.
Doxygen ist nur nice-to-have, also relativ weit unten auf meiner Liste.
Doxygen ist nur ein Tool. Mir sind die Informationen, nicht die Tools
wichtig.
Wie für jedes Tool gilt bei Doxygen
nützt mir gar nichts.
So einen Müll kann ich 100 Mal durch Doxygen schieben, ich bekomme immer
nur Müll raus. Zwar schöner formatiert und mit ein paar Diagrammen und
Querverweisen, aber Müll.
Da ist mir das ursprüngliche Beispiel, ohne Doxygen-Dekoration
wesentlich lieber. An das könnte ich, wenn ich unbedingt Doxygen
bräuchte, einen billigen Studenten setzen, der das Ganze in ein paar
Stunden für Doxygen formatiert. Bei dem Müll da oben kann man das nicht.
Hannes Jaeger schrieb:> Rolf Magnus schrieb:>> Jörg Wunsch schrieb:>>> Rolf Magnus schrieb:>>>> Wobei ich das dann aber im Doxygen-Format bevorzugen würde>>>>>> Das ist natürlich nice to have, keine Frage.>>>> Doxygen oder was vergleichbares ist für mich nicht nur nice to have.>> Doxygen ist nur nice-to-have, also relativ weit unten auf meiner Liste.> Doxygen ist nur ein Tool. Mir sind die Informationen, nicht die Tools> wichtig.
Doxygen bietet aber eine komfortable Möglichkeit, diese Informationen
schön aufzubereiten und auch noch ein paar zusätzliche nicht explizit
dokumentierte Infos aus dem Code zu genereiren, sowie deren Verlinkung.
> Wie für jedes Tool gilt bei Doxygen> So einen Müll kann ich 100 Mal durch Doxygen schieben, ich bekomme immer> nur Müll raus. Zwar schöner formatiert und mit ein paar Diagrammen und> Querverweisen, aber Müll.
Natürlich muss ich den Input dafür auch liefern. Wie bei jedem Werkzeug
kann man es auch falsch benutzen. Das tut der allgemeinen Nützlichkeit
des Werkzeugs aber keinen Abbruch.
Und um ehrlich zu sein: Selbst bei nicht oder nur schlecht
dokumentiertem Code kann ich einen besseren Überblick bekommen, wenn ich
den erstmal durch Doxygen jage, als wenn ich den Code direkt ansehe.
@Rolf Magnus (Gast)
>>>Neu schreiben ist einfach, sofern GENAU weiß, was das Programm tun soll.>> Quark. Damit kann man ja mal fix immer mehrere tausend bis sowiviel>> Arbeitsstunden wegschmeißen. Das ist weder ökonomisch noch praktikabel.>Das kann es durchaus sein. In solchem Code sind oft jede Menge Altlasten>drin, die heute gar keiner mehr versteht, außer dem, der das mal>programmiert hat.
Mensch, daß sowas im Einzelfall sinnvoll ist, ist doch gar nicht
bestritten worden. Sondern die pauschale Aussage, daß men es meistens
oder gar immer so machen soll!!!
>als ihn neu zu schreiben. Ganz davon abgesehen ist das auch eine prima>Gelegenheit, das mal aufzuräumen.
Nice to have.
>Und die Zahl an Stunden, die in den Code im Laufe der Jahre geflossen>sind, entspricht ja nicht der Zeit, die man bräuchte, um ihn neu zu>schreiben.
Komischerweise werden Softwareprojekte von jahr zu jahr nicht unbdeingt
kürzer und effizineter . . .
>> Denn wir reden hier nicht von kleinen 1 Mann Hobbyprojekten!>Nun sind 15.000 Zeilen aber auch nicht das riesige Megaprojekt, bei dem>ganze Abteilungen jahrelang an Teilmodulen arbeiten.
Ja und? Denkst du, eine kleine bis mittlere Firma will einfach mal 6-12
Mannmonate Arbeit wegschmeißen? Es hat nicht jeder zuviel geld wie
Microsoft & Co!
Rolf Magnus schrieb:> In solchem Code sind oft jede Menge Altlasten> drin, die heute gar keiner mehr versteht, außer dem, der das mal> programmiert hat.
Und diese scheinbaren Altlasten sind vielleicht die Antworten auf
besondere Situationen wie Bugs in Libraries oder (von 3. Seite
definierte und nicht änderbare) idiotisch gestaltete Schnittstellen
anderer Komponenten.
Wenn der neugeschriebene Code nach ein paar Jahren Jahren dann läuft,
die gleiche Funktionalität hat und halbwegs praxisgetestet ist, sieht er
genauso katastrophal aus. Genau dann wäre der Zeitpunkt, an dem die
Programmierer alle reingehackten Spezialanforderungen noch im Kopf haben
und alles aufräumen und etwas gutes daraus machen könnten. Aber dafür
ist natürlich keine Zeit und irgendwann übernimmt die nächste Abteilung
das Projekt und flucht über die idiotischen Vorgänger.
Jörg Wunsch schrieb:> sondern so:> /*> * Diese Funktion bekommt ein mumble
Sobald ein Pfuscher am Projekt beteiligt war, kann man der Prosa sowieso
nicht trauen, weil der Code seit der Erstellung der Doku dreimal
umgeworfen wurde.
Wenn ich solche Doku bei meinem aktuellen Projekt sehe, geht der erste
Blick ins VCS-Log. Nachdem Kollege A vor zwei Jahren die Funktion+Doku
mustergültig geschrieben hat, hat meist Kollege X (Spezialität: erstmal
schnell ohne zu denken programmieren, die Funktionalität wird dann
hinterher hinein-debuggt; sobald es geht, commit und auf zur nächsten
Aufgabe) mehrfach irgendwas geändert und garantiert nicht die Doku
angepasst. Also schlimmer als keine Doku, weil irreführend.
Tom schrieb:> Wenn ich solche Doku bei meinem aktuellen Projekt sehe, geht der erste> Blick ins VCS-Log. Nachdem Kollege A vor zwei Jahren die Funktion+Doku> mustergültig geschrieben hat, hat meist Kollege X (Spezialität: erstmal> schnell ohne zu denken programmieren, die Funktionalität wird dann> hinterher hinein-debuggt; sobald es geht, commit und auf zur nächsten> Aufgabe) mehrfach irgendwas geändert und garantiert nicht die Doku> angepasst. Also schlimmer als keine Doku, weil irreführend.
Das heißt dann, dass in der Firma entweder:
a.) die Prozesse nichts taugen oder
b.) der Vorgesetzte nichts taugt, weil er nicht darauf achtet was seine
Leute (die er ja angeblich führen soll) überhaupt tun.
Ach so, es gibt noch eine Möglichkeit.
c.) Der Vorgesetzte würde zwar etwas taugen, ist aber mit weitgehend
sinnfreiem Reporting und zu vielen Meetings so ausgelastet, dass er
nicht dazu kommt darauf zu schauen, was seine Leute eigentlich so an
Code und Doku verzapfen.
Also ein schlechtes Management im Endeffekt, welches verhindert dass die
Vorgesetzten ihre eigentlichen Aufgaben wahrnehmen.
Tom schrieb:> Wenn der neugeschriebene Code nach ein paar Jahren Jahren dann läuft,> die gleiche Funktionalität hat und halbwegs praxisgetestet ist, sieht er> genauso katastrophal aus. Genau dann wäre der Zeitpunkt, an dem die> Programmierer alle reingehackten Spezialanforderungen noch im Kopf haben> und alles aufräumen und etwas gutes daraus machen könnten.
Respekt für diese Gedächtnisleistungen! Mir ist weder im Privaten noch
Beruflichen nach ein paar Jahren präsent, was ich wie warum so gemacht
habe. Zumindest nicht solche Details. Wenn's ein dicker Klopper war,
natürlich. Aber wenn etwas auch noch x mal geändert wurde weiß ich
garantiert nicht mehr, ob das, was ich da sehe, überhaupt der letzte
Stand war...
Danke nochmals...
Wie gesagt eigentlich bin ich nicht die richtige Person fuer sowas und
habe meine Vorbehalte schon kommuniziert.
Das half mir bisher am Besten weiter:
+ Anforderungsspezifikation
+ Architekturspezifikation
+ Designspezifikation
+ Testspezifikation
Habe schon einiges gesichtet, aber die Dokumentation die ich bisher
erhalten habe passt auf auf vieleicht 20 DINA4 Blaetter...
Ich haette erwartet das es ein paar Diagramme gibt, die vieleicht das
ein oder andere erklaeren. Oder zum Beispiel ein Dokument das alle
Fuktionen auflistet mit eventuell einer kurzen Beschreibung.
Ist ja nicht das ich noch nie eine Zeile Code geschrieben haette aber
nie so etwas umfangreiches... meist nur ein paar Zeilen um meine
Hardware zu testen... Was ich soweit gesehen habe gibt es in dem Code
wohl einen groessen Speicherbereich und alles greift irgendwie darauf zu
bzw schreibt dort rein... Funktionen die einen wirklichen Rueckgabewert
haben seh ich dort fast nicht... Aber wie gesagt bin ich nicht der
Fachmann...
Mal ne andere dumme Frage... Wenn ich so durch die wenige Dukumentation
gehe, mit dem Hintergrund das ich keine Software schreibe, sollte ich
nicht wenigstens in etwa verstehen was dort dokumentiert ist...
Es handelt sich wie gesagt um ein Steuergeraet mit Mikrocontroller, ein
paar Sensoren mit I2C / SPI, ein paar Analogeingaenge, ein paar digitale
Ausgaenge mit PWM, serielle Schnittstelle, EEPROM und ein GPS
Empfanger...
Danke nochmals an alle...
Mit deiner Erfahrung - und den Aussage von dir zu dem Code/Dokumentation
ist es schwierig irgendetwas so sagen
-Das Projekte könnte aus Quelltextsicht ganz schnukkelig und
verständlich sein - auch wenn die Doku Müll ist - du würdest es nicht
wirklich erkennen
-Das Projekt könnte aus Quelltextsicht ganz nett aussehen und die Doku
ist verständlich (aber trotzdem Müll) - würde dir genauso wenig
auffallen oder?
Ohne die Möglichkeit den Quelltext einfach wie ein "Erfahrener"
Entwickler "mal eben" durchzulesen sehe ich schwarz für jeder
Vorbeurteilung - und diese Rateschläge mit "Neuschreiben" kannst du
gerade mal in die Anfängertonne klopfen
Das einzige was zähl:
Wenn es gibt:
-Repositorium von die Entwicklung versionkontrolliert wurde, (CVS, RCS,
SVN, Git, ... was auch immer - egal was) - oder eben alles was du an
Dateien bekommen kannst - mit klarer Info was davon der Master-Stand ist
-passendes Entwicklungssystem zum erstellen und debuggen der Anwendung,
das sollte nicht nur das passende installiert sein sondern auch direkt
laufen und getestet werden - du musst mit der Software eine laufende
Hardware hinbekommen
-eine Kontaktperson aus dem alten Team - ihr werdet nicht alle Probleme
100% selbst lösen können (Zeitmangel) - manchmal reicht ein kurzes
Telefonat um Dinge die euch Tage kosten zu klären
Kopf hoch - dein einziges Problem ist der fehlende Entwickler - dem du
auch noch vertrauen können solltest - das würde mich am meisten stören
NaSuper schrieb:> Kid Rock schrieb:>> Zusammensetzen geht leider nicht... Die eine Abteilung ist in>> Deutschland, wir sind in Singapur.>> Helft nur mit, Arbeit von Deutschland nach Asien auszulagern.> Ihr schafft euch damit noch selbst ab.
+1
@Kid Rock:
Letztendlich wirst Du erst sehen, ob es klappt, wenn Deine neuen
Softwerker da sind. Ein heller Kopf kommt mit Spaghetti-Code eher klar
als ein Dunkelhut.
Ansonsten kann auch noch Refactoring sinnvoll sein.
http://de.wikipedia.org/wiki/Refactoring
Ich hab mal ein völlig chaotisches Projekt übernommen.
Meine Vorgehensweise war dann so
1. Schritt: Den Source-Code systematisch aufräumen, ohne daß dabei sich
der Objectcode (das Hexfile) ändert.
2. Schritt: Projekt im Versionsverwaltungssystem sichern
3. Schritt: Ein kleines Aufräum-Paketchen machen, bei dem sich der
Objectcode ändern, testen und im VWS sichern.
4. Schritt: Nächstes kleines Aufräum-Paketchen machen, bei dem sich der
Objectcode ändern, testen und im VWS sichern.
5. usw.
Wichtig dabei: Immer nur kleine Änderungen machen und jedesmal den
Programmstand sichern, dann kann man schnell und einfach nachvollziehen,
ob eine bestimmte Änderung einen ungewünschten Seiteneffekt hatte, bzw.
welche Änderungen diesen Seiteneffekt verursacht hat.
Bronco schrieb:> 1. Schritt: Den Source-Code systematisch aufräumen, ohne daß dabei sich> der Objectcode (das Hexfile) ändert.> 2. Schritt: Projekt im Versionsverwaltungssystem sichern
Die beide Schritte würde ich umdrehen!
Falk Brunner schrieb:> Ein Quelltext muss nicht immer den persönlichen Vorlieben entsprechen,> um dennoch gut zu funktionieren.
und was macht man wenn einem keiner glaubt?
habe 3 Wochen gebraucht um "Cheffe" zu überzeugen das das Urprogramm
Luftmesseungen macht, da sind aber schon 50.000 Tastwahlblöcker verkauft
worden. Erst nach mühsamer Überzeugungsarbeit durfte ich den alten Code
rauswerfen, neu schreiben und habe noch mal 30% Prüfzeit eingepart und
dabei noch mehr Messungen gemacht, in den Pausen (so ein Tastwahlblock
legt schon mal eine Zwischenwahlzeit ein und da kann man prima Strom und
Spannung messen)
Falk Brunner schrieb:>>Das kann es durchaus sein. In solchem Code sind oft jede Menge Altlasten>>drin, die heute gar keiner mehr versteht, außer dem, der das mal>>programmiert hat.>> Mensch, daß sowas im Einzelfall sinnvoll ist, ist doch gar nicht> bestritten worden. Sondern die pauschale Aussage, daß men es meistens> oder gar immer so machen soll!!!
Meines Erachtens liegt die Wahrheit dazwischen. Es sind nicht nur
Einzelfälle, aber genausowenig ist es fast immer so, daß neuschreiben
die bessere Lösung wäre.
Schon mehrmals erlebt: Das Projekt sollte eigentlich neue Features
bekommen, aber die Architektur ist so festgefahren, daß man die da so
gar nicht reinbekommt. Dafür sind 100 andere Sachen drin, die seit
Jahren keiner mehr nutzt und die den Code dadurch unnötig kompliziert
machen.
Aussage der bisherigen Programmierer: Da müßte man ja alles umstellen...
viel zu aufwendig.
Wenn man dann schon neue Leute dran setzt, kann man die Gelegenheit auch
gleich nutzen, um da mal einen Schnitt zu machen.
>>als ihn neu zu schreiben. Ganz davon abgesehen ist das auch eine prima>>Gelegenheit, das mal aufzuräumen.>> Nice to have.
Nein!
>>> Denn wir reden hier nicht von kleinen 1 Mann Hobbyprojekten!>>>Nun sind 15.000 Zeilen aber auch nicht das riesige Megaprojekt, bei dem>>ganze Abteilungen jahrelang an Teilmodulen arbeiten.>> Ja und? Denkst du, eine kleine bis mittlere Firma will einfach mal 6-12> Mannmonate Arbeit wegschmeißen?
Wie ich oben schon geschrieben habe: Wieviel man wegschmeißt, ist egal.
Es kommt lediglich darauf an, was billiger ist. Wenn das Neuschreiben
weniger Zeit kostet, als neue Leute in das alte Projekt einzuarbeiten
und dieses aufzuräumen, dann schreibt man neu, unabhängig davon, ob
vorher 3 Mannmonte oder 30 da reingeflossen sind.
> Es hat nicht jeder zuviel geld wie Microsoft & Co!
Eben. Deshalb nimmt man die billigere Variante, auch wenn das bedeutet,
daß man Sachen wegwerfen muss.
@ Rolf Magnus (Gast)
>Wie ich oben schon geschrieben habe: Wieviel man wegschmeißt, ist egal.>Es kommt lediglich darauf an, was billiger ist. Wenn das Neuschreiben>weniger Zeit kostet, als neue Leute in das alte Projekt einzuarbeiten>und dieses aufzuräumen, dann schreibt man neu, unabhängig davon, ob>vorher 3 Mannmonte oder 30 da reingeflossen sind.
Ja, WENN es denn so ist. Und die Abschätzung auch WIRKLICH so Realität
wird! Meine, wenn gleich nicht sonderlich große Erfahrung, ist da eher
anders!
Rolf Magnus schrieb:> Es kommt lediglich darauf an, was billiger ist. Wenn das Neuschreiben> weniger Zeit kostet, als neue Leute in das alte Projekt einzuarbeiten> und dieses aufzuräumen, dann schreibt man neu, unabhängig davon, ob> vorher 3 Mannmonte oder 30 da reingeflossen sind.
ich habe 3 Wochen ohne Hilfe am alten unkommentierten Code gesessen,
(CBM Basic Spagetti Code viel GOTO und ein bissl ASM in HEX dazwischen)
vieles nicht verstanden aber zu letzt festgestellt das das Programm
Hausnummern fabriziert, für mich war klar das ich aus dem Gestrüpp nur
rauskomme mit Neuschreiben, schade das dafür 3 Wochen vertrödelt wurden
mit der Aussage, wieso Fehler das lief doch Monate (nur hatte niemand
überprüft ob richtig gemessen wurde -> Prüfautomat, Messgeräte,
Generatoren und Relais angesteuert)
Falk Brunner schrieb:> @ Rolf Magnus (Gast)>>>Wie ich oben schon geschrieben habe: Wieviel man wegschmeißt, ist egal.>>Es kommt lediglich darauf an, was billiger ist. Wenn das Neuschreiben>>weniger Zeit kostet, als neue Leute in das alte Projekt einzuarbeiten>>und dieses aufzuräumen, dann schreibt man neu, unabhängig davon, ob>>vorher 3 Mannmonte oder 30 da reingeflossen sind.>> Ja, WENN es denn so ist.
Ich sagte ja schon, daß es nicht sein MUSS, aber KANN.
> Und die Abschätzung auch WIRKLICH so Realität wird!
Deshalb habe ich (und andere) oben ja auch schon geschreiben, daß es
leider vorher sehr schwer einzuschätzen ist. Mein weiß meistens erst
nachher, was besser gewesen wäre.
@ Rolf Magnus (Gast)
>> Und die Abschätzung auch WIRKLICH so Realität wird!>Deshalb habe ich (und andere) oben ja auch schon geschreiben, daß es>leider vorher sehr schwer einzuschätzen ist. Mein weiß meistens erst>nachher, was besser gewesen wäre.
Das ist das große Dilema! Wie man es macht, macht man es falsch!
Thread beobachten
Seitenaufteilung abschalten