Consiglio: come convincere il mio team appena informato a sfidare a scrivere il codice base da zero

8

Lavoro in un MNC piuttosto famoso e il modulo in cui lavoro è stato assegnato a un nuovo "lead". La base di codice è piuttosto grande (~ 130 K o più, con dipendenze inter di altri moduli), ma stabile - alcune parti sono diventate brutte nel corso degli anni, ma è in condizioni provvisorie. (I nostri prodotti sono in corso da anni su di loro, anche nuovi). Il problema è che la nostra guida vuole riscrivere il codice da zero , per includere "granularità più fine e un design proattivo".

So che nelle mie budella non è una buona idea, ma come posso convincerlo / il resto della squadra (che è molto più anziano di me in termini di anni di esperienza), senza sembrare troppo pedante ( Non dovrai riscrivere, dato che Joel e altri hanno articoli chiari che lo proibiscono)?

Ho un buon rapporto di lavoro con la persona interessata, e non voglio rovinarlo, ma nemmeno voglio essere parte di una decisione che ci tormenterebbe sicuramente per anni a venire !! Qualche suggerimento per un approccio più mite ma efficace? Anche i resoconti su come hai affrontato una situazione del genere a tuo piacimento mi avrebbero aiutato molto!

EDIT: Il codice base di cui sto parlando non è un prodotto / GUI, ma a livello kernel con tutte le funzionalità critiche per il nostro prodotto. Spero che ora tu sappia perché sembro così apprensivo !!

    
posta TCSGrad 15.03.2011 - 14:58
fonte

7 risposte

8

Fai i conti con lui insieme:

Dal lato del debito:

  • quanto tempo ci vorrà per ricreare le funzionalità che hai adesso. Quanto costa quel (devs + overhead)

  • quanto l'azienda perde per non essere in grado di implementare nuove funzionalità / correzioni di errori o solo a una velocità molto più lenta?

  • qual è il rischio di non essere in grado di completare la riscrittura e di ricadere sulla base della sorgente attuale dopo n-mesi? Compreso il rischio di uccidere il prodotto tutti insieme.

  • Quanto ci vorrà prima che il nuovo code base sia brutto come quello attuale?

Dal lato dell'asset:

  • quanto sarà migliore il codice dopo la riscrittura (misurata in costi di manutenzione risparmiati al mese)

Aggiungi tutto, possibilmente facendo un confronto scenario migliore / peggiore.

Alla fine avrai una risposta. Se ignora la risposta, parla con il suo capo.

    
risposta data 15.03.2011 - 15:28
fonte
13

Obbligatorio: Cose che non dovresti mai fare, parte 1 (L'hai visto, ma nel caso qualcuno lo trovi domanda e non ha.)

La riscrittura da zero è molto allettante per gli sviluppatori. Nessuno vuole lavorare sul codice legacy, tutti vogliono scrivere un nuovo codice sexy. Ma alla fine della giornata si tratta di ciò che è meglio per il business. Perché è necessaria una riscrittura? Possono presentare questo caso in modo chiaro, dimostrando un valore aggiunto per l'azienda?

Non dovresti convincerli non a spendere risorse. Dovrebbero convincere la società a spendere risorse

    
risposta data 15.03.2011 - 15:12
fonte
8

Quanto bene il tuo approccio di test copre il codice base? Che ne dici di test unitari?

Se non si trova lì, suggerisci che ogni codice deve essere riscritto solo una sezione alla volta e che qualsiasi sezione in riscrittura ha una copertura del codice di test delle unità quasi completa (90% +). Una volta fatto, avrai definito una parte del codice che è ben definita (potremmo testarla) e ha anche un'interfaccia conosciuta.

A quel punto, riscrivere quel codice è un rischio molto più basso. Gli errori dovrebbero essere intercettati da test unitari / altri test e presumendo che anche il controllo del codice sorgente possa essere facilmente ripristinato.

La riscrittura in blocchi più piccoli consente anche a te e al tuo team di avere un tocco più preciso per una riscrittura completa. Conosci entrambi cosa stai facendo? Sei uno di voi troppo pessimistico / optomistico?

    
risposta data 15.03.2011 - 15:06
fonte
2

Ci sono alcuni fattori rilevanti da considerare:

  • Il fatto che funzioni come gli utenti è un'indicazione per il refattore piuttosto che per la riscrittura
  • Se hai dei test unitari, sicuramente refactoring piuttosto che riscrivere. Se non lo fai, allora questo livella lo sforzo tra il refactoring e la riscrittura (supponendo che il tuo obiettivo sia di avere test unitari per il sistema risultante). Se non si dispone di test unitari e tutto il codice si trova nel livello della GUI, potrebbe essere più veloce da riscrivere, soprattutto se la funzionalità è per lo più interrotta. Questa è la mia esperienza.
  • Se il tuo obiettivo è cambiare completamente piattaforme (codice non gestito - > .NET o Windows - > Linux o PHP - > python, ecc.) allora questo è un argomento ovvio a supporto della riscrittura.
risposta data 15.03.2011 - 15:36
fonte
0

Dì solo "NO". Sii convincente, ma sii disposto a dire "Non solo non sei corretto riguardo ai suoi benefici, ma hai torto perché è uno spreco di sforzi umani".

    
risposta data 15.03.2011 - 15:09
fonte
0

Dov'è il business case per una riscrittura? Hai una base di codice che sta riempiendo un bisogno. Certo, potrebbe non essere perfetto, ma rappresenta un investimento sostanziale in termini di tempo e risorse. L'unica volta che una completa riscrittura è giustificata è quando la qualità del codice è così grave che sta causando alla propria organizzazione di perdere denaro o opportunità di business. Uno ha bisogno di ricordare il vecchio adagio, se non è rotto, non aggiustarlo!

    
risposta data 15.03.2011 - 16:52
fonte
0

Acquista il maggior numero di cortometraggi sul titolo possibile. Se la direzione accetta di suicidarsi, almeno dovresti ricavarne dei soldi. Dopotutto, sarai presto in strada dopo aver fatto il pieno.

    
risposta data 16.03.2011 - 05:06
fonte

Leggi altre domande sui tag