Cosa fare quando i tuoi colleghi non valutano la manutenibilità del codice [duplicato]

Naviga le tue risposte
12

Ho lavorato nello stesso reparto di sviluppo software per alcuni anni. A quel tempo, la permanenza media di uno sviluppatore è stata di 6-9 mesi. Una manciata è in circolazione da oltre 2 anni, ma la maggior parte dei nostri 20 o così sviluppatori vanno e vengono a un ritmo relativamente alto.

Di conseguenza, la maggior parte dei nostri progetti sono diventati incubi di manutenzione. Gli appaltatori arriveranno, codificheranno alcune patch release e se ne andranno.

Il nostro reparto ha linee guida per lo sviluppo (facciamo TDD) ma non sono applicate.

Recentemente, ho sollecitato il nostro dipartimento a produrre codice più gestibile. Ho richiesto revisioni obbligatorie del codice e TDD obbligatorio. La direzione concorda pienamente con me ... in teoria.

In pratica TDD esce sempre dalla finestra. La giustificazione è sempre che, nel nostro dominio, abbiamo bisogno di consegnare ORA.

Continuo a dire ai colleghi che stiamo solo scavando una buca per noi stessi e che il nostro attuale approccio allo sviluppo del software sta costando un sacco di soldi al nostro dipartimento ... ma sembra non essere ascoltato.

Che cosa posso fare per convincere i miei colleghi a vedere il valore della manutenibilità del codice? Come posso spiegare che le vittorie a breve termine senza una visione a lungo termine non sono sostenibili?

    
posta MetaFight 12.04.2013 - 19:13
fonte

3 risposte

16

Non sono i tuoi colleghi che devi convincere.

Se la gestione è d'accordo con te, applicherebbe le revisioni del codice e TDD. Così com'è, stanno solo annuendo con la testa per farti smettere di infastidirli.

Vedo due opzioni qui:

  1. Fai un passo al senior management su quanto l'alto turnover dei dipendenti e molti report sui bug dei clienti stiano costando loro dei soldi. Includi nel tuo campo una soluzione fattibile che preveda revisioni forzate del codice, TDD, ecc. Avvolgiti in un orizzonte temporale e prometti di fornire. Potrebbero farti diventare un manager incaricato di risolverlo.

  2. Lascia. Se sai che sta per crollare, perché restare?

risposta data 12.04.2013 - 19:40
fonte
4

Vedo che questo accade molto quando uno sviluppatore lavora su un progetto esclusivamente per un lungo periodo di tempo. Sanno dove sono le insidie e come aggirarle, e quindi generalmente non si preoccupano che esistano. Il numero uno per convincere gli sviluppatori a utilizzare standard di codifica e best practice comuni è quello di farli lavorare di volta in volta sul codice di altri sviluppatori. Vedranno abbastanza rapidamente il valore del codice di autocertificazione, la corretta gestione delle eccezioni, la pulizia del codice morto, ecc. Fai questo una o due volte e i tuoi colleghi sviluppatori saranno felici di adottare queste pratiche.

Con i gestori, di solito è una storia diversa. I buoni manager risponderanno ai reclami degli sviluppatori e cercano in modo proattivo dei modi per migliorare le pratiche di codifica della tua azienda. I cattivi manager non si preoccuperanno, a patto che il prodotto esca in tempo. Per questi tipi di manager, avrai mostra loro cosa c'è di sbagliato nel modo in cui stai facendo le cose. Spiega che occorrono da due a tre volte il tempo necessario per addestrare un nuovo sviluppatore, o che ci vogliono giorni per trovare bug che potrebbero essere risolti in pochi minuti, tutto perché la base di codice è un disastro. Se possibile, mostra casi reali e concreti dei costi associati al codice mal gestito.

    
risposta data 12.04.2013 - 23:18
fonte
-1

Vite che spiega le cose alle persone .

Potrebbe essere più semplice ottenere la gestione / altri sviluppatori a bordo con qualche tipo di integrazione continua. Quindi, se i test non passano, il codice non viene spedito. Fine della storia.

    
risposta data 12.04.2013 - 23:30
fonte

Leggi altre domande sui tag

Che cosa sta succedendo nel mondo delle tecnologie server-side per quanto riguarda il boom delle app mobili? Preparare il piano di consegna del codice sorgente [chiuso]