Ja, ich verstehe deine Frustration über die dumme Regel. Ich habe viele Programme mit sinnlosen Kommentaren wie gelesen
x = x + 1; // add 1 to x
Und ich sage mir, das ist was für ein Pluszeichen bedeutet !! Wow, danke, dass du es mir erzählt hast, das wusste ich nicht.
Aber das heißt, der Kunde bezahlt die Rechnung. Deshalb gibst du ihnen, was sie wollen. Wenn ich bei einem Autohaus arbeiten würde und ein Kunde sagte, er wolle einen Pickup, würde ich mich nicht mit ihm darüber streiten, ob er wirklich einen Pickup braucht, und ihn befragen, was er erwartet, damit anzufahren. Ich würde ihm einen Pickup verkaufen.
Okay, es gibt Zeiten, in denen das, was der Kunde wünscht und was er wirklich braucht, so weit voneinander entfernt ist, dass ich versuche, die Angelegenheit mit ihm zu besprechen, ihn vielleicht davon zu überzeugen, sich auf etwas Vernünftigeres zu einigen. Manchmal funktioniert das, manchmal nicht. Am Ende gebe ich ihm, was er will, wenn ich seine Meinung nicht ändern kann. Wenn er später wiederkommt und sagt: Oh, das hat meine geschäftlichen Anforderungen wirklich nicht erfüllt, können wir ihm mehr in Rechnung stellen, um das zu tun, was wir ihm beim ersten Mal gesagt haben. Wie viel Sie mit dem Kunden verhandeln können, hängt davon ab, wie sehr er Ihrem Fachwissen vertraut, wie der Vertrag mit Ihnen zur Organisation passt und ehrlich gesagt, wie eigenwillig er ist.
Es wäre ein sehr seltener Fall, in dem ich unter der Annahme, dass es an mir liegt, einen Vertrag verlieren würde, weil ich dachte, dass die Anforderungen schlecht konzipiert waren.
Denken Sie daran, dass die Personen, mit denen Ihr Unternehmen verhandelt, möglicherweise diejenigen sind, die diese 25% -Regel erfunden haben oder nicht. Es könnte eine Regel sein, die ihnen von oben auferlegt wird.
Ich sehe fünf mögliche Antworten:
Ein. Überzeugen Sie Ihren Chef oder jeden, der mit dem Kunden verhandelt, darüber zu streiten. Wahrscheinlich wird dies nichts bewirken, aber Sie können es versuchen.
Zwei. Weigere dich, es zu tun. Dadurch werden Sie wahrscheinlich entlassen, oder wenn das Unternehmen mit Ihnen einverstanden ist, verlieren Sie den Vertrag. Das scheint unproduktiv.
Drei. Schreiben Sie unbrauchbare Kommentare, um Platz zu schaffen, Kommentare, die nur wiederholen, was sich im Code befindet, und die jeder Programmierer, der den Code ändern kann, in 2 Sekunden sehen kann. Ich habe so viele Kommentare gesehen. Vor Jahren arbeitete ich für eine Firma, in der wir vor jeder Funktion, in der die Parameter aufgeführt sind, Kommentarblöcke einfügen mussten, wie z.
/*
GetFoo function
Parameters:
name: String, contains name
num: int, the number
add_date: date, the date added
Returns:
foo code: int
*/
int GetFoo(String name, int num, Date add_date)
Der Einwand, dass solche Kommentare eine Wartungslast darstellen, weil Sie sie auf dem neuesten Stand halten müssen, ist ungültig. Sie müssen nicht auf dem neuesten Stand gehalten werden, da kein seriöser Programmierer sie sich jemals ansehen wird. Wenn Sie diesbezüglich Fragen haben, sollten Sie allen Teammitgliedern klar machen, dass die nutzlosen, überflüssigen Kommentare ignoriert werden sollten. Wenn Sie wissen möchten, was die Parameter einer Funktion sind oder was eine Codezeile bewirkt, lesen Sie den Code, und sehen Sie sich die nutzlosen Kommentare nicht an.
Vier. Wenn Sie überflüssige wertlose Kommentare hinzufügen möchten, ist es möglicherweise die Zeit wert, ein Programm zu schreiben, um sie zu generieren. Etwas wie eine Investition im Vorfeld, könnte aber eine Menge Tipparbeit ersparen.
Als ich in diesem Geschäft anfing, verwendete eine Firma, für die ich arbeitete, ein Programm mit der Aufschrift "Schreibt Ihre Dokumentation für Sie! Vollständige Dokumentation für jedes Programm!" Das System verlangte, dass wir allen Variablen im Wesentlichen bedeutungslose Namen geben und dann eine Tabelle mit einem aussagekräftigen Namen für jede Variable erstellen. Die "automatische Dokumentation" ersetzte also im Wesentlichen den bedeutungslosen Namen, den wir verwenden mussten, durch einen aussagekräftigen Namen. Zum Beispiel - dies funktionierte mit COBOL - hätten Sie eine Zeile in Ihrem Programm, die besagt
MOVE IA010 TO WS124
und sie würden eine Reihe von "Dokumentationen" generieren, die besagten
COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE
Wie auch immer, man könnte mit Sicherheit ein Programm schreiben, mit dem man ziemlich leicht ebenso wertlose Dokumentation erstellen kann. Lesen Sie eine Zeile wie
a=b+c
und generiere den Kommentar
// add b to c and save result in a
Usw.
Fünf. Mach das Beste aus der dummen Regel. Versuchen Sie, nützliche und aussagekräftige Kommentare zu verfassen. Hey, es könnte eine gute Übung sein.
Oh, übrigens, darf ich hinzufügen, dass Sie die Metrik immer spielen können.
Ich erinnere mich, als ein Arbeitgeber sagte, sie würden damit beginnen, die Produktivität von Programmierern an der Anzahl der Codezeilen zu messen, die wir pro Woche erstellt haben. Als uns dies bei einem Treffen gesagt wurde, sagte ich: Großartig! Ich kann meine Punktzahl leicht steigern. Kein Schreiben mehr
x=x+4;
Stattdessen schreibe ich:
x=x+1;
x=x+1;
x=x+1;
x=x+1;
Schleifen? Vergiss es, ich werde den Code zehnmal kopieren und einfügen. Usw.
Wenn Sie also Kommentarzeilen zählen möchten, machen Sie jede Zeile kurz und setzen Sie die Idee in der nächsten Zeile fort. Wenn sich Änderungen in den Kommentaren ergeben, aktualisieren Sie den vorhandenen Kommentar nicht. Tragen Sie ein Datum ein, kopieren Sie den gesamten Text und schreiben Sie "Updated" und ein neues Datum. Wenn der Kunde Fragen stellt, teilen Sie ihm mit, dass Sie der Meinung sind, dass die Historie gepflegt werden muss. Usw.