Come sviluppatore, puoi dire al tuo project manager che un'applicazione non è lavorabile ? Oppure, se sei un project manager, come ti occorrerebbe questo per essere costretto? Non si tratta di "come lavorare su un progetto scadente", si presume che non sia possibile.
Posso fornire un esempio della situazione se qualcuno pensa che sia importante, ma sto cercando di evitare le soluzioni proposte per "arrancare".
Quando leggo le risposte, ho la sensazione che molte persone sottovalutino quanto può essere cattivo e intrattabile un codice base.
Solo per illustrare ciò, sto lavorando nel luogo in cui l'intero Progetto è nato da un file "principale" di centinaia di migliaia di LOC. ... la parte peggiore è che la bestia è diventata sempre più grande nel tempo:
Prima di iniziare a lavorare, non immaginavo che potesse esistere qualcosa di così catastrofico. I costi per la manutenzione sono ovviamente sbalorditivi e tutto è fatto per cercare di minimizzare i cambiamenti.
Dal lato, perché tutti sanno che questo è un incubo, viene creato un nuovo software "2.0", ma è così grande che rappresenta almeno una dozzina di anni uomo.
Penso che dovresti semplicemente parlarne al tuo manager. Parlare fa meraviglie. Ciò che è importante per loro è capire quale sia lo stato attuale. Quella manutenzione è davvero estremamente difficile, richiede molto tempo, è soggetta a errori, il tutto a causa del codice errato. Inoltre, continuare a lavorarci aumenta di solito anche il suo debito tecnico perché aggiungiamo mucchi di merda basati su altre pile di merda. ... ma nel frattempo, dato che è una merda produttiva che guadagna i soldi della compagnia, dobbiamo affrontarla, anche se è dura e improduttiva.
L'altra cosa divertente è che qualsiasi idiota può trasformare un normale codice sorgente in una pila di merda. Tuttavia, il codice più crappier, il più intelligente che si occupa di esso deve essere. Il lato negativo è che l'idiota è apparso produttivo dal momento che ha aggiunto caratteristiche, e quello brillante improduttivo dal momento che ha a che fare con il caos del suo predecessore. Solo i bravi manager con esperienza tecnica possono capire cosa sta succedendo.
Molto raramente c'è un caso in cui vi è un requisito impraticabile, di solito è un "non voglio", essendo formulato "non posso".
Non usare mai assoluti come "Can not" e "Unworkable" a meno che tu non possa provarlo e sei assolutamente certo di aver esaurito tutte le opzioni. Sembri un idiota o una tana quando ha finito. Un certo numero di volte mi è stato detto "Questo non può essere fatto ..." e l'ho visto funzionare alcuni giorni o settimane dopo, lasciando gli sviluppatori a guardare male. La prossima volta mette loro e il resto della squadra in una posizione davvero difficile, come si dice "non può" e non si crede.
Se proprio non ci riesci, fornisci dei sostituti a titolo oneroso, con i vantaggi e gli svantaggi di ciascuno. Segui questo con una discussione aperta e onesta. Concentrati sulla ricerca di una soluzione, non sulla definizione del problema.
Il tuo manager non ti ha assunto per creare problemi. Ti ha assunto per creare soluzioni. Non prendere mai un problema al tuo manager che non hai (o almeno cercato di ottenere) una soluzione per.
Bene, penso che fondamentalmente tutto in realtà può essere fatto, è solo una questione di quanto tempo ci vuole. Su una base di codice errata, tutto richiede naturalmente molto tempo. Quindi, quando stai dicendo che qualcosa è impraticabile , intendo, intendi che ci vorrà troppo tempo per implementare una determinata funzionalità affinché sia praticamente fattibile. So che un manager potrebbe pensare che sia solo un piccolo problema, sai, "abbiamo già altre funzionalità come questa, come può essere così difficile?".
Se il tuo manager è il tipo di persona che non capisce quando gli spieghi gli anti-pattern e gli odori nel codice, dovrebbe almeno capire tempo e denaro. Quindi, crea un piano valido e solido su come implementare la funzionalità richiesta, se davvero lo fai. Prenditi il tuo tempo per analizzare il codice e dividere il progetto in sotto-attività gestibili di non più di circa 8 ore. Disegna un diagramma di Gantt delle fasi del progetto. Quando non è possibile fornire una stima temporale accurata, fornire almeno un intervallo: 10-30 ore è meglio di niente. Spiega il caso ottimale quando occorrono 10 ore e fai sapere al tuo manager le condizioni dello scenario peggiore di 30 ore. Poi, forse, dì qualcosa del tipo "Data la qualità generale del codice, sono abbastanza sicuro che ci troveremo più vicini a 30 o 10 ore. Inoltre, si noti che questa attività si trova sul percorso critico del diagramma di Gantt, quindi quando questo è in ritardo , l'intero progetto è in ritardo. "
Finirai con il tuo progetto A prendendo, per esempio, 100 ore. Quindi escogitare un altro piano, scrivendo la funzionalità richiesta da zero. Questo potrebbe essere difficile da includere nel tuo progetto esistente se / quando anche le tue interfacce sono cattive, quindi ricorda di includere il tempo di integrazione dei due sistemi insieme. In questo modo potresti finire con un progetto B che richiede, per esempio, 90 ore. Probabilmente è troppo vicino al piano originale per il gestore per comprarlo, ma poi dovresti spiegare loro come la nuova base di codice sarebbe più semplice da modificare ulteriormente: se hai implementato la caratteristica 2 in cima al progetto A, ci sarebbero volute 30 ore , ma se hai fatto lo stesso con il Progetto B, ci sarebbero volute solo 5 ore. A questo punto sono abbastanza sicuro che il tuo manager inizi a vedere le cose in prospettiva.
L'orgoglio professionale (il cattivo tipo, non il buon genere) spesso fa sì che i programmatori sentano di dover arrancare. In pratica, trovo che sia meglio stare insieme al project manager (fare discussioni più dure come questa durante il pranzo spesso toglie la pressione, IMHO) e discutere le tue preoccupazioni. Fai sapere loro quali problemi, forse insormontabili, hai trovato. Proponi una sorta di compromesso, se possibile umanamente. Ad esempio, "Non possiamo aggiungere la funzione di Foobar nel tempo assegnato, ma l'implementazione di FizzBuzz impiegherà un quarto del tempo e ci darà il 75% delle funzionalità."
Qualsiasi project manager degno di questo nome vuole sapere queste cose e sarà aperto per discutere delle preoccupazioni soprattutto se si dispone di una soluzione.
Ogni volta che qualcuno assegna un compito per te in quel progetto, fai una stima onesta e accurata dello sforzo. Se la cosa è davvero "impraticabile", come dici tu, quelle stime, in un modo o nell'altro, sommeranno una somma così alta che il tuo project manager prenderà in considerazione di fermare il progetto.
(Oppure assegnerà il compito a qualcun altro che non pensa allo stesso modo in cui lo fai per la cosa).
Si desidera iniziare facendo una sorta di analisi costi-benefici. Non capirai davvero quanto sia importante ricominciare da capo senza essere in grado di dimostrare che questo è l'approccio migliore da seguire. Questo non vuol dire che l'istinto del tuo intestino sia necessariamente sbagliato, ma devi davvero determinare da solo se è un caso di riluttanza o di orgoglio professionale che ti trattiene dal lavorare su un prodotto esistente.
Per quanto possa sembrare una base di codice esistente, è necessario ricordare che probabilmente c'è già un notevole investimento in esso che il tuo datore di lavoro non vorrà che tu passi via senza una buona causa. La realtà è che anche se hai una buona ragione per voler buttare fuori il prodotto esistente, devi giustificare il tuo ragionamento, e per fare in modo che funzioni sia per il tuo team che per l'azienda, avrai bisogno di essere in grado di mostrare non solo quanto costa il prodotto e potrebbe salvare se fatto in un altro modo, sarà anche necessario dimostrare che esiste un percorso verso il tuo "ideale d'oro" che non sarà eccessivamente costoso, e puoi assicurati che questo costo extra per il percorso venga conteggiato rispetto a tutti i potenziali risparmi che potresti pensare di poter mostrare per la tua riscrittura.
Quello che sto dicendo è che ci sarà molto lavoro. Hai bisogno di mostrare che cosa costano i prodotti per mantenerli così come sono, quanto costerebbe migliorarli per renderlo di migliore qualità, cosa avrebbe voluto conservare per prepararsi a passare a un nuovo prodotto, quanto costerebbe a sviluppare un nuovo prodotto e ciò che il nuovo prodotto dovrebbe costare da mantenere.
La realtà è che nessun prodotto è effettivamente TROPPO difficile da mantenere. Tutti i prodotti possono essere migliorati con un approccio attento al refactoring e al miglioramento graduale nel tempo. Anche questo sarà molto lavoro, ma con meno probabilità di essere costoso o impegnativo rispetto al tentativo di giustificare il lancio dell'asciugamano semplicemente perché il codice attuale è difficile da mantenere. Quando sento qualcuno dire che il codice non è mantenibile, quello che sento è che è probabile che il codice non sia supportato da test unitari, probabilmente non supportati dall'automazione di test / build, probabilmente molta duplicazione del codice e probabilmente molte classi e metodi che stanno tutti cercando di fare troppo. Questi sono tutti problemi che possono essere risolti in larga misura se viene applicato un piccolo sforzo per affrontarli.
In alcuni casi molto rari, potresti avere un codice con dipendenze su cui non hai alcun controllo. Sto parlando di vecchi prodotti di terze parti che vengono utilizzati dalla tua base di codice, ma che sono stati dimenticati perché sono stati aggiunti anni fa e tutti gli esperti se ne sono andati senza documentare il motivo per cui questi prodotti erano in uso. In questi casi potresti essere giustificato a iniziare qualcosa di nuovo, tuttavia a seconda delle dimensioni del tuo prodotto è raro che ciò giustifichi la riscrittura di un intero prodotto da zero.
Non penso che tu possa davvero trovare una risposta definitiva alla tua domanda. Gran parte di questo genere di cose si riduce a te, alla tua squadra, alla cultura aziendale, al tempo, ai finanziamenti disponibili e ad un intero casino di altre cose. Questo è il tipo di cose che devi davvero sederti con il tuo manager per discutere e per lavorare come team per determinare il percorso migliore.
Non c'è mai veramente un progetto che sia completamente impraticabile se può essere progettato o immaginato - la parte non lavorabile può venire dalle scelte fatte per implementare il prodotto.
Ad esempio, è perfettamente corretto affermare che è non lavorabile a sviluppare un'applicazione iPad con solo una macchina Windows e una copia di Visual Studio. A parte situazioni del genere, è meglio pensare alle cose in termini di costi e opportunità.
Pensa alle soluzioni al potenziale problema e sii aperto con il tuo product manager su ciò che è difficile, perché, come potresti risolverlo e su come potresti aver bisogno di aiuto per risolverlo. (A volte può essere una questione di non conoscere abbastanza bene una particolare tecnologia per sapere in cosa è veramente bravo e in che cosa non va bene.)
Non c'è davvero modo di rispondere a questo senza specificità. Quanto è importante questo progetto per l'azienda? Quanto tempo e denaro sono già stati spesi? Stai proponendo di abbandonare completamente il progetto o è possibile ridurne l'ambito, aumentare il periodo di tempo o aggiungere più persone?
Se questo è il prodotto principale dell'azienda, e abbandonarlo vuol dire che la compagnia va a fondo, quindi tutto ciò che puoi fare è dimettersi. D'altra parte, se puoi suggerire qualcosa di costruttivo, ad esempio eliminando alcune funzionalità o assegnando più tempo e più persone, è perfettamente ragionevole occupartene con il gestore.
Come Michael ha appena suggerito, il punto cruciale è: perché questo progetto è impraticabile?
Un project manager vuole solo saperlo. Dammi almeno un motivo davvero convincente per rinunciare e lo farò. Proverò a limitare al minimo il danno e fermerò lo sviluppo.
Come potete immaginare, è molto, molto difficile convincere un project manager che un progetto in corso debba essere fermato a causa di considerazioni tecniche. Anche un pasticcio totale di codice può essere migliorato o riscritto.
Diverso è il caso delle considerazioni di business. Un progetto può perdere la sua ragione di esistere durante lo sviluppo. Forse un nuovo concorrente ha già occupato la nicchia desiderata, forse l'investitore non ha più denaro. È possibile essere motivi aziendali per interrompere un progetto.
Il mio suggerimento molto personale è quello di identificare con la massima cura i problemi con il progetto, spiegare al responsabile del progetto perché rendono il progetto impraticabile e cosa è possibile fare per risolverli.
Sii costruttivo. Porta in tavola ogni soluzione che trovi. Fai del tuo meglio per salvare il progetto anche se pensi che dovrebbe essere ucciso.
L'ultima decisione deve essere lasciata all'investitore e al project manager. Se la tua spiegazione è convincente, interromperanno il progetto.
Questo tipo di problema è solitamente un disaccordo sul tempo e sulle risorse richieste e ci sono molti modi per negoziare per più tempo, più risorse, un diverso percorso di sviluppo o obiettivi diversi.
Se non riesci a negoziare un piano di lavoro soddisfacente, la tua posizione di riserva può sempre essere "questo progetto non può essere fatto da me (con queste risorse)". Se ciò non annulla il progetto o lo sposta sul piatto di qualcun altro, è difficile che la gestione ti ritenga responsabile di un errore.
In ogni caso, l'importante è che tu non accetti un'attività che non puoi completare solo per placare il tuo manager.
Leggi altre domande sui tag project-management legacy bad-code