misanthropy schrieb am 6. Dezember 2011 18:43
Richard schrieb am 6. Dezember 2011 17:47
Da stimme ich Dir fast zu 100% zu - mit einer klitzekleinen Ausnahme:
Ob Code dokumentiert ist oder nicht sagt nicht wirklich was über die
Qualität aus.
Ich habe durchaus schon undokumentierten aber exzellenten Code
gesehen - der braucht dann auch keine Dokumentation, weil sich beim
Durchlesen des Codes direkt alles Wesentliche erschließt.
Ja und nein. :) Wenn es komplexere Sachen werden oder man 20-30
Methoden hat die zusammen erst irgendwas sinnvolles als Endprodukt
auswerfen bietet es sich auch hier an zumindest einen Satz zu
schreiben und die entsprechende Seite der Doku oder des Wikis und das
Ticket zu verlinken. Muß ja kein Roman sein aber ein kurzes Statement
"Das gehört dazu (weil...).".
Ebenfalls ja und nein :-)
Die 20-30 zusammengehörenden Methoden bündelt man besser im passenden Sprachkonstrukt (Klasse, Modul, Package, wieauchimmer) - wenn das nicht verständlich geht ist das oft ein Hinweis darauf, daß man beim Entwurf irgendwas falsch gemacht hat. Dann sollte man das aber besser korrigieren statt es zu erklären. Und ja, ich weiß natürlich auch daß die böse Außenwelt gerne mal das schöne Modell kaputtmacht und ein passender Kommentar die am wenigsten schlechte Alternative ist. Zufrieden sein sollte man damit aber nicht.
Und die Links auf die Tickets (und die zugehörigen Commits mit der Umsetzung) kann das SCM-System der Wahl (gegebenfalls in Zusammenarbeit mit der Entwicklungsumgebung) viel besser und disziplinierter verwalten als jeder Entwickler. Der muß sich dann "nur" noch am Riemen reißen und aussagekräftige Commit-Messages verfassen.
Ich hatte dieses Jahr schon so viel "Indisch" auf dem Tisch,
ich kotz schon Galle. :> Das war von solcher "Qualität".
"Wer billig kauft kauft zweimal" gilt halt auch für Software-Entwicklung. Ich hoffe, Du bekommst wenigstens ordentlich Schmerzensgeld dafür daß Du Dir den Mist antun mußt.