Come convertire un programmatore copia / incolla / spaghetti per vedere la luce?

Questa domanda è stata ispirata da questa . Mentre quell'altra domanda è stata considerata localizzata, credo che il problema di fondo sia qualcosa di estremamente comune nel nostro settore. So che ci sono alcuni sviluppatori, che leggeranno questo e penseranno che sto inventando queste cose e quindi potrebbero rispondere a come tutti si preoccupano del loro lavoro e vogliono imparare, ma solo guardando altri post di Programmers SE ( caso al punto ), So che non è universalmente vero.

Quindi supponiamo di avere qualcuno nel tuo team (o forse la maggioranza) che ha la procedura operativa standard per copiare / incollare e che crede che tutto possa essere risolto se solo aggiungi abbastanza chiamate di funzione e variabili. Questa persona non ha mai sentito parlare di TDD, DRY o SOLID e al di fuori delle 40 ore di lavoro quando sono impegnate a lavorare, non hanno mai letto una sola metodologia / pratiche / libro di progettazione.

In passato io (e altri) ho chiesto come insegnare a OOD . Ma ora sto pensando che non è la domanda giusta. La vera domanda è come ti avvicini a una persona / squadra simile e rendili curiosi di sapere come fare meglio le cose? Come li ispiri ad imparare? Senza questo, sembra che tutti gli insegnamenti, le riunioni, le lezioni e le discussioni siano inutili se sono perfettamente felici di tornare alla propria scrivania e fare ciò che hanno sempre fatto.

Lavoro con un gruppo di persone così. In realtà sono individui piuttosto brillanti, ma odio quando sento "Ho finito di scrivere codice, ho solo bisogno di refactoring e dividere in più classi per rendere felice DXM". Non effettuano il refactoring per un codice più pulito, leggibile e gestibile, ma solo perché altrimenti verranno sgridati. So che sono in grado di apprendere, sembra che ci sia una generale mancanza di motivazione.

Quando fornisco lavoro, generalmente ha molti meno bug e il lavoro che possiedo non è mai diventato mostruosità di 5.000 righe di una classe. Altri farebbero commenti come "il tuo codice è molto più pulito e leggibile delle nostre cose", quindi vedono la differenza. Ma allo stesso tempo, credo che credano di essere pagati per 40 ore indipendentemente da ciò che fanno, quindi in realtà non si preoccupano se trascorrono 3 giorni interi in QA alla ricerca di un bug che non avrebbe dovuto essere introdotto in il primo posto. O che impiegano una settimana per modificare una classe perché ci sono così tante dipendenze che finiscono per toccare. Tuttavia, "forse quella classe avrebbe dovuto essere scritta diversamente" non sembra mai apparire.

Si può fare qualcosa in queste situazioni? Qualcuno è riuscito? O è meglio isolare tale mentalità da parti non critiche del progetto e ridurre al minimo il danno?

NOTA: quando dico "mancanza di motivazione". Non credo sia mancanza di motivazione a lavorare o fare un buon lavoro perché hanno semplicemente smesso di prendersi cura. Gran parte del nostro team è in realtà il contrario. Hanno sicuramente a cuore il prodotto. Abbiamo ragazzi che lavoreranno notti e fine settimana. La parte che sto cercando di superare è con abitudini e abilità migliorate, in realtà non dovrebbero lavorare tanto. Immagino che "40 ore" abbiano fatto sembrare questo post un po 'troppo negativo.

Ti sei trovato il motivo: "So che sono in grado di apprendere, sembra solo che ci sia una generale mancanza di motivazione".

Ci sono persone appassionate del loro lavoro. E ci sono altri che, a volte abbastanza competenti, lavorano solo per soldi . Conoscono le loro cose, ma non amano il loro lavoro. Non passeranno altro tempo a fare ulteriori refactoring per rendere leggibile il codice o risolvere un problema intrigante quando un hack rapido e brutto può fare il lavoro.

Questo fenomeno esiste in ogni lavoro. È solo che alcuni lavori non sono estremamente eccitanti (hai visto un ragioniere che ama il suo lavoro e lo sognavi già da bambino?), Ma in programmazione ci sono molte persone che amano davvero quello che stanno facendo (altrimenti Programmers.SE sarà piuttosto vuoto). Ciò significa che come sviluppatori appassionati, che parlano quotidianamente con altri sviluppatori appassionati, abbiamo più possibilità di essere sorpresi nel vedere una persona che fa la programmazione solo per soldi.

Cosa possiamo fare? Non troppo. In ogni caso, non spetta a te, ma alle risorse umane scegliere persone veramente motivate¹. E licenzia le persone che non lo sono.

Puoi provare a motivare i tuoi colleghi, ma è estremamente difficile. Se dai loro dei libri da leggere, li restituiranno non aperti qualche settimana dopo. Se dai loro un consiglio, non ascolteranno, perché a loro non importa2.

Puoi:

• Convinci il tuo capo a stabilire una serie di rigide regole nella tua azienda: linee guida di stile , ecc. Ciò non motiverà quelle persone a fare un lavoro migliore, ma almeno non saranno in grado di impegnare il codice sorgente che non corrisponde ai requisiti .

• Lavora sui requisiti, in particolare i requisiti non funzionali . Che dire di un requisito che dice che un progetto specifico deve contenere meno di 5.000 righe di codice IL (no, non sto parlando del LOC insignificante ) ³? Che ne dici di richiedere risultati specifici alla complessità ciclomatica o all'accoppiamento di classe ?

• Aumenta il numero di ore trascorse nella tua azienda per la revisione del codice . Specificare ciò che viene esaminato: se si dispone di un elenco di controllo, aggiungere i punti relativi a refactoring, leggibilità, commenti chiari e utili, ecc. Se non si dispone di un elenco di controllo, è necessario.

• Utilizzare [altro] coppia di programmazione . Può aiutare a migliorare la qualità del codice e motivare i colleghi meno motivati.

• Utilizzare il sistema di compensazione simile a quello utilizzato in Fog Creek.

^{¹ Ecco le interviste: prima di assumerti, le risorse umane devono valorizzare non solo il tuo livello tecnico, ma anche la tua motivazione . Purtroppo, alcune aziende dimenticano questa seconda parte dell'intervista e assumono persone che non amano programmare troppo. Fortunatamente, nella maggior parte dei casi, il lavoro in quelle aziende non è mai divertente e il test di Joel raramente supera 2.}

^{² A loro non importa davvero , anche se guadagnano meno soldi. Sono abbastanza vicino a uno dei miei clienti (sono un libero professionista) che crede che il suo lavoro sia quello di sviluppare siti Web per i propri clienti. Ha anche un designer. Ho detto loro molte volte dei modi in cui possono aumentare la loro produttività di 2 o più. Se assumessero semplicemente qualcuno competente, aumenterebbero le loro entrate di almeno 3. Ma hanno abbastanza soldi e non si preoccupano della qualità o di quanto costano ai clienti ignoranti, rispetto a qualcuno produttivo.}

^{³ Quello che intendo è il numero di righe di codice IL che vedi in Code Metrics in Visual Studio , la metrica che in realtà significa qualcosa. Il vero LOC non ha importanza e non devi misurarlo; è una delle metriche più stupide di sempre. Applicare righe di codice IL significa che gli sviluppatori saranno costretti a refactificare effettivamente il codice e non solo a comprimere dieci righe di codice in un'unica riga illeggibile.}

"Ho finito di programmare, ho solo bisogno di refactoring e dividere in più classi per rendere felice DXM".

Quella linea di pensiero proprio lì c'è un cancro in ogni squadra e ucciderà la motivazione di tutta la squadra se non curata immediatamente. Mi riferisco ovviamente al fatto che, per anzianità e / o merito, ti trovi in ​​una posizione di autorità tecnica, dandoti il ​​potere di aiutare a influenzare e realizzare buone pratiche nella tua squadra.

Tutto questo va bene, tuttavia, se il tuo team fosse chiaramente venduto su questi processi, non ti distinguerebbero in dichiarazioni come questa tra loro che mostrano chiaramente una mancanza di rispetto per il processo e una mancanza di rispetto per te. Vedono ancora queste migliori pratiche come un ostacolo causato da te e non un processo di proprietà del team che la tua squadra difenderà per i suoi meriti.

Nei commenti precedenti hai menzionato che altri membri del team stanno effettivamente seguendo queste pratiche e standard e le stanno applicando correttamente. Focalizza prima l'attenzione sul sostegno da parte loro, chiedi loro cosa funziona, cosa non funziona, cosa piace a loro e cosa vorrebbero vedere cambiato. Se lo fai e prendi sul serio le loro opinioni, si sentiranno in modo molto diverso sugli standard come se fossero una decisione della comunità invece di una procedura tramandata da un superiore.

Rafforzi il supporto per le migliori pratiche e gli standard indicando al team come hanno migliorato il processo di sviluppo del software o la qualità del software.

Tieni un voto sulle questioni in discussione e documenta i risultati, idealmente ogni decisione dovrebbe essere unanime per motivi di legittimità, ma se hai a che fare con ostruzionisti di linea dura questo potrebbe essere impossibile e potrebbe semplicemente risolvere ogni problema. Usa un voto di maggioranza in questa situazione. Se la maggioranza è contraria agli standard e alle pratiche proposti, allora hai già perso la stanza, rinuncia a quel punto.

Saranno proprio tali norme e procedure e sarà far rispettare in modo che non si deve. Come capo tecnico non dovresti dichiarare editti e decreti, è un modo scarso di essere un leader.

Una volta che il team ha la sensazione di essere il proprietario delle procedure, i membri del team che iniziano a etichettarti su determinate procedure e le migliori pratiche saranno illegittimi a pensarlo. Il tuo team aiuterà a correggere questo atteggiamento negli altri.

Buona domanda! Penso che la risposta dipenda dal perché le persone non vogliono migliorare le proprie capacità. Le possibili risposte sono:

• Pensano di essere troppo impegnati per imparare qualcosa di nuovo o pensano che il nuovo modo di fare le cose (come scrivere tutti quei test) richiederà più tempo e non hanno tempo per farlo. Quindi la risposta ovvia sarebbe: dare loro più tempo. Imparare qualcosa o cercando qualcosa di simile a TDD quando hai le cose sempre fatto in modo diverso si vorrà più tempo il primo paio di volte. Se i tuoi programmatori non hanno quel tempo, non puoi biasimarli per non aver provato.
• Hanno una diversa percezione delle proprie capacità, cioè pensano di essere programmatori molto bravi che producono codice di alta qualità. Questo è un terreno psicologico difficile, perché frantumare questa convinzione può essere molto demotivante. Forse una sorta di competizione informale può aiutare (chi produce il minor numero di difetti / funzionalità? Il codice più corto? Il minor numero di WTF / minuto in una revisione del codice?).
• Potrebbe esserci un vero problema di motivazione (cioè vogliono solo "fare il loro tempo e rimanere soli" fino all'orario di chiusura). Fortunatamente, questo è troppo generico / non legato alla programmazione, perché davvero non ho una risposta per questo.
• Sono principianti e non conoscono meglio. In tal caso, la formazione, le revisioni del codice potrebbero essere utili o un "club del libro" in cui un membro del team deve discutere un nuovo libro tecnico ogni mese.
• Hanno già visto proiettili d'argento (e sono stati amaramente delusi) e pensano che qualunque cosa tu stia cercando di venderli è solo un'altra nuova parola d'ordine che suona bene in teoria ed è poco utile nella pratica. In tal caso, dimostrando i vantaggi durante le revisioni del codice e le sessioni di programmazione delle coppie potrebbe funzionare. Cerca di non essere un esperto totale quando lo fai.

La migliore soluzione dipende davvero dal problema alla radice: ad esempio, linee guida formali di codifica, metriche e recensioni possono funzionare per i principianti, ma le persone nella "percezione sbagliata delle proprie capacità" -crowd potrebbero lottare contro di loro o giocare le metriche perché vedono come ostacoli burocratici controproducenti per portare a termine il loro lavoro.

La vera domanda è come ti avvicini a una persona / squadra simile e rendili curiosi di sapere come fare meglio? Come li ispiri ad imparare? Senza questo, sembra che tutti gli insegnamenti, le riunioni, le lezioni e le discussioni siano inutili se sono perfettamente felici di tornare alla propria scrivania e fare ciò che hanno sempre fatto.

Questo è tutto! Questa è davvero una vera domanda.

Per dare un po 'di backgound, semplicemente non abbiamo tempo di dedicare molta formazione formale - ma occasionalmente se lo faccio - non vedo ancora luce. Ho anche fatto parte delle aziende in cui la formazione formale diventa un processo stesso ma e sono così spesso testimone che difficilmente insegnano loro a pensare.

Quindi la domanda che pongo a loro non è come insegnare loro - ma come farli imparare? La differenza è sottile ma è ciò che farà la differenza.

Non so se ho ragione; ma spesso credo in una finestra di dialogo di una matrice il film - "È la domanda che ci guida!" Ciò che è più importante è farli pensare, far loro chiedere perché! E, naturalmente, la maggior parte di coloro che pensano di sapere già tutto su alcuni modelli di design perché hanno ottenuto buoni voti nei corsi universitari - sono i più difficili lì.

Come fai a fargli queste domande? Il mio approccio generale è "che li butti nello stagno se vuoi che imparino a nuotare" . Sono d'accordo che le persone potrebbero non essere d'accordo; e accetterò volentieri di non essere d'accordo con loro. Quando li lanci nello stagno - in realtà non imparano a nuotare automaticamente; ma scatena un istinto di sopravvivenza che li fa pensare - una volta che ciò accadrà, naturalmente penseranno a COME e PERCHÉ.

Un esempio pratico che do alla gente è quello di metterli in un progetto significativamente complesso rispetto a quello che hanno sperato di farne uno e lasciarli combattere la propria battaglia. Quando hanno iniziato a svelare il codice e hanno difficoltà a rintracciarlo, ti rendi conto che iniziano a fare una buona domanda.

Questo può sembrare un po 'estremista, questo può sembrare uno spreco di risorse . E sono sicuro, ce ne sono molti altri che mi daranno il consiglio di non farlo. Ma questo ha funzionato per me!

Indipendentemente dai pacchetti a pagamento e dai tag HR assegnati, non risolverai il problema di motivazione di base . Perché l'unica strada è che sono sfidati; Se scintilli di questo spirito umano di base, tutto il resto funziona. Se non puoi, è un gioco sciolto.

PS: Per inciso ho pubblicato una risposta qui https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - e ho avuto tutti i colpi; principalmente la maggior parte delle persone crede che in qualche modo le aziende non possano permettersi di sprecare risorse! Sono sicuro che questa risposta potrebbe ottenere un trattamento simile qui. Ma la verità è che far lavorare le persone e farle credere nel fare un buon lavoro è un argomento della psicologia umana su come realizzare il programma del corso.

Ad ogni modo, il compito che stai descrivendo qui equivale ad accendere la passione interiore per fare grandi cambiamenti. E più grande è il sistema, più diventa difficile. Inizia con i giovani più giovani che sono ancora integrati con lo spirito di non fare un buon lavoro e sfida lo status quo.

Come fai notare, la sua motivazione. Non confonderli senza preoccuparsi che non lo sappiano. Sanno chiaramente cosa fare. A loro non importa . In tal caso, la vera domanda qui è ... cosa sta facendo la tua direzione in modo sbagliato che li mantiene così poco motivati? Sei il nuovo membro del team? Forse hanno già affrontato tutto ciò prima, con solo problemi di gestione. Quindi si limitano a fare la minima quantità di lavoro necessaria per mantenere il loro lavoro perché non pensano che fare di più verrà risposto dal datore di lavoro.

Mi sembra che questo sia un problema di gestione e di leadership: se è il tuo team, puoi lavorare per rendere il miglioramento (personale e del codice) un attributo fondamentale del tuo team, la domanda è: che sarà supportato dal tuo management, perché vorrai fare cose che richiederanno tempo (otterranno una vincita netta in quanto dovresti ridurre il nuovo debito tecnico e rimborsare il debito tecnico esistente).

Quindi, affermi che vuoi che il team migliori, ottieni il loro consenso sul fatto che questa è una buona cosa (che il team, nel suo insieme, lavora per migliorare la qualità del suo codice) e quindi inizi un programma per farlo succede - sembra così facile ... Sono consapevole che non lo è!

Penso che ci siano due parti in questo: educazione e pratiche di lavoro.

• Istruzione, puoi iniziare un pranzo a settimana: tutti mangiano insieme, fai una presentazione di 20-30 minuti con domande e risposte. Inizi con le basi che vuoi - SOLID può occupare le prime 2 ~ 4 settimane - col tempo fai in modo che il team parli a rotazione e puoi capire come decidere chi parla su cosa tra di te. Consenti agli altoparlanti un po 'di tempo di preparazione durante il lavoro. Oltre a ciò, incoraggiare la presenza di gruppi di utenti locali (rendendola almeno in parte social, se possibile)
• Pratiche di lavoro ... beh dipende da cosa fai ora e da quali strumenti hai, ma potresti voler esaminare gli standard di codifica concordanti, introdurre la revisione del codice peer (è solido), test unitari (non necessariamente testare prima) , eseguendo un server di integrazione continua e esaminando test più automatizzati (oltre ai test unitari). Ma questi devono essere sostanzialmente introdotti con il consenso / accordo (non il server build / CI!) E devi voler far avanzare la qualità come squadra. Ci sono sempre cose che si possono migliorare (Kaizen)

Vale anche la pena guardare Kanban (che viene visto come un driver per il cambiamento / miglioramento).

Un ultimo pensiero: sono un programmatore professionale e vorrei che il mio team fosse lo stesso, ma lavorare più di 40 ore alla settimana non è in realtà una buona cosa, quindi l'obiettivo dovrebbe essere quello di avere un team che faccia il proprio lavoro efficacemente entro la normale settimana lavorativa e per questo l'argomento per migliorare la pratica lavorativa è che è più probabile, ad esempio: aggiungere test unitari per dimostrare il caso fallito quando (prima) la correzione dei bug ti dà la certezza che èfisso; avere un server di build ti dà fiducia nella tua capacità di costruire le tue soluzioni in modo pulito - se tale build genera anche pacchetti di distribuzione significa che la distribuzione è notevolmente semplificata; Il codice SOLID è, per definizione, più facile da modificare; e su tutta la linea minore è il debito tecnico che devi sostenere, meno devi rimborsare ...

Sono caduto nella programmazione per caso ~ 30 anni fa. Ero motivato ad apprendere i principi di base dell'ingegneria del software venendo assegnato a mantenere / supportare il codice di altre persone. In questi compiti, ho imparato come un lettore di codice sperimenta il codice - come entrare in empatia con il lettore di codice. Non volevo infliggere agli altri il dolore del mio codice scritto male!

Questa pratica di assegnare nuovi programmatori a mantenere / supportare il codice di altre persone non è un proiettile magico e sembra fornire motivazione per imparare a produrre codice solido il più delle volte.