Come bilanciare la qualità del codice con le forti personalità degli sviluppatori

Sulle revisioni del codice sul lavoro ho visto codice e schemi che ritengo "intelligenti", sebbene non si aggiungano necessariamente alla qualità generale o alla manutenibilità della base di codice. Lo segnalo sul mio feedback e non sono convinto dai controargomenti. Sono un po 'preoccupato quando questo codice entra nel repository e successivamente nella produzione.

Voglio mantenere un team coeso, quindi non voglio creare tensione essendo troppo vocale sulle mie riserve. Voglio anche creare un ottimo prodotto per i nostri clienti senza essere troppo indulgente.

Tradizionalmente, chi ha il potere di "veto" su ciò che viene verificato e come?

Come può essere rimosso il codice che funziona, ma è troppo coinvolto / intelligente senza calpestare le dita dei piedi?

Adoro questa citazione:

"Il debug è due volte più difficile della scrittura del codice in primo luogo. Pertanto, se si scrive il codice nel modo più intelligente possibile, non si è, per definizione, abbastanza intelligenti da eseguirne il debug." - Brian W. Kernighan

Da un lato, questo ti rende stanco del codice troppo intelligente, poiché sarà difficile eseguire il debug e l'estensione in seguito.

D'altra parte, il codice intelligente che funziona è un ottimo modo per imparare. Probabilmente per l'intera squadra. Che ne dite di incoraggiare l'autore a tenere un breve discorso informale sul codice ai propri colleghi? Assicurati solo che funzioni davvero come previsto e che abbia senso nel progetto nel suo insieme. Non vuoi trasformarlo in una competizione inutile!

Se non pensi che aggiunga valore, posiziona la controspinta chiedendo: "Come puoi refactoring questa parte (hai test in atto, giusto?) In modo che sia più leggibile?" Assicurati di indicare che è più difficile creare un codice intelligente e leggibile che creare pepite impenetrabili.

Il mio consiglio è di fare l'idiota, quando è il momento di fare recensioni di codice sentiti libero di dire che non hai idea di come funzioni (se il tuo ego ha bisogno di un massaggio, puoi dire che non hai avuto il tempo di capirlo ) e chiedi allo sviluppatore di spiegarlo. Quando ha finito puoi suggerire di scrivere tutto questo come un commento per la futura manutenzione, con il suggerimento implicito che è troppo contorto per essere considerato un codice "buono".

Se il suo buon codice è un po 'troppo complicato, la maggior parte delle persone otterrà il suggerimento, senza che sia stato detto nulla sulla qualità del codice o sull'esperienza degli sviluppatori.

PS. Ovviamente la maggior parte di questo codice sarà comunque soggettiva, quindi il codice incredibilmente intelligente di una persona potrebbe essere un algoritmo ragionevole e forse persino standard di settore per un altro sviluppatore, quindi non puoi accusare nessuno direttamente di scrivere codice cattivo (tranne quando il suo sfregio è ovvio come l'appaltatore che ha copiato un array di byte in un elenco stl, lo ha passato in una routine di crittografia e poi lo ha riconvertito in un array di byte!)

La mia regola pratica è quella di piegare le linee guida sulla qualità del codice a favore di personalità forti degli sviluppatori. Lo uso sempre quando non ho tempo per scavare abbastanza in profondità - tale scavare a proposito è in genere piuttosto impegnativo (di più su quello che segue).

Questa regola si basa sull'esperienza personale. Ho iniziato (probabilmente come qualsiasi neofita) seguendo fanaticamente le linee guida e combattendo a fondo ogni deviazione. Con il passare del tempo ho acquisito competenze sufficienti e imparato abbastanza trucchi per vincere tali combattimenti con relativa facilità - che a loro volta mi hanno permesso di concentrarmi maggiormente sull'apprendimento dell'impatto complessivo delle mie "vittorie". E l'impatto, per quanto posso dire, è stato piuttosto negativo - i ragazzi che "hanno perso la lotta" hanno sofferto e sono diventati meno produttivi - e, sai, il fatto che il loro codice fosse conforme al 200% con le linee guida sulla qualità non ha compensato questo.

Questa scoperta mi ha fatto abbandonare la maggior parte dei combattimenti che a loro volta hanno portato ad avere più tempo per analizzare i casi problematici. E ho scoperto che quando scavo abbastanza in profondità c'è in genere un interessante problema di progettazione da qualche parte dietro, un problema sottile (o non troppo sottile) che si nascondeva dietro le personalità in lotta.

• È come, ad esempio, dire che trovo il file sorgente 31K che supera il limite di dimensioni consigliato, ovvero 30K. Le mie opzioni sono o di passare qualche minuto / ora a combattere per costringere il proprietario del file a spremere in qualche modo quel kilobyte in più o a passare un giorno o due a pensare e scavare per scoprire che, diciamo, c'è qualche API della libreria che può essere utilizzata al posto di tutte il codice in quel file (in modo che possa essere appena rimosso).

Tale scoperta a volte potrebbe non essere molto utile dal punto di vista dell'utente finale (anche se a volte può effettivamente avere un impatto profondo), ma devo ammettere il divertimento che provo quando rompere un tale dado vale comunque la pena lo sforzo ... e come un la ciliegina sulla deviazione delle linee guida per la torta scompare senza combattere. :)

La tua organizzazione dovrebbe avere un documento di linee guida / standard di codifica che viene periodicamente aggiornato con il contributo del team di sviluppo. Quel documento può precisare specifici, come: come nominare le variabili, come formattare il codice e così via. Il documento dovrebbe inoltre spiegare i valori che l'organizzazione si aspetta che i programmatori adottino per iscritto il codice, compresa l'importanza relativa di cose come leggibilità, manutenibilità, correttezza, efficienza e rispetto degli standard.

Le revisioni del codice devono essere condotte utilizzando quel documento sugli standard di codifica. Se gli standard di codifica affermano che i programmatori dovrebbero preferire la leggibilità alla brevità quando i due sono in conflitto, allora avrai un po 'di supporto nel discutere contro il codice "intelligente". Se gli standard non lo dicono e pensi che dovrebbero, allora puoi discuterne in astratto alla riunione degli standard di codifica piuttosto che cercare di capire quando l'ego di qualcuno è in linea.

Alla fine, a volte si riduce a una sentenza, e in quei casi la parola finale dovrebbe andare alla persona che è in definitiva responsabile del codice e / o del prodotto. Di solito è qualcuno come uno sviluppatore senior, responsabile tecnico, project manager o direttore dell'ingegneria. Se sei il responsabile e ritieni che un determinato codice non sia sufficientemente gestibile, non dovresti aver paura di dirlo. Puoi essere diplomatico al riguardo:

Sam, sono impressionato dalla tua ingegnosità qui, ma sono preoccupato che potrebbe essere solo un po 'troppo intelligente. Avrò bisogno che tu lavori al nuovo sviluppo tra un anno piuttosto che mantenerlo, e sono preoccupato che chiunque debba mantenerlo potrebbe non comprendere appieno la sua bellezza. So che odi farlo, ma lo apprezzerei se tornassi alla semplice implementazione di cui abbiamo discusso.

D'altra parte, se non sei il responsabile, il meglio che puoi fare è spiegare chiaramente la tua posizione e cercare di convincere il resto della squadra. Se non ricevi supporto dal gestore, accetta che non sia la tua chiamata e vai avanti.

Al tuo posto (e io, a volte, sono una di quelle smartasses) non lo rimuoverei, ma chiedo personalmente all'autore arguto / intelligente di documentarlo molto bene nei commenti e, se possibile, di includere alcune discussioni su alternative e scritti più semplici che avrebbe potuto usare, con esempi.

Sottolineo che questo è per il meglio, perché anche lui probabilmente non ricorderà tutti i pezzi che ci sono, in quelle righe, tra due mesi.

Probabilmente lascerà cadere il codice intelligente in favore di quello più semplice, non appena sarà costretto a scriverlo, come esempio.

Perché dovrebbe funzionare.

• Hai riconosciuto che ti importa di ciò che scrive ,
• hai mostrato lo rispetta per chiedere ,
• citando i problemi di memoria / concentrazione che hai ideato e analizzagli uno scenario in cui quel codice deve essere modificato e non può essere mentre lavora ancora per l'azienda o il team

(senza quest'ultima allusione, questo tipo di richiesta può essere ricevuto come un tentativo, da parte dell'azienda, di mercificare il programmatore , rendendolo intercambiabile con qualsiasi altra scimmia di codice in qualsiasi momento)

In base alla mia esperienza, in genere è molto difficile ottenere il codice che soddisfa tutti i requisiti dalla base di codice.

Tuttavia, la prossima volta che il codice deve essere mantenuto, si può facilmente discutere per la sua sostituzione come futura misura di riduzione dei costi perché il vecchio codice era più difficile da mantenere.

Per quanto riguarda il potere di veto, la direzione ovviamente lo possiede.
A volte si tratta di squadre o comitati che si occupano della qualità del codice, nel qual caso avrebbero anche questo potere.

Sarebbe anche utile dare un esempio di un modello "intelligente". Forse stai solo esagerando ...

"intelligente" non è quasi mai una brutta cosa nel mio libro, ma posso essere d'accordo sul fatto che possa esserci una pendenza scivolosa tra intelligente e contorto.

Come molte altre pratiche, penso che la risposta sia che dipende .

• Se si tratta di un difetto, è necessario risolverlo.
• Se il codice funziona devi bilanciare il valore di insistere affinché il codice venga modificato rispetto al costo futuro del codice intelligente. Mentre ci sono delle regole empiriche per quanto riguarda il rapporto tra lavori di sviluppo e lavori di manutenzione, varieranno molto da un progetto all'altro. Essere ragionevole.
• Considera perché non riesci a convincere il tuo compagno di squadra che il codice deve essere semplificato?
• Non devi sempre ottenere tutto perfetto. Ciò significherebbe revisioni del codice in un ciclo infinito e nulla è registrato perché nulla (tranne il mio codice, haha) è perfetto.
• La mia preferenza personale è che l'autore del codice abbia l'ultima parola. Ovviamente se continuano a svolgere un lavoro molto scarso, allora devono essere intraprese altre azioni, ma come dici tu, il valore negativo di forzare lo sviluppatore a cambiare il codice potrebbe essere superiore al guadagno ottenuto correggendolo se questa è una situazione molto rara .

Posso sicuramente collegarmi a questa domanda. Attualmente sono il responsabile tecnico di 2 team ed è mio compito garantire che il codice che produciamo sia il più leggibile e gestibile possibile. Allo stesso tempo, sono stato conosciuto per produrre un codice "intelligente" e so che la maggior parte dei miei compagni di squadra avrà difficoltà a seguirlo.

Poche osservazioni posso offrire:

1. La tua squadra ha bisogno di un vantaggio che prenderà la decisione finale in caso di disaccordo. Nell'ultima versione ero in una squadra senza leadership ed era atroce. Tutto è diventato un argomento, e se hai poche persone con personalità forti nessuno dei due si muoverà. Se hai un vantaggio, indipendentemente da quale decisione sia stata scelta, tutti i membri del team DEVONO capire che cosa dice il lead. Ecco perché il management lo ha portato al comando.

2. Mantenere le persone felici è molto importante. Pertanto, invece di spingere l'intera squadra verso il tuo punto di vista, spingili lì. Spiega i principi SOLID, spiega l'importanza di classi / metodi / interfacce piccole e coerenti e ripeti queste cose ogni volta che vedi che sono state violate (cioè in una revisione del codice). Allo stesso tempo, non farli riscrivere ogni singola cosa che non ti piace. Alla fine della giornata, è necessario un equilibrio tra espressione personale e seguenti standard di gruppo. Si spera che i due convergeranno mentre le preferenze personali si spostano verso il modo in cui il gruppo in generale sta funzionando.

3. Credo che sia molto più importante avere interfacce di classe pulite e di facile comprensione, piuttosto che non avere mai un codice "intelligente". Ad esempio, abbiamo una classe che mantiene un elenco di voci che vengono cercate in 3 modi diversi. Attualmente utilizza semplicemente la ricerca lineare per tutte le ricerche che funzionano su piccola scala, ma poiché questa classe è a un livello molto basso, vedo che non si adatta molto bene. Sto per sostituirlo con una classe diversa, che utilizza i contenitori Boost Intrusive. Ogni elemento supporterà il posizionamento simultaneo in ciascuno degli indici e tutta la ricerca verrà eseguita in O (sqrt (N)). Sì, sarà molto più complicato all'interno e molte persone non apprezzeranno Boost, ma all'esterno rimarranno 3 metodi: Aggiungi, Rimuovi, Ottieni. La linea di fondo è che le persone possono scrivere qualunque codice vogliano (entro limiti ragionevoli),

4. Mantenere l'idea della proprietà del codice. Anche se a volte è difficile da ottenere poiché persone diverse potrebbero aver bisogno di aggiungere / modificare del codice. Quando viene scritto il codice, lo sviluppatore originale è il custode finale di quel codice. Ciò non significa che nessun altro possa toccarlo. Se altri modificano il loro codice, va bene, ma alla fine lo sviluppatore originale lo rivede e rimane responsabile di qualunque cosa accada. Che quel codice sia semplice o intelligente, è suo figlio. Se / quando, come si prevede, i bug iniziano a accumularsi a causa delle decisioni di progettazione / codifica che sono state prese, invece di limitarsi a correggere quei bug quando entrano, siediti con quello sviluppatore (che tra l'altro dovrebbe correggere tutti quei bug) e riflettere su quelle decisioni per vedere come avrebbero potuto essere prese diversamente.

Ho passato molti anni a guidare e gestire team di sviluppo. Per natura, sono un po 'OCD in termini di codice e molto in bianco e nero. Ho imparato per esperienza che scegliere le tue battaglie è una delle abilità più difficili da imparare come leader di una squadra. Sì, gli standard sono importanti. Sì, la leggibilità e la manutenibilità sono incredibilmente importanti. Sì, dovremmo tutti impegnarci a scrivere un codice uniforme e conforme agli standard. Gli sviluppatori sono umani però ... non strumenti di generazione del codice. Abbiamo personalità, opinioni, ci annoiamo e vogliamo imparare cose nuove.

Sulle revisioni del codice sul lavoro ho visto codice e schemi che ritengo "intelligenti", sebbene non si aggiungano necessariamente alla qualità generale o alla manutenibilità della base di codice.

OK ... quindi non aggiungono, ma riducono? Stiamo parlando solo di una questione di preferenze personali negli stili di codifica o il codice è stato scritto completamente superfluo (ad es. Usare alberi di espressione e riflessione solo perché è divertente usare alberi di espressione e riflessione)? Se è il primo, lascialo andare. Parte del divertimento di essere uno sviluppatore è trovare soluzioni creative ai problemi. Forse (e alla maggior parte di noi non piace ammetterlo), a volte ci sentiamo intimiditi da approcci che non capiamo e o non vogliamo chiedere o non abbiamo l'energia aggiuntiva per apprendere il nuovo approccio.

Ora, quando la creatività porta a codici superflui e complessità completamente ingiustificabile, allora sii assolutamente vocale e fai valere le tue ragioni. Essere un giocatore di squadra è importante, ma lo è anche essere (e trattenere gli altri). Le revisioni del codice riguardano sia la responsabilità che la garanzia della qualità e l'apprendimento. Stai per fare qualche passo avanti, ma se senti di avere una forte argomentazione sul perché lo sforzo (denaro) dovrebbe essere speso riscrivendo il codice di lavoro E un ego dovrebbe essere contuso nel processo E vuoi rischiare di schiacciare l'entusiasmo di qualcuno per il loro mestiere , quindi non dovresti evitare di metterlo sul tavolo. Se sei il capo squadra, questo è il tuo lavoro. Sii consapevole dell'impatto e fallo. Se non sei a capo di una squadra e non hai l'autorità, allora lascia che sia la squadra a decidere.

Il modo migliore per instillare la responsabilità nella tua squadra è incoraggiare gli altri a renderti responsabile. Se mantieni una mentalità aperta e non chiudi le persone quando suggeriscono miglioramenti al tuo codice, potresti scoprire che sono più ricettivi ai tuoi suggerimenti.

Per esperienza personale, quando ciò accade chiederei il permesso di essere un tester volontario dell'unità avversaria per scrivere test al fine di torturare l'implementazione sconosciuta.

Farò del mio meglio per capire veramente come funziona il codice e cercherò anche di sondarlo in molti modi diversi.

Si noti che questo è un impegno di tempo. Potrebbero essere ore o decine di ore o anche una buona parte di una settimana. La giustificazione dipende dal fatto che la complessità del codice sia commisurata alla complessità del requisito.

Se non avessi prevalso, cioè se il codice sopravvivesse ai numerosi test, mi convincerei che forse l'implementazione è davvero più illuminata di me, e sosterrò l'inclusione nel prodotto principale.

A seconda della metodologia di controllo del codice sorgente, potrebbe essere necessario eseguire il commit provvisorio del codice nel sistema di controllo del codice sorgente (forse in un ramo) prima che questa fase di test possa iniziare.

La mia risposta è colorata dalla mia esperienza di utilizzo di OpenCV. Ci sono algoritmi che sono molto più sofisticati di quanto i programmatori possano implementare da soli; nemmeno i dottorati di ricerca - forse le prime percentuali di dottorato. Se il codice è così buono, devi fidarti di ciò, agendo contro i tuoi stessi istinti e pregiudizi, anche se non hai mezzi efficaci per quantificare quel livello di fiducia.