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
:
Verschoben durch Moderator
>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
|
11 | * aufgetreten; Beschreibung siehe "fehler.h".
|
12 | */
|
13 | fehler_t fooboo(const mumble_t *mumble, foobar_t *foobar) |
14 | {
|
15 | // …
|
16 | }
|
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?
1 | * Als Hilfsfunktion wird dooboo() aufgerufen, diese ruft dann foo() auf. globale Variablen werden nicht geändert. Außer wenn es in dooboo() oder dann in foo() gemacht geändert werden. |
So eine doku wird immer veralten.
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. :)
:
Bearbeitet durch Moderator
Beispiel für einen hilfreichen Inline Kommentar:
1 | // Process the job only if it was loaded from DB |
2 | 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:
1 | bool jobIsLoadedFromDB=job->getDate()!=0 && job->getDate()->toLong()>0; |
2 | if (jobIsLoadedFromDB) {
|
3 | ... |
4 | } |
Wenn man von solchen Bedingungen mehrere miteiandner verknüpft, vermeidet man so ganz hässlichen Code:
1 | if ((jobIsLoadedFromDB && jobIsNotScheduleForFuture) || forceFlagIsSet) {
|
2 | ... |
3 | } |
Die hässliche Version kann sich jeder selbst denken.
Doxygen erzeugt sowas aus Kommentaren (wenn sie richtig formatiert sind): http://stefanfrings.de/qtwebapp/api/index.html
@ 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.
:
Bearbeitet durch User
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
1 | Müll rein -> DOXYGEN -> Müll raus |
D.h. Doxygen-Kommentare der Form
1 | /*! \brief Meine Upsidupsidu-Funktion.
|
2 | *
|
3 | *
|
4 | * Implementierung der Upsidupsidu-Funktion.
|
5 | */
|
6 | struct special * |
7 | upsidupsidu(void *dadada, struct special2 *thingy, int a, int, b) { |
8 | ...
|
9 | }
|
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.
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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 schrieb: > Mein Man > weiß meistens erst nachher, was besser gewesen wäre. oder auch nie.
@ 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 abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.