Come bilanciare la qualità del codice rispetto a forti personalità dello sviluppatore

Adoro questa citazione:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan

Da un lato, questo ti rende stanco del codice troppo intelligente, dal momento che sarà difficile eseguire il debug e estenderlo in seguito.

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

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

Il mio consiglio è di fare l'idiota, quando è il momento di fare recensioni sul codice sentitevi liberi di dire che non avete idea di come funzioni (se il vostro ego ha bisogno di un massaggio, potete dire che non avete avuto il tempo di capiscilo) e chiedi allo sviluppatore di spiegarlo. Quando avrà finito, puoi suggerire che scriverà tutto ciò come commento per la manutenzione futura, con il suggerimento implicito che è troppo complesso per essere considerato un codice "buono".

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

PS. Ovviamente la maggior parte di questo codice sarà soggettiva in ogni caso, quindi il codice di una persona incredibilmente intelligente potrebbe essere un algoritmo ragionevole e forse addirittura standard del settore per un altro dev, quindi non si può accusare nessuno direttamente di scrivere codice cattivo (eccetto quando è evidente come l'appaltatore che ha copiato un array di byte in un elenco di stl, lo ha passato in una routine di crittografia e poi lo ha riconvertito in un array di byte!)

La mia regola empirica consiste nel piegare le linee guida sulla qualità del codice in favore di forti personalità dello sviluppatore. Lo uso sempre quando non ho il tempo di scavare abbastanza in profondità - tale tipo di scavo è in genere abbastanza impegnativo (di seguito più avanti).

Questa regola si basa sull'esperienza personale. Ho iniziato (probabilmente come qualsiasi neofita) con le seguenti linee guida fanatiche e combattendo a fondo ogni singola deviazione. A tempo debito ho acquisito abilità sufficienti e ho imparato trucchi sufficienti per vincere tali combattimenti con relativa facilità - il che a sua volta ha permesso di concentrarsi 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 battaglia" soffrivano e sono diventati meno produttivi - e, sapete, 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 perdere la maggior parte dei combattimenti che a loro volta portano ad avere più tempo per analizzare i casi problematici. E ho scoperto che quando scavo abbastanza in profondità di solito c'è un interessante problema di progettazione da qualche parte dietro, un problema sottile (o non troppo sottile) che si nascondeva dietro le personalità che combattevano.

• È come se, come dire, trovo che il file sorgente 31K superi il limite di dimensioni raccomandato, ovvero 30K. Le mie opzioni sono di passare qualche minuto / ora a combattere per forzare il proprietario del file a spremere in qualche modo quel kilobyte extra o per passare un giorno o due a pensare e scavare per scoprire che, per esempio, c'è qualche API della libreria che può essere usato al posto di tutto il codice in quel file (in modo che possa essere rimosso).

Una tale scoperta a volte potrebbe non essere molto utile dal punto di vista dell'utente finale (anche se a volte può avere un impatto profondo), ma devo ammettere il divertimento che ottengo quando scappare un tale dado lo rende meritevole comunque lo sforzo ... e come ciliegina sulla torta la deviazione delle linee guida va anche via senza combattere. :)

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

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

In definitiva, a volte si arriva a una chiamata di giudizio, e in questi casi l'ultima parola dovrebbe andare alla persona che è alla fine responsabile del codice e / o del prodotto. Di solito è qualcuno come uno sviluppatore senior, capo 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, I'm impressed with your ingenuity here, but I'm concerned that it may be just a little too clever. I'll need you to be working on new development a year from now rather than maintaining this, and I'm concerned that whoever does have to maintain it may not fully comprehend its awesomeness. I know you hate to do it, but I'd appreciate it if you'd go back to the straightforward implementation that we discussed.

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

Al tuo posto (e io, a volte, sono uno di quegli idioti) non lo rimuoverei, ma chiedo personalmente all'autore spiritoso di di documentarlo molto bene nei commenti e, se possibile, includere alcune discussioni su scritti alternativi e più semplici che avrebbe potuto utilizzare, con esempi.

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

Probabilmente farà cadere il codice smart in favore di quello più semplice, non appena sarà costretto a scriverlo, ad esempio.

Perché dovrebbe funzionare?

• Hai riconosciuto che ti interessa di ciò che scrive ,
• gli hai mostrato rispetto di chiedendo ,
• citando problemi di memoria / messa a fuoco che hai ideato e abbattendo su di lui uno scenario in cui quel codice deve essere cambiato e non può mentre sta ancora lavorando per la società o il team

(senza quell'ultima allusione questo tipo di richiesta può essere ricevuta come tentativo, dalla parte della compagnia, di mercificare il programmatore , rendendolo intercambiabile con qualsiasi altro codice scimmia in qualsiasi momento)

Nella mia esperienza, è generalmente molto difficile ottenere codice che soddisfi tutti i requisiti dal codice base.

Tuttavia, la prossima volta che si manterrà il codice, si può facilmente sostenere che la sostituzione è una misura di risparmio futuro perché il vecchio codice era più difficile da mantenere.

Per quanto riguarda il potere di veto, la gestione ovviamente lo ha.
A volte le loro sono squadre o comitati che si occupano della qualità del codice, nel qual caso avrebbero anche questo potere.

Sarebbe anche utile se date 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 ci possa essere una china scivolosa tra intelligente e contorta.

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

• Se si tratta di un difetto, è assolutamente necessario correggerlo.
• Se il codice funziona, devi bilanciare il valore di insistere sulla modifica del codice rispetto al costo futuro del codice intelligente. Mentre ci sono regole pratiche per quanto riguarda il rapporto tra il lavoro di sviluppo e il lavoro di manutenzione, varieranno molto da un progetto all'altro. Sii ragionevole.
• Considera perché non riesci a convincere il tuo compagno di squadra che il codice deve essere semplificato?
• Non è sempre necessario ottenere tutto perfetto. Ciò significherebbe recensioni del codice in un ciclo infinito e nulla viene verificato perché nulla (tranne il mio codice, haha) è perfetto.
• La mia preferenza personale è che l'autore del codice abbia l'ultima parola. Ovviamente se stanno facendo continuamente un lavoro molto povero, allora bisogna prendere qualche altra azione, ma come dici tu il valore negativo di forzare lo sviluppatore a cambiare il codice potrebbe essere più alto del guadagno ottenuto correggendolo se questa è una situazione molto rara .

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

Poche osservazioni posso offrire:

1. Il team ha bisogno di un lead che prenderà la decisione definitiva in caso di disaccordo. Nell'ultima uscita ero in una squadra senza leadership ed è stato 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 sia la decisione scelta, tutti i membri del team DEVONO capire che cosa dice il lead. Ecco perché la direzione lo ha reso il protagonista.

2. Mantenere le persone felici è molto importante. Pertanto, invece di spingere l'intero team verso il tuo punto di vista, spingili lì. Spiegare i principi SOLID, spiegare l'importanza di classi / metodi / interfacce piccoli e coesi e ripetere queste cose ogni volta che vengono violati (ad esempio 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 l'espressione personale e gli standard di gruppo seguenti. Si spera che i due convergeranno mentre le preferenze personali si spostano sul modo in cui il gruppo in generale sta operando.

3. Credo che sia molto più importante avere interfacce di classe pulite e facili da capire, che non avere mai un codice "intelligente". Ad esempio, abbiamo una classe che mantiene un elenco di voci che sono ricercate 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, la vedo non scalare molto bene. Sto per sostituirlo con una classe diversa, che utilizza contenitori Boost Intrusive. Ogni elemento supporterà l'inserimento 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 amano Boost, ma all'esterno rimarranno 3 metodi: Aggiungi, Rimuovi, Scarica. La linea di fondo è che le persone possono scrivere qualunque codice vogliano (entro limiti ragionevoli), ma le interfacce NON DEVONO essere intelligenti.

4. Mantenere l'idea della proprietà del codice. Anche se a volte è difficile da raggiungere, è possibile che persone diverse debbano aggiungere / modificare del codice. Quando il codice è scritto, lo sviluppatore originale è il custode ultimo di quel codice. Ciò non significa che nessun altro possa toccarlo. Se altri modificano il loro codice, va bene, ma alla fine della giornata lo sviluppatore originale lo revisiona e rimane responsabile per tutto ciò che accade lì dentro. Se quel codice è semplice o intelligente, è il suo bambino. Se / quando, come si preannuncia, i bug iniziano ad accumularsi a causa delle decisioni di progettazione / codifica che sono state fatte, invece di correggere semplicemente questi bug mentre entrano, siediti con quello sviluppatore (che dovrebbe risolvere tutti questi bug) e riflettere su quelle decisioni per vedere come avrebbero potuto essere fatte in modo diverso. Poi dagli un libro sul refactoring e vedi come puoi "scovarlo" in parte.

Ho trascorso 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 attraverso l'esperienza che scegliere le tue battaglie è una delle abilità più difficili da imparare come guida di una squadra. Sì, gli standard sono importanti. Sì, la leggibilità e la manutenibilità sono incredibilmente importanti. Sì, dovremmo tutti sforzarci di scrivere un codice uniforme e conforme agli standard. Gli sviluppatori sono esseri umani però ... non strumenti di generazione del codice. Abbiamo personalità, opinioni, ci annoiamo e vogliamo imparare cose nuove.

On code reviews at work I have been seeing code & patterns that I consider "clever" though not necessarily adding to the overall quality or maintainability of the code base.

OK ... quindi non aggiungono, ma fanno danno? Stiamo parlando solo di preferenze personali negli stili di codifica, o il codice è stato scritto completamente non necessario (ad esempio usando alberi di espressione e riflessi solo perché è divertente usare alberi di espressione e riflessioni)? Se è il primo, lascia andare. Parte del divertimento di essere uno sviluppatore sta arrivando con soluzioni creative ai problemi. Forse (e molti di noi non amano ammetterlo), a volte ci sentiamo intimiditi da approcci che non comprendiamo, e o non vogliamo chiedere o non avere l'energia aggiuntiva per imparare il nuovo approccio.

Ora, quando la creatività porta a codice non necessario e complessità completamente ingiustificabile, allora è assolutamente vocale e fai il tuo caso. Essere un giocatore di squadra è importante, ma lo è anche l'essere (e il ritenerne altri) responsabili. Le revisioni del codice riguardano la responsabilità tanto quanto la garanzia della qualità e l'apprendimento. Stai per calpestare le dita dei piedi, ma se pensi di avere una strong argomentazione sul perché lo sforzo (denaro) dovrebbe essere speso per riscrivere il codice di lavoro E un ego dovrebbe essere ferito 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 della squadra, questo è il tuo lavoro. Sii consapevole dell'impatto e fallo. Se non sei un caposquadra e non hai l'autorità, allora mettilo in squadra per decidere.

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

In base all'esperienza personale, quando ciò accade, chiedo il permesso di essere un tester dell'unità adversariale volontario per scrivere test per torturare un'implementazione non familiare.

Cercherò davvero di capire veramente come funziona il codice, e cercherò 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 della settimana. La sua giustificazione dipende dal fatto che la complessità del codice sia commisurata alla complessità del requisito.

Se non prevalesse, cioè se il codice sopravvivesse alle molte prove, mi convincerei che forse l'implementazione è veramente più illuminata di quanto non lo sia io e sosterrò la sua inclusione nel prodotto principale.

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

La mia risposta è colorata dalla mia esperienza nell'uso di OpenCV. Esistono algoritmi molto più sofisticati di quelli che i programmatori possono implementare da soli; nemmeno i dottorati di ricerca - forse le percentuali più alte dei dottori di ricerca. Se il codice è quello buono, devi aver fiducia in esso, agire contro i tuoi stessi istinti e pregiudizi, anche se non hai mezzi efficaci per quantificare quel livello di fiducia.