Sì, capisco la tua frustrazione per la regola sciocca. Ho letto molti programmi con commenti inutili come
x = x + 1; // add 1 to x
E mi dico, quindi QUESTO significa un segno più !! Wow, grazie per avermelo detto, non lo sapevo.
Detto questo, il cliente sta pagando il conto. Pertanto, dai loro quello che vogliono. Se avessi lavorato presso un concessionario di automobili e un cliente avesse detto che voleva un camioncino, non avrei discusso con lui sul fatto che avesse davvero bisogno di un camioncino e non lo interrogassi su ciò che si aspetta di trasportare. Gli venderei un camioncino.
Va bene, ci sono momenti in cui ciò che i clienti dicono che vuole e ciò di cui ha davvero bisogno sono così distanti che provo a discutere della questione con lui, magari a 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 ritorna più tardi e dice, Oh, che davvero non ha soddisfatto i miei requisiti aziendali, allora possiamo fargli pagare di più per fare ciò che gli abbiamo detto di fare la prima volta. Quanto puoi negoziare con il cliente dipende da quanto si fidano delle tue competenze, da come il loro contratto con te si adatta all'organizzazione e, francamente, da quanto sono corretti.
Sarebbe un caso molto raro in cui, supponendo che dipendesse da me, perderei un contratto perché pensavo che i requisiti fossero mal concepiti.
Tieni presente che le persone con cui la tua azienda sta negoziando possono o meno essere quelle che hanno inventato questa regola del 25%. Potrebbe essere una regola imposta loro dall'alto.
Vedo cinque possibili risposte:
Uno. Convincere il proprio capo o chiunque stia negoziando con il cliente per discuterne. Le probabilità sono che questo non compirà nulla, ma puoi provare.
Due. Rifiuta di farlo. Questo probabilmente ti farà licenziare, o se la società è d'accordo con te, ti farà 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 blocchi di commenti davanti a ogni funzione che elencava 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é è necessario tenerli aggiornati non è valida. Non è necessario tenerli aggiornati perché nessun programmatore serio li guarderà mai. Se c'è qualche domanda a 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 hai intenzione di aggiungere commenti inutili ridondanti, forse vale la pena scrivere un programma per generarli. Qualcosa di un investimento in anticipo, ma potrebbe salvare un sacco di scrivere lungo la strada.
All'inizio della mia attività, un'azienda per cui lavoravo utilizzava un programma pubblicizzato come "Scrive la tua documentazione per te! Documentazione completa per ogni programma!" Il sistema richiedeva che dessimo a tutte le variabili nomi sostanzialmente privi di significato e che quindi avessimo una tabella che fornisse un nome significativo per ogni variabile, quindi sostanzialmente ciò che la "documentazione automatica" faceva era sostituire il nome insignificante che ci costringeva a usare con un nome significativo. Quindi, per esempio - ha funzionato con COBOL - nel tuo programma avresti una linea che diceva
MOVE IA010 TO WS124
e genererebbero una linea 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 abbastanza facilmente documentazione altrettanto inutile. Leggi una riga come
a=b+c
e genera il commento
// add b to c and save result in a
Eccetera.
Cinque. Ottieni il meglio dalla 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 aveva affermato che avrebbero iniziato a misurare la produttività dei programmatori in base al numero di righe di codice prodotte a settimana. Quando ci hanno detto questo in una riunione, ho detto: Fantastico! Posso facilmente aumentare il mio punteggio. Non più scrittura
x=x+4;
Invece scriverò:
x=x+1;
x=x+1;
x=x+1;
x=x+1;
Loops? Lascia perdere, copierò e incollerò il codice dieci volte. Eccetera.
Quindi qui, se contano le righe di commenti, accorcia ogni riga e continua l'idea sulla riga successiva. Se c'è una modifica a ciò che accade nei commenti, non aggiornare il commento esistente. Inserisci una data su di esso, quindi copia l'intero testo e scrivi "Aggiornato" e una nuova data. Se il cliente lo mette in discussione, digli che hai pensato che fosse necessario mantenere la cronologia. Ecc. Ecc.