wieso müssen programmierer immer anderer leute software schlecht reden?
-
So ganz ist mir der Sinn von Marc++us' Theorie nicht klar. Damit kann ich doch alles erklären, jedes beliebige Verhalten ist im Sinne irgendeines Kriteriums optimal. Aber eine Theorie, die alles erklärt, erklärt nichts. Und so kann daraus auch nicht der Schluss, dass man besser in Gruppen arbeiten soll, gezogen werden. Zumal der Schluss auch nicht unbedingt plausibel ist, denn "Viele Köche verderben den Brei."
-
Bashar schrieb:
Zumal der Schluss auch nicht unbedingt plausibel ist, denn "Viele Köche verderben den Brei."
stimmt, normal schafft einer an und der rest kocht
-
Dokumentation gehoert einfach zu qualitativ guter Software dazu!
-
ja, die schreibt dann der azubi... und wenn er das programm verstanden hat, darf er bischen spielen
-
Mei, ich kenn' da einen, der hat an einem WE in selbstverordneten Überstunden einen Fräsbahngenerator runtergerissen, der war ein paar Wochen später unabgemeldet in Indien und hat von da aus angerufen, daß er nicht mehr wieder kommt, eingehaltenes Versprechen.
Den Code hat hinterher keine Sau mehr verstanden, aber der tut bis heute - ist auch gut 12 Jahre her jetzt. Schlechtreden könnte ich den bis heute nicht.
Das, was verärgert, ist, daß er uns ohne vernünftige Doku hinterlassen hat.
-
Nein, die Doku muss der Entwickler schreiben, der die Software geschrieben (oder verbrochen) hat.
-
Bashar schrieb:
So ganz ist mir der Sinn von Marc++us' Theorie nicht klar. Damit kann ich doch alles erklären, jedes beliebige Verhalten ist im Sinne irgendeines Kriteriums optimal. Aber eine Theorie, die alles erklärt, erklärt nichts. Und so kann daraus auch nicht der Schluss, dass man besser in Gruppen arbeiten soll, gezogen werden. Zumal der Schluss auch nicht unbedingt plausibel ist, denn "Viele Köche verderben den Brei."
Jo, mein letztes Posting anbelangend:
Der Typ hatte einen Geistesblitz und hat den runtergerissen - solche Momente hatte ich auch gelegentlich.
Aber dann ist er durchgetickert und hat uns ohne Doku hinterlassen - sein Zeug hat aber funktioniert, nur ich schnall's nicht, neben ein paar anderen Proggern. Der hat sich vermutl. Koks und XTC in Red Bull aufgelöst und intravenös gegeben, keine Ahnung.
Das war kein Teamwork, der hat das ganz alleine gemacht und ein Team hätte in der Situation nichts besser machen können.
Aber wir lassen das jetzt trotzdem einfach liegen. Nicht wartbar.
-
kellerassel schrieb:
ja, die schreibt dann der azubi... und wenn er das programm verstanden hat, darf er bischen spielen
Der azubi versteht bzw. überblickt das Programm aber nicht.
Vor allen nicht wenn der Code scheisse ist.
-
es kommt doch immer darauf an, man muss die ja nicht gleich überfordern, so dass sie nicht mehr kommen... aber es wird doch funktionen geben, die aus ein paar zeilen bestehen, die nicht mit 50 klassen interagieren, welche relativ leicht verständlich sind und ein kommentar fehlt? dabei liest man code und macht was nützliches - ist doch okay für den anfang, oder?
also in meinem würden mir spontan schon ein paar stellen einfallen
-
btw. bis auf eine kleine mini c++ wrapper lib mit 5 funktionen wär alles in c. das sollte es auf jeden fall nicht schwerer machen :p
aber leider kann ich mir zzt. keine mitarbeiter leisten, und es bleibt unkommentiert - ein dilemma
