Come si ottiene che gli sviluppatori vogliano scrivere un buon codice di cui possano essere orgogliosi? [chiuso]

Risposta breve:

Se non hai il tempo di farlo correttamente ora, avrai il tempo di farlo correttamente in seguito?

Risposta lunga:

La manutenzione è il 70% dello sforzo nello sviluppo di software. Più debito tecnico si accumula nel codice, maggiore è il livello di manutenzione richiesto. I bug costano più sforzo per sistemare più a lungo rimangono non fissati, a causa della necessità di riacquisire la conoscenza del codice, i costi sostenuti dai clienti che si occupano di questi bug, il costo di distribuzione delle correzioni, ecc ...

Ritardare il bug fixing è costoso. Devi uscire dal ciclo di feedback negativo di "nessun tempo":

1. Non c'è tempo per scrivere un nuovo buon codice, affrettiamoci il più possibile e spediamo il codice errato
2. Il codice errato ha molti bug, ora dobbiamo correggerli
3. Poiché il codice errato è stato scritto qualche tempo fa e la correzione deve essere distribuita al cliente, il suo fissaggio richiede molto tempo
4. Poiché passiamo così tanto tempo a correggere i bug, non abbiamo tempo per scrivere un nuovo codice
5. Vai a 1

Considera di provare a mettere un numero su quanto impegno costa correggere un bug in media, e quindi a fare un obiettivo per ridurre quel numero. Il modo per farlo è scrivere le cose correttamente, in primo luogo, perché correggere i bug mentre si scrive il codice (ad es. Rilevarli attraverso i test unitari) è molto più economico per l'organizzazione nel suo complesso che aspettare un tester (o il cliente ) li trova. Se hai i numeri giusti per sostenerti, decidere di prendersi il tempo per svolgere correttamente il lavoro può essere difeso finanziariamente dal management (l'unica lingua a cui tengono veramente).

Sembra che la tua squadra debba prima iniziare ad assumere la proprietà del proprio lavoro. Se non si sentono in grado di prendere la decisione di scrivere il codice corretto in primo luogo, è necessario capire perché lo è, e possibilmente negoziare con la direzione per capire come risolverlo. Una volta che si sentono in grado di apportare le modifiche necessarie, il cambiamento avverrà. A nessuno piace essere cattivo in quello che fanno.

Penso che stai arrivando al problema dal punto di vista sbagliato - il codice non è l'aspetto più importante di tutto questo. Il prodotto è Puoi avere il codice più elegante, ben progettato e con la massima cura che produce un prodotto inutile, lento, difettoso, non utilizzabile, così mal documentato che nessuno può capirlo o usarlo.

In effetti, direi che il codice "migliore" produce sempre cattivi prodotti perché lo sviluppatore non è focalizzato a creare qualcosa che sia semplice e facile da mantenere, che funzioni in base ai compromessi necessari per fare qualcosa di pratico. Se sei troppo preoccupato per tutti i piccoli bit della buzzword che stanno girando al giorno d'oggi, passi tutto il tuo tempo a cercare di non ripetere te stesso o di tenere le cose separate che dimentichi il motivo per cui le stai facendo.

Ora, questo non significa che dovresti semplicemente violare qualsiasi codice terribile, ma significa che devi focalizzare l'orgoglio sui risultati. I risultati includono anche misure come la comunicazione e la manutenibilità del codice, non solo la BTW del prodotto funzionante. Ad esempio, se non c'è documentazione che ne consegue, e nessuno può capire come utilizzare la tua API OO meravigliosamente complessa, quindi non è utile a nessuno.

Quindi, come incoraggiare i tuoi giovani programmatori che sono orgogliosi di nel loro lavoro è una buona cosa. È possibile implementare un sistema di feedback - se qualcuno utilizza un codice che ha trovato facile da usare o utile, può riconoscere il creatore di quello con un flag rapido (simile a come a volte un cliente invierà feedback su un servizio particolarmente buono). Quindi puoi fare revisioni del codice, non le solite in cui sono coinvolti i peer, ma dove scegli un bug a caso e vai a chiedere allo sviluppatore di spiegarti tutto, cosa hanno fatto, perché hanno scelto quell'approccio, che supporto caratteristiche che hanno fornito. È probabile che avrai il minimo indispensabile e potrai evidenziare ciò che ti aspetti, quelli che raggiungono le tue aspettative possono ottenere una ricompensa.

Sembra che ci siano 2 diverse domande: buon codice e orgoglio per il tuo codice. Dico qualcosa su quest'ultimo.

Non sono quasi mai orgoglioso di quale codice scrivo come parte del mio lavoro perché:

• i progetti non sono la mia idea, è l'idea del cliente. Raramente sono qualcosa di fantastico o fantastico e quindi è davvero difficile per me sentirmi emozionato per loro.
• la progettazione e l'implementazione del progetto sono una serie di compromessi: devo accettare di farlo in questo modo perché altrimenti l'altro modulo non può usare il mio codice; Devo accettare di sacrificare alcune buone decisioni di progettazione perché il resto della squadra non è d'accordo con loro.

Penso che questi aspetti si applichino alla maggior parte degli sviluppatori.

Probabilmente l'unico modo per rendere i tuoi sviluppatori orgogliosi del loro codice è promuovere una cultura nella tua azienda di "forniamo prodotti di alta qualità" rispetto a "consegniamo velocemente i prodotti e funzionano abbastanza bene". Fare questo cambiamento significa fornire un codice di qualità che richiede più tempo e quindi costa di più. Questo probabilmente danneggerà la tua azienda, a meno che la base della tua azienda non sia la qualità, cosa che raramente avviene (HR e marketing bullsh * t non si traducono quasi mai in fatti reali).

Nello sviluppo del software, il codice di alta qualità e la competitività aziendale non vanno quasi mai mano nella mano. Proprio come non puoi tenere 2 cani nella stessa vasca da bagno: D.

Ci sono tre aree principali che devono essere affrontate per gestire un problema così ampio. Potresti non essere in grado di cambiarli tutti.

Strategia aziendale: vendite, marketing, ecc. . - Arrivare al mercato prima potrebbe solo superare qualsiasi altra cosa. Quando non sai nemmeno se qualcuno acquisterà il tuo prodotto, rischi più nel settore del debito tecnico. I clienti che odiano implementare la tua prossima versione perché hai una cronologia di creazione di nuovi bug sono altrettanto pessimi di quelli che non pensano di rilasciare abbastanza velocemente e sono disposti ad accettare alcuni difetti.

Gestione, ricompense e punizioni. - Se l'unica cosa che qualcuno riconosce è quanti bug corrono tutti in un determinato lasso di tempo, questo è il sistema che tutti impareranno a giocare. Qualcuno sa che queste correzioni rapide introducono nuovi bug? È necessario continuare ad aggiungere nuove funzionalità perché il codice è troppo difficile da comprendere, il che rende più difficile la manutenzione e il miglioramento? Quando non si adatta al Business è quando causa il maggior numero di problemi.

Formazione e mentori - Gli sviluppatori inesperti (non devono essere giovani) probabilmente continuano a programmare allo stesso modo delle esercitazioni da cui hanno appreso e che cosa ha funzionato abbastanza bene su un progetto più piccolo. Devono essere addestrati e raramente vengono eseguiti da qualcun altro o da soli. È troppo costoso trovare e assumere programmatori entry-level, per farli semplicemente imparare da soli. Se non sono in grado di imparare dagli errori indicati nelle recensioni del tuo codice (hai delle revisioni del codice?) O non vogliono seguire i tuoi standard di codifica (ne hai?), Allora potresti essere costretto a sostituirli.

Tutti questi sono intrecciati. Non sono sicuro che coloro che programmano i pacemaker cardiaci siano migliori di quelli che costruiscono siti web sociali purché comprendano e lavorino nel quadro della strategia aziendale, della gestione e della formazione.

Cosa penso (essendo uno sviluppatore, non un manager), una cosa è abbastanza: permetti loro di fare TDD (e non proibire la programmazione delle coppie). Faranno tale codice, quindi.

Ma è ovvio che è vero solo per gli sviluppatori che vogliono scrivere codice di alta qualità, ma non sono consentiti da regole rigide.

Se hai bisogno di motivare le persone che "stanno bene con tutto ciò che sembra funzioni", non posso aiutarti :-(.