Forum: Mikrocontroller und Digitale Elektronik Softwareprojekt übernehmen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Kid R. (uglykidjoe)


Bewertung
0 lesenswert
nicht lesenswert
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
von Softworker (Gast)


Bewertung
3 lesenswert
nicht lesenswert
>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.

von Rene H. (Gast)


Bewertung
4 lesenswert
nicht lesenswert
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é

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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:
   zaehler++;  /* zaehler hochzählen */

sondern so:
/*
 * Diese Funktion bekommt ein mumble als Eingabe, verarbeitet es
 * entsprechend dem Algorithmus aus Meyer: Kleines Einmaleins, S. 25,
 * und gibt das Ergebnis in foobar zurück, der auf ein Feld von
 * hmptzig 32-bit-Ganzzahlen zeigen muss.
 *
 * Als Hilfsfunktion wird dooboo() aufgerufen, globale Variablen
 * werden nicht geändert.
 *
 * Ein Rückkehrwert von 0 bedeutet Erfolg, andernfalls waren Fehler
 * aufgetreten; Beschreibung siehe "fehler.h".
 */
fehler_t fooboo(const mumble_t *mumble, foobar_t *foobar)
{
  // …
}

von Rolf Magnus (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Peter II (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?
* 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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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“.

von Peter II (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Daniel V. (danvet)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Pandur S. (jetztnicht)


Bewertung
2 lesenswert
nicht lesenswert
Software Projekte "einfach" uebernehmen ist viel teurer als erwartet und 
dauert viel laenger als erwartet. Denn man macht die Arbeit eigentlich 
nochmals.

von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Kid R. (uglykidjoe)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Kid R. (uglykidjoe)


Bewertung
0 lesenswert
nicht lesenswert
Ich guck ja schon grade... :)

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Beispiel für einen hilfreichen Inline Kommentar:
// Process the job only if it was loaded from DB
if (job->getDate()!=0 && job->getDate()->toLong()>0) {
  ...
}

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:
bool jobIsLoadedFromDB=job->getDate()!=0 && job->getDate()->toLong()>0;
if (jobIsLoadedFromDB) {
  ...
}

Wenn man von solchen Bedingungen mehrere miteiandner verknüpft, 
vermeidet man so ganz hässlichen Code:
if ((jobIsLoadedFromDB && jobIsNotScheduleForFuture) || forceFlagIsSet) {
  ...
}

Die hässliche Version kann sich jeder selbst denken.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Doxygen erzeugt sowas aus Kommentaren (wenn sie richtig formatiert 
sind): http://stefanfrings.de/qtwebapp/api/index.html

: Bearbeitet durch User
von Falk B. (falk)


Bewertung
1 lesenswert
nicht lesenswert
@ 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!

von Mladen G. (mgira)


Bewertung
0 lesenswert
nicht lesenswert
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

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jan H. (j_hansen)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Random .. (thorstendb) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von NaSuper (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
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
von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
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
Müll rein -> DOXYGEN -> Müll raus

D.h. Doxygen-Kommentare der Form
/*! \brief Meine Upsidupsidu-Funktion.
 *
 *
 *  Implementierung der Upsidupsidu-Funktion.
 */
struct special *
upsidupsidu(void *dadada, struct special2 *thingy, int a, int, b) {
...
}
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.

von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@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!

von Tom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
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
von Lutz (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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...

von Kid R. (uglykidjoe)


Bewertung
0 lesenswert
nicht lesenswert
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...

von DerBert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von megusta (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bronco (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@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.

von Eric B. (beric)


Bewertung
2 lesenswert
nicht lesenswert
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!

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ 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!

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf Magnus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Mein

Man

> weiß meistens erst nachher, was besser gewesen wäre.

oder auch nie.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ 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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.