Come convincere il mio capo a migliorare la qualità del codice? [duplicare]

16

Il luogo per cui lavoro è un fornitore di servizi. Abbiamo molti servizi, che sono scritti per gestire la scadenza, quindi il loro codice è davvero terribile:

  • Nessuna convenzione di codifica, tutti codici nel suo stile
  • Nessun test di unità (che è davvero pessimo)
  • Nessun refactoring (che è veramente peggio)
  • Nessuna build di automazione / implementazione

etc

e questi codici sono usati ancora e ancora, quindi il codice cattivo continua a diffondersi in tutto il mio dipartimento.

Voglio davvero impostare una qualità standard per il nostro codice, richiedendo a tutti di seguire le "regole": ogni riga di codice che non segue la convenzione verrà rifiutata, e ogni funzione di codice che non supera il test di unità sarà non essere impegnato, ... Ma non so come convincere il mio capo a permettermi di farlo. Sono relativamente nuovo, le persone che ispirano le mie opere sono davvero difficili, e penso che sia più facile se il mio capo mi supporta per questo.

Grazie mille per i tuoi consigli

    
posta Vimvq1987 15.01.2011 - 17:41
fonte

8 risposte

22

Non vorrei iniziare dal tuo capo. Sono certo che altri sviluppatori della tua azienda sono ugualmente preoccupati per la qualità del tuo codice: siediti con loro durante la pausa pranzo, discuti il problema e concorda su una guida allo stile condivisa.

Lavorare con le nuove convenzioni di codifica per un po 'di tempo, quindi presentare i risultati durante un incontro: "insieme a [compagni coraggiosi], abbiamo iniziato a utilizzare queste convenzioni [collegamento a un file di specifiche], ha davvero migliorato la nostra produttività e è più facile distribuire le attività e individuare i bug durante le revisioni del codice ".

È probabile che la ridotta entropia della convenzione di codice, insieme a tecniche soft come riesaminare con entusiasmo richieste di unione più ordinate, sarà sufficiente per condurre i tuoi restanti collaboratori sulla strada giusta.

Se questo non dovesse funzionare, avrai raccolto abbastanza dati empirici per dimostrare al tuo capo come uno stile coerente porti a software più stabile e comprensibile - e potresti proporre il controllo dello stile come prerequisito per l'unione.

Se lei è d'accordo, puoi ripetere la procedura per gli altri problemi che hai menzionato - ho suggerito di affrontare lo stile di codifica in primo luogo perché non ci sono spese extra iniziali.

    
risposta data 15.01.2011 - 18:07
fonte
11

Spiegagli il debito tecnico e perché è importante tenerlo sotto controllo facendo "acconti" tutto il tempo. Se non lo fai, dovrai passare tutto il tempo a pagare l'affitto e non fare nulla.

Mi piace molto quella metafora dato che parla direttamente ai loro portafogli.

    
risposta data 15.01.2011 - 19:53
fonte
6

È tutto a costo di beneficiare. La maggior parte dei dirigenti non riesce a vedere che, impiegando un po 'di tempo, sforzi e denaro per sviluppare queste cose nei loro gruppi di sviluppo possono premiarli con costi inferiori in seguito. Pianificano solo i costi immediati e prendono il percorso più veloce e più economico per il momento immediato. Cercare di cambiare questa mentalità nella maggior parte degli ambienti aziendali richiede molto tempo, sforzi e dimostrazioni dopo aver dimostrato i vantaggi finanziari di questi nuovi approcci fino a quando non affonda definitivamente.

    
risposta data 15.01.2011 - 18:08
fonte
3

L'unico buon modo per convincere il management a fare o non fare qualcosa è mostrare come influisce sulla bottom line.

Tu e il tuo team e / o responsabile tecnico dovete dimostrare come le convenzioni di codifica, i test unitari e gli strumenti di build / distribuzione automatizzati consentiranno di risparmiare tempo per il vostro team o migliorare la produttività. Per giustificare il refactoring del tempo di spesa, è necessario mostrare come trascorrere ora in ora per ripulire il codice esistente senza aggiungere nuove funzionalità farà risparmiare m ore di implementazione e debug in seguito (dove m > n).

    
risposta data 15.01.2011 - 18:37
fonte
3

Penso che potresti dover ricordare che l'obiettivo della tua azienda non è probabilmente quello di generare codice bello o perfetto. Personalmente, ritengo che gli standard di codifica (soprattutto quelli rigorosi) siano più uno strumento di microgestione che un utile contributo alla qualità dell'applicazione. Nella maggior parte delle situazioni, gli standard di codifica dovrebbero essere estremamente minimi.

Ad esempio, quelli che sostengono che avere uno standard per stabilire se la parentesi graffa di apertura vada su una nuova riga in qualche modo aumenta la leggibilità del codice in qualche modo sciocco. La coerenza è buona, sembra carina, ma puoi davvero sostenere che in realtà crei un valore aggiunto per l'organizzazione?

Per quanto riguarda il refactoring: questa è solo una di quelle cose che è semplicemente meglio chiedere il perdono che il permesso. Ti impediscono attivamente di refactoring mentre vai avanti? Veramente? Spesso vedo sviluppatori in attesa di una tavoletta di pietra dalla cima della montagna per impiegare buone pratiche di codifica come il refactoring quando hanno solo bisogno di andare a farlo. Se il tuo capo sta guardando da dietro le spalle e schiaffeggia la parte posteriore della testa quando sembra che tu possa essere refactoring, ALLORA potrebbe esserci un problema. Raramente ho visto un negozio, però, che i programmatori non hanno abbastanza autonomia per farlo da soli. Ricorda solo di includere il tempo nelle stime.

Test delle unità: se la mancanza di test delle unità stava creando problemi di qualità, allora non penso che sarebbe difficile venderli al tuo capo. Se non lo è, allora perché ti lamenti? Basta suggerirlo, creare il tuo caso e andare avanti con la tua vita.

La linea di fondo è che dovrai fare il tuo caso in termini di bottom line per l'azienda. Tutte le cose che suggerisci sono solo un mezzo per raggiungere un fine, e quella fine è un'applicazione di qualità sufficiente per soddisfare le esigenze degli utenti. Se non riesci a trovare una giustificazione in termini di problemi con le versioni correnti (qualità o tempo di consegna), potresti considerare che sei ossessionato dai tuoi strumenti invece del prodotto di lavoro. Se è POSSIBILE trovare giustificazioni in termini di risultati finali, basta puntare a quei reclami e al loro costo per l'azienda e legarli a qualsiasi pratica di codifica che si possa offrire per rimediarli.

In conclusione: non cercare di trasformare il tuo problema nel problema del tuo capo. Prendi uno dei suoi problemi e spiega come risolverli con le migliori pratiche.

    
risposta data 16.01.2011 - 00:12
fonte
2

Forse stai cercando di fare troppo in un solo passaggio. "Ogni linea di codice che non segue la convenzione verrà respinta", potrebbe essere piuttosto intimidatorio per le persone che sono abituate alla libertà di farlo a modo loro. Sospetto anche che suoni troppo controllati, brevi parti di codice con poche interazioni con altri sistemi non abbiano bisogno di un alto livello formale di ingegneria del software, e probabilmente non è conveniente applicare SE troppo profondamente.

Forse, il miglioramento incrementale dell'ambiente / cultura delle imprese SE è più fattibile. Trova alcune riforme relativamente non controverse e lascia che il loro valore diventi evidente, quindi spingi per il prossimo passo.

    
risposta data 15.01.2011 - 18:31
fonte
2

Questo dipende;)

Come è la tua storia di consegna dei prodotti? Offri la funzionalità desiderata in tempo, in un prodotto stabile (per stalla intendo dire, gli utenti finali che non riescono a vedere le cose terribili che accadono all'interno lo percepiscono come stabile)?

In caso contrario, chiederei al mio capo, se è soddisfatto del prodotto che stai consegnando. Se lo è, troverei un altro lavoro. Ma molto probabilmente, non lo è. E poi lo illuminerei dicendo che ci sono processi che possono garantire quelle cose.

    
risposta data 15.01.2011 - 18:32
fonte
0

Vedi Steve Mcconnel " Il business case per migliori pratiche software e La frutta bassa appesa dello sviluppo del software .

Il primo mostra miglioramenti di produttività, pianificazione e difetti.

Companies that invest in post-gold rush development practices have found that their investments pay off. In 1994, James Herbsleb reported that the average “business value” (roughly the same as return on investment) for 13 organizations that had taken on systematic improvement programs was about 5 to 1, with the best organizations realizing returns of 9 to 1. In 1995, Neil C. Olsen reported similar returns for organizations that had made significant investments in staffing, training, and work environments. In 1997, Rini van Solingen reported that the average ROI was 7 to 1 with the best organization realizing returns of 19 to 1. In 2000, Capers Jones reported that the return on investment from process improvement could easily go into double digits (i.e., returns greater than 10 to 1). A recent analysis by Watts Humphrey found that the ROI for improved software practices could be in the neighborhood of 5 to 1 or better...

Il secondo ha "LHF [low handing fruit] che non sarà Resistenza da Upper Management" che elenca Standard di codifica , Daily Build e Test di fumo e Test-First Coding , tre problemi che hai chiesto.

Steve McConnell describes strategies that produce improvements in schedule, quality, and development costs in the short term. McConnell identifies the specific technical practices that produce the highest returns on investment, the lowest risks of adoption, and the shortest paths to more successful software projects. McConnell describes the theory behind short-term vs. long-term improvement strategies and presents tips for maximizing your chances of success in adopting these strategies...

    
risposta data 30.01.2011 - 05:14
fonte