Dovrei cercare di persuadere il mio manager che il riordino del codice dovrebbe avere la priorità rispetto alle scadenze? [duplicare]

è il capo, è una sua decisione. E sono d'accordo con lui. Non cambiare MAI codice per il gusto di cambiarlo. Se c'è una ragione valida per il cambiamento (diciamo che le cose si comportano al di sotto dei requisiti così come sono) le cose dovrebbero cambiare, ma "Penso che non sia abbastanza carino" non è un valido motivo.
Il tuo zelo religioso (e questo è ciò che è in questa fase, o sembra essere) costerebbe denaro, introdurrebbe dei rischi (ogni cambiamento di codice rischia di rompere il prodotto, richiedendo più cambiamenti, più test, più ritardi). Non è mai una buona cosa.
Invece, prendi appunti e raccogli le modifiche quando e se le parti interessate dell'applicazione devono comunque essere modificate.

My manager has tight deadlines to meet.

La maggior parte sì.

The current project I am working on is currently on schedule

Buona. Continua così!

I've noticed a couple of quite significant areas in the code that are really badly written. (Bits of code get called two or three times, when they only need to be called once.)

Se questo non è un problema di correttezza o prestazioni, allora non sembra così male. Chiamare lo stesso codice due volte inutilmente è spesso meglio che chiamarlo una volta e memorizzare nella cache il risultato. Ho visto molti bug a causa di una logica di caching difettosa. Ma prendiamo in parola che questo è un codice errato.

The problem is, as far as my manager is concerned, the program works. As he sees it, there's no point making lengthy changes to code that will make us miss the release date, for no tangible improvement that he can see. He keeps saying "That's not a priority. It's working fine as it is."

Il tuo manager è corretto. Sei nel business di fornire valore alle parti interessate, non nel business della prettificazione del codice. Se non riesci a formulare una discussione sul fatto che rendere il codice più carino porti più valore alle parti interessate rispetto alla data di rilascio, allora non fare l'argomento.

Should I keep trying to persuade him?

No.

Should I just do what he suggests and leave it?

No.

Dovresti piuttosto cercare di convincere la tua gestione a pianificare una "pietra miliare di qualità del codice" dopo che la scadenza è stata rispettata . Quando le tue scadenze sono state rispettate e stai pianificando la prossima versione, la prima cosa che dovresti fare è pianificare un'analisi post-rilascio che analizzi in dettaglio cosa è andato bene e cosa è andato male. Ciò include l'analisi di rischi per il successo futuro , rischi come codice di scarsa qualità che è stato archiviato con problemi noti al fine di rispettare una scadenza . Utilizza il tempo dedicato al "traguardo di qualità" per mitigare tali rischi. Aiuterà se puoi arrivare a quell'incontro con un elenco accurato dei problemi che vorresti indirizzare.

L'argomentazione da fare è che così facendo, ti aiuti a garantire che il tuo gestore continui a rispettare le scadenze in futuro .

Ecco alcuni punti:

1. Ogni modifica causa più errori. La modifica di codice complesso causa più errori di quanti non possa mai risolvere. Idealmente lo si scriverà una volta e non lo si modificherà mai. L'aggiunta di nuovo codice è ok, ma la modifica della logica esistente causa più errori. Se il risultato finale è un disastro la prima volta che lo hai scritto, pensa a quanto sarà pessimo se lo modifichi senza ricordare tutte le regole che ti hanno dato il disordine originale.
2. Il codice complesso sembra sempre male. Il codice è complicato per un motivo. Codifica l'importante logica aziendale, e questo è sempre complesso. Tutto il codice complesso sembra un disastro per le persone che non conoscono le regole che il codice segue. Una volta che le regole sono conosciute, è un buon sistema logico che funziona correttamente. Dimenticherai le regole (o peggio, qualcun altro ha scritto il codice e non hai mai avuto le regole), e inizierai a pensare che l'importante logica aziendale sia un disastro. Pulire questo codice è un grosso errore.
3. Nel corso del tempo, le regole aziendali diventano obsolete . Ora hai un gran casino e metà delle regole codificate per il tuo software sono obsolete. È già tempo di riscrivere? Sicuramente NO. L'unico modo per sbarazzarsi delle regole aziendali che sono già codificate nel codice sorgente del software è scaricare l'intero sistema. Altrimenti finirai per guasti a cascata in cui un pezzo mancante di software attiva guasti in codice non correlato che ha funzionato correttamente negli ultimi 10 anni.
4. La manutenzione è un'attività difficile. Il mantenimento del caos richiede abilità. È necessario conoscere tutte le regole aziendali raccolte negli ultimi 10 anni per apportare eventuali modifiche. Dimentica uno di loro e il tuo cambiamento sta causando più danni di quanto non stia risolvendo. Un buon piano è inserire nuova logica, ma non modificare mai la vecchia logica. Rifattorizzare o riscrivere è un modo sbagliato di affrontare il problema. Devi iniziare a scrivere codice funzionante e non fidarti mai mai della possibilità di risolverlo in seguito; la possibilità non comparirà mai. Una volta codificato in codice, è concreto; è sempre lì e rompere è pericoloso.

Molti manager non capiscono il concetto di "debito tecnico" che è esattamente quello che stai cercando di impedire di costruire.

Il gestore è corretto se preso nel contesto di questa sezione che vorresti correggere, ma questo diventa davvero un problema quando molte sezioni si degradano nel tempo e altri sviluppatori entrano e si basano su di esso.

Quindi viene scoperto un bug in una parte del codice, ma viene risolto solo in una sezione, non nelle sezioni copia e incollate.

Anche se non sei ancora in diretta, ci sono altre cose che devi tenere a mente che probabilmente la gestione sta pensando.

Forse questa rilavorazione del codice significherà che una grande fase di test deve essere ripetuta. C'è anche la possibilità che introduci bug in una funzione precedentemente funzionante.

È compito tuo segnalare queste cose, ma è comunque la decisione del gestore.

Tuttavia, dovresti provare ad apportare modifiche al tuo processo di sviluppo per evitare questi problemi in futuro.

1. Identifica i problemi ripetuti e istruisci tutti gli sviluppatori su un metodo preferito. Tutti non lo faranno bene la prima volta, quindi preparatevi a prenderli in una revisione del codice. In questo modo, puoi dedicare del tempo a fare la modifica prima che un manager sappia che il codice funziona abbastanza bene / passa a ulteriori test.
2. Inizia il factoring # 1 nelle tue stime. Il tuo team migliorerà nel tempo, ma è meglio gestire le aspettative in anticipo.

Si spera che le scadenze siano state stabilite in base a quanto tempo gli sviluppatori pensavano di dover costruire e non qualche altro metodo arbitrario. Alcuni sviluppatori si sentono portatori di cattive notizie se fanno lunghe stime di progetto, quindi lo evitano essendo eccessivamente ottimisti.

Questa è una domanda soggettiva, ed ecco il mio punto di vista.

DOVRESTI cercare di persuaderlo. Il fatto che tu abbia scritto questa domanda qui risponde. Quanto dovresti provare è una domanda diversa ..

Pensa a diverse parti del sistema:

• Quanto sei lontano nello sviluppo di quel modulo?
• Quanto è probabile che lo stesso modulo venga modificato in modo significativo in futuro (modifiche specifiche).
• L'interfaccia pubblica del modulo sta cambiando?

Basta porsi queste domande e creare i tuoi pro / contro.

Ad esempio se il modulo è quasi finito e probabilmente verrà modificato dopo il rilascio, lascerò il refactoring per dopo. Ma se è nella fase iniziale, e le specifiche non sono suscettibili di cambiare, refact ASAP. Perché le specifiche cambieranno e, dopo non aver guardato il codice disordinato in due anni, avrai difficoltà a implementare nuove specifiche. i cambiamenti. Potrebbe essere così grave che tu decida di scrivere il modulo da zero e di utilizzare solo alcune parti di codice dalla precedente versione del modulo.

Ci sono alcuni accorgimenti che possono convincere il manager a lasciarti refactoring.

• trova un bug nel codice esistente. Puoi dedicare tempo al refactoring durante la correzione del bug.

No, non dovresti. Le scadenze sono più importanti del codice di riordino , perché probabilmente non hai idea del motivo per cui la scadenza è stata impostata in primo luogo. Forse devi finire prima del tuo concorrente, che ruberebbe i tuoi clienti. O alcune leggi stanno entrando in vigore. O sta diventando troppo costoso per il tuo CIO affamato. Oppure ...

Se pensi che rilasciarlo sarebbe un grande rischio, allora spiegalo al tuo manager. Le ragioni valide sono: i dati dei clienti potrebbero essere persi, la reputazione dell'azienda ne risentirà o qualcos'altro ciò che avrebbe un impatto negativo sulla società. Ma il tuo manager deve ponderare i rischi e le opportunità e deve decidere se vale la pena spostare la scadenza.

Ma chiedi al tuo manager di pianificare alcune risorse extra la prossima volta , in modo che il software non diventi un monolito grande e non mantenibile. Quindi il tuo manager può mantenere la sua scadenza e avrai tempo sufficiente per creare un bel software.

Qualunque cosa tu faccia, ti preghiamo di non dare ai manager una ragione per pensare ai programmatori come persone in torri d'avorio che non sanno nulla di affari.

Aggiornamento perché ho letto che si tratta di un'applicazione di nuova scrittura :

La tua prima priorità dovrebbe essere quella di fare un'analisi delle cause alla radice per scoprire perché quel codice errato è stato scritto in primo luogo. I requisiti sono cambiati? Uno dei programmatori non è abbastanza esperto? La scadenza provoca un atteggiamento send-and-forget?

Problemi nel codice possono creare scadenze imprecise per la manutenzione in futuro, specialmente se i problemi non sono documentati correttamente con commenti nel codice.

La maggior parte dei manager ha una comprensione tecnica sufficiente a consentire loro di svolgere il proprio lavoro, ma non sapranno come codificare, né con loro capiscono come i problemi possano influenzare le timeline in futuro.

Mi rivolgerei al tuo manager per iscritto e delinei loro ciò che può (e probabilmente succederà) accadere lungo la strada consentendo ai problemi di rimanere intatti e irrisolti. Questo può includere timeline che saranno influenzate quando lo modificherete in futuro per aggiornamenti, prestazioni scadenti dell'applicazione (con conseguente scarsa soddisfazione dell'utente), ecc. Quando capiscono l'impatto dei problemi e prendono la loro decisione, accettarla e andare avanti . A questo punto avrai fatto il tuo lavoro come un programmatore credibile e affidabile (con la prova scritta che hai), e ora la palla è nel loro campo per assumersi la responsabilità per qualsiasi problema associato al problema che hai delineato.