Sì, capisco la tua frustrazione per la regola stupida. Ho letto molti programmi con commenti inutili come
x = x + 1; // add 1 to x
E io dico a me stesso, così CHE è un segno più significa !! Wow, grazie per avermelo detto, non lo sapevo.
Ma detto questo, il cliente paga il conto. Pertanto, dai loro ciò che vogliono. Se lavorassi in un concessionario di auto e un cliente dicesse che voleva un furgone, non avrei discusso con lui se avesse davvero bisogno di un camioncino e lo interrogasse su cosa si aspettasse di trascinare in esso. Gli venderei un furgoncino.
Ok, ci sono momenti in cui ciò che i clienti dicono di volere e ciò di cui ha veramente bisogno sono così distanti che cerco di discutere la questione con lui, forse convincerlo a concordare qualcosa di più razionale. A volte funziona, a volte no. Alla fine, se non riesco a cambiare idea, gli do quello che vuole. Se torna più tardi e dice, Oh, questo in realtà non ha soddisfatto i miei requisiti di business, quindi possiamo caricarlo di più per fare ciò che gli abbiamo detto di fare la prima volta. Quanto puoi negoziare con il cliente dipende da quanto si fidi della tua esperienza, dal modo in cui il loro contratto con te si adatta all'organizzazione e, francamente, da come sono diventati teste di toro.
Sarebbe un caso molto raro in cui, supponendo che dipendesse da me, avrei perso un contratto perché pensavo che i requisiti fossero mal concepiti.
Tieni presente che le persone con cui la tua azienda sta negoziando potrebbero o meno essere quelle che hanno inventato questa regola del 25%. Potrebbe essere una regola imposta su di loro da più in alto.
Vedo cinque possibili risposte:
Uno. Convinci il tuo capo o chiunque stia negoziando con il cliente per discuterne. Le probabilità sono che questo non porterà a nulla, ma puoi provare.
Due. Rifiuta di farlo. Questo probabilmente ti farà licenziare, o se la compagnia è d'accordo con te, farai perdere il contratto. Questo sembra improduttivo.
Tre. Scrivi commenti inutili per riempire lo spazio, il tipo di commenti che ripetono semplicemente ciò che è nel codice e che qualsiasi programmatore in grado di modificare il codice potrebbe vedere in 2 secondi. Ho visto molti commenti come questo. Anni fa ho lavorato per un'azienda in cui dovevamo mettere dei blocchi di commento davanti a tutte le funzioni che elencavano i parametri, come:
/*
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)
L'obiezione che tali commenti sono un onere di manutenzione perché devi tenerli aggiornati non è valida. Non è necessario tenerli aggiornati perché nessun programmatore serio li guarderà mai. Se c'è qualche domanda al riguardo, assicurati di chiarire a tutti i membri del team che i commenti inutili e ridondanti dovrebbero essere ignorati. Se vuoi sapere quali sono i parametri di una funzione o cosa fa una riga di codice, leggi il codice, non guardare i commenti inutili.
Quattro. Se stai per aggiungere commenti inutili ridondanti, forse vale la pena dedicare del tempo a scrivere un programma per generarli. Qualcosa di un investimento in anticipo, ma potrebbe salvare un sacco di digitazione lungo la strada.
Quando ho iniziato a lavorare in questo settore, una società per la quale ho lavorato utilizzava un programma pubblicizzato come "Scrive la documentazione per te! Completa documentazione per ogni programma!" Il sistema richiedeva di dare a tutte le variabili nomi sostanzialmente privi di significato e quindi di avere una tabella che fornisse un nome significativo per ogni variabile, quindi in sostanza ciò che faceva la "documentazione automatica" era sostituire il nome senza significato che ci obbligava a usare con un nome significativo. Ad esempio, questo ha funzionato con COBOL: nel tuo programma avresti una riga che diceva
MOVE IA010 TO WS124
e avrebbero generato una riga di "documentazione" che diceva
COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE
Ad ogni modo, si potrebbe sicuramente scrivere un programma per generare una documentazione altrettanto inutile abbastanza facilmente. Leggi una riga come
a=b+c
e genera il commento
// add b to c and save result in a
Ecc.
Five. Sfruttare al meglio la regola sciocca. Prova a scrivere commenti utili e significativi. Ehi, potrebbe essere un buon esercizio.
Oh, a proposito, posso aggiungere che puoi sempre giocare la metrica.
Ricordo che una volta un datore di lavoro disse che stavano per iniziare a misurare la produttività dei programmatori di quante linee di codice producevamo a settimana. Quando ci è stato detto durante un incontro, ho detto, fantastico! Posso facilmente aumentare il mio punteggio. Basta scrivere
x=x+4;
Invece scriverò:
x=x+1;
x=x+1;
x=x+1;
x=x+1;
Loops? Scordatelo, copierò e incollerò il codice dieci volte. Ecc.
Quindi, se stanno andando a contare le righe di commenti, riduci ogni riga e continua l'idea nella riga successiva. Se c'è una modifica a ciò che accade nei commenti, non aggiornare il commento esistente. Metti una data su di esso, quindi copia l'intero testo e scrivi "Aggiornato" e una nuova data. Se il cliente lo interroga, dì che hai pensato che fosse necessario mantenere la cronologia. Ecc ecc.