Qual è il valore effettivo di uno stile di codice coerente


47

Faccio parte di un team di consulenti che implementa una nuova soluzione per un cliente. Sono responsabile della maggior parte delle revisioni del codice sul codebase lato client (React e javascript).

Ho notato che alcuni membri del team usano schemi di codifica univoci al punto che potrei scegliere un file a caso per dire chi era l'autore dal solo stile.

Esempio 1 (funzioni inline una tantum)

React.createClass({
  render: function () {
    var someFunc = function () {
      ...
      return someValue;
    };
    return <div>{someFunc()}</div>
  }
});

L'autore sostiene che assegnando un nome significativo a someFunc il codice sarà più facile da leggere. Credo che integrando la funzione e aggiungendo un commento si possa ottenere lo stesso effetto.

Esempio 2 (funzioni non associate)

function renderSomePart(props, state) {
    return (
      <div>
        <p>{props.myProp}</p>
        <p>{state.myState}</p>
      </div>
    );
}

React.createClass({
  render: function () {
    return <div>{renderSomePart(this.props, this.state)}</div>;
  }
});

Questo è il modo in cui lo facciamo di solito (evita il passaggio di stato e oggetti di scena):

React.createClass({
  renderSomePart: function () {
    return (
      <div>
        <p>{this.props.myProp}</p>
        <p>{this.state.myState}</p>
      </div>
    );
  },
  render: function () {
    return <div>{this.renderSomePart()}</div>;
  }
});

Sebbene questi schemi di codifica siano tecnicamente corretti, non sono coerenti con il resto della base di codici né con lo stile e gli schemi che Facebook (l'autore di React) suggerisce nei tutorial e negli esempi.

Dobbiamo tenere un ritmo veloce per consegnare in tempo e non voglio caricare inutilmente la squadra. Allo stesso tempo, dobbiamo avere un livello di qualità ragionevole.

Sto cercando di immaginarmi come lo sviluppatore della manutenzione dei clienti di fronte a incongruenze come queste (ogni componente potrebbe richiedere che tu comprenda un altro modo di fare la stessa cosa).

Domanda:

Qual è il valore percepito dal cliente e dai suoi sviluppatori di manutenzione di una base di codice coerente rispetto a consentire a incongruenze come queste di rimanere e potenzialmente diffondersi?


50
Qual è il valore di un'ortografia coerente? Un'accelerazione permanente e costante nella lettura e nella scrittura di testi. Qual è il valore di uno stile di codice coerente? Un'accelerazione permanente e costante nella lettura e nella scrittura del codice. Cos'altro potresti desiderare?
Kilian Foth,

9
Quando leggi le cose, ti abitui ai modelli di ciò che stai leggendo e arrivi ad anticipare come leggere le cose future. Se non c'è coerenza, non si possono prevedere schemi e occorre fare una maggiore interpretazione del codice, rallentando il lettore.
Canadian Coder

1
Joel ha alcune buone idee su questo argomento. In breve, un buon standard di codifica rende i bug facili da vedere. joelonsoftware.com/articles/Wrong.html

13
Voglio aggiungere che le funzioni con nome sono quasi sempre preferite alle funzioni anonime in JavaScript. Quando esegui il debug, questo ti aiuta a determinare dove ti trovi nello stack.
Mike McMahon,

1
@yoniLavi dovresti chiederlo su meta.
RubberDuck,

Risposte:


48

Vantaggio di trasferimento del codice

Seguire i modelli forniti da una libreria, Reactnel tuo caso, significa che il prodotto che consegnerai sarà facilmente ritirato e gestito da altri sviluppatori che hanno anche familiarità con React.

Potenziali problemi di compatibilità con le versioni precedenti

Alcune librerie avrebbero una nuova versione principale in uscita e la compatibilità con le versioni precedenti potrebbe essere compromessa se i tuoi pattern sono significativamente diversi, rallentando / arrestando il tuo futuro aggiornamento. Non sono sicuro di come Reactgestire le nuove versioni, ma l'ho già visto accadere prima.

I nuovi membri del team iniziano a essere produttivi più rapidamente

Se segui ciò che viene fornito dall'autore, è più probabile che tu assumi sviluppatori di talento usando il tuo framework e li avvii più velocemente con il tuo sistema piuttosto che insegnare nuovi schemi.

Potenziali problemi non ancora scoperti

In futuro potrebbero esserci problemi che non hai ancora scoperto con il tuo approccio, risolti dall'approccio dell'autore.

Detto questo, l'innovazione è sempre un rischio, se senti fortemente che il tuo approccio è migliore e funziona per il tuo team, provaci!


Grazie per questi punti eccellenti. In genere seguiamo gli schemi forniti dalla biblioteca. Gli esempi che ho fornito (trovati nelle recensioni dei codici) si discostano. Sono stato preoccupato che il cliente potesse rifiutare e richiederci di rifare una parte della nostra consegna perché non "sembrava e non reagiva". Ora so perché lo farebbero.
Andreas Warberg,

2
+1 "rather than teaching new patterns": l'addestramento procedurale è una perdita di tempo molto grande con nuovi assunti.
Sforzati

1
@Alexus: per quanto riguarda la compatibilità con le versioni precedenti, React non è ancora alla versione 1.0. La versione attuale, 0.13, ha interrotto la compatibilità in alcuni modi piuttosto drastici, anche se il verificarsi di questi guasti dipende dal meccanismo utilizzato per chiamare i componenti di React. Avere regole molto coerenti su come chiamare React potrebbe non impedire agli aggiornamenti di React di violare il codice, ma la correzione di un codice coerente è più facile, più veloce e più affidabile. Le tue preoccupazioni in merito a problemi di compatibilità con le versioni precedenti sono decisamente giustificate nel caso di React. Ad esempio, vedi il mio commento su stackoverflow.com/a/20913637/18192
Brian

53

Le incoerenze ti fanno fermare e pensare al perché , quale e dove :

  • Quando leggi parte del codice e vedi che utilizza uno stile diverso dal resto del codice, ti viene da chiederti: perché questa particolare parte è diversa? Ha un motivo speciale di cui devo essere consapevole? Questo è pericoloso, perché se c'è davvero una ragione per cui quella parte è diversa, devi esserne consapevole oppure potresti creare dei bug cattivi. Quindi, invece di pensare al problema originale che ti ha fatto andare a toccare quel codice, ora perdi tempo a pensare al perché è diverso, e non puoi capirlo, quindi vai dall'autore originale per chiedere loro, perdendo anche il loro tempo, e peggio ancora: nel processo entrambi perdete il modello mentale dei problemi a cui stavate lavorando.

    Moltiplicare per ogni altro sviluppatore del team che deve toccare / leggere quel codice.

  • Quando devi aggiungere un codice che utilizza più stili, devi interrompere e decidere quale stile utilizzare per la tua aggiunta. Devi prendere abbastanza decisioni che contano - è una perdita di tempo perdere tempo a pensare a decisioni che non contano.

  • Quando lo stile è coerente, è facile spostarsi all'interno del codice, poiché la coerenza ti aiuta a trovare rapidamente dove si trovano gli elementi. Con uno stile incoerente, anche il grepping diventa più difficile perché non sai quale stile sta usando la cosa che stai cercando.


6
Ottima intuizione fanatica. Perché alcuni sviluppatori sembrano semplicemente "ottenerlo" e altri lo combattono?
Dogweather,

2
Sospetto perché uno stile coerente proposto ora è profondamente in contrasto con ciò su cui hanno lavorato in progetti precedenti. Soprattutto per quelli con una notevole esperienza in diversi ambienti.
Calcio d'

4

Il codice potrebbe essere ben scritto ma non perfettamente coerente, quindi ad alcuni clienti non importa. Quando le cose iniziano a andare male, vuoi dare loro un altro colpo contro di te? Se assumessi un'azienda per lavorare su un progetto multi-sviluppatore e non mi indicassero che hanno uno standard di codifica e lo seguono, sarei scettico.

Dobbiamo tenere un ritmo veloce per consegnare in tempo e non voglio caricare inutilmente la squadra.

Fintanto che gli standard di codifica non sono troppo folli, non dovrebbe essere così difficile per tutti salire a bordo. I progetti si bloccano perché le persone non sanno quale codice scrivere o meno e non a causa della digitazione e della formattazione. Saprai di essere andato troppo lontano quando ci vorrà una quantità sproporzionata di tempo per aderire. Spero che questo non sia il tuo primo rodeo.

Esegui il tuo test Tutto ciò che devi fare è cambiare i compiti a metà strada da uno sviluppatore all'altro e farli finire il file di qualcun altro. Passano il tempo a riformattare completamente le cose per la loro versione? È troppo difficile da seguire? Andrà peggio per il team di manutenzione del cliente.


2

Ho avuto fortuna a trattare gli stili di codice proprio come io tratto gli stili di scrittura in inglese naturale. C'è una vasta gamma di stili dall'inglese colloquiale, che imita il modo in cui parliamo nella conversazione di tutti i giorni, fino all'inglese formale, che è spesso pesante e ostacolato da un significato sempre molto preciso.

Considera come vorresti che fosse il prodotto finale in quel senso. Alcune situazioni sono molto favorevoli all'utilizzo di qualunque struttura sia la migliore al momento. Altri richiedono una cadenza e una struttura uniformi. Ciò è particolarmente vero se il tuo prodotto è meglio se come se fosse scritto in inglese formale. In questo caso i colloquialismi possono essere d'aiuto, ma lacerano la sensazione generale del prodotto.

In generale, più coerente è il tuo standard di codifica, minore è lo sforzo che uno sviluppatore deve fare per attirare la sua attenzione su qualcosa di interessante. Se supporti una grande diversità negli standard di codifica, gli sviluppatori devono essere più forti quando annunciano che stanno facendo qualcosa di insolito o unico. Questo tentativo di esprimere ciò che uno sviluppatore considera importante può spesso oscurare la gamma dinamica del codice stesso. Quando ciò accade, è facile far passare i bug perché è semplicemente troppo difficile vederli.

Il rovescio della medaglia di tale argomento, più i tuoi standard di codifica sono più ampi, più gli sviluppatori di libertà devono adattare la loro sintassi al problema. In contrasto ironico con l'argomento degli standard di codifica professionale, troppa standardizzazione può portare a una struttura di codice compromessa, che può anche rendere facile far passare i bug.

Quello che stai cercando è il mezzo felice della tua squadra.


2

Come molti altri hanno sottolineato, quando gli sviluppatori di manutenzione devono seguirti, una sezione di codice in uno stile diverso li farà fermare e provare a capire cosa c'è di speciale in quella sezione. C'è anche il rischio molto reale che lo stile incoerente venga propagato ad altre sezioni, risultando in un grande casino in seguito.

Ho l'impressione che, nel profondo, tu sappia già la risposta a questa domanda e non lo avresti nemmeno affrontato se non fosse stato per questo:

Dobbiamo tenere un ritmo veloce per consegnare in tempo e non voglio caricare inutilmente la squadra.

Questo sembra sempre essere il compromesso universale ... farlo veloce contro farlo nel modo giusto. Solo tu puoi valutare le conseguenze del sacrificio di buone pratiche di codifica sull'alterazione delle scadenze dei clienti. Tuttavia, devo essere d'accordo con JeffO quando osserva che seguire uno stile di codifica (forse insolito o controintuitivo) non dovrebbe rallentare la tua squadra in modo così drastico che le scadenze scendano in modo significativo.

Sebbene conosca questo concetto da anni, solo recentemente ho imparato il termine " debito tecnico ". Devi davvero considerare il debito tecnico che alla fine dovrà essere pagato se non segui uno stile disciplinato ora.

Sfortunatamente, come affermato da eBusiness, a meno che il cliente non sia particolarmente esperto o non manterrà il codice in seguito, è difficile per loro apprezzare il valore di standard di codifica coerenti. Tuttavia, qualsiasi uomo d'affari ragionevole dovrebbe essere in grado di comprendere il concetto che "un po 'di manutenzione preventiva ora" (sotto forma di una buona codifica) "aiuterà a evitare significativi costi di riparazione in seguito" (sotto forma di tempo di sviluppo sprecato in seguito per ripulire il pasticcio).


Il cliente è tecnicamente esperto e molto probabilmente assumerà la manutenzione e l'ulteriore sviluppo della soluzione ad un certo punto. Lo sforzo di domande e risposte finora si è concentrato sul layout visivo e non tanto sulla funzionalità. Una volta che i bug di funzionalità iniziano ad arrivare, avremo la sensazione di come sia la manutenzione. Penso che le revisioni del codice sarebbero più veloci con maggiore coerenza (riducono nuovi modi sorprendenti di fare la stessa cosa). Il cliente ovviamente vuole la massima coerenza (ma forse non pagare un extra).
Andreas Warberg,

2

Le risposte votate qui ripetono le migliori pratiche teoriche facilmente accettabili che descrivono in dettaglio come vorremmo che fossero tutti i nostri codebase. Ma il vero codice in qualche modo non sembra mai così. Se provi a creare quella base di codice perfetta, quasi inevitabilmente fallirai. Questo non vuol dire che non dovremmo cercare di fare di meglio, ma ci deve essere un limite per quanto lontano dal realisticamente realizzabile stabiliamo i nostri obiettivi.

Troppa attenzione a cose minori ha il rischio di perdere attenzione su questioni più importanti, come come risolvere il lavoro nel modo più efficiente in generale.

Non vorrei riferirti al tuo primo esempio come stile, lo stile è le scelte in cui non esiste un chiaro o giusto, in questo caso la funzione extra è il gonfiamento del codice senza vantaggi. Sono solo 2 righe extra, ancora facili da leggere e facili da correggere, quindi questo esempio in sé non è un grosso problema.

Il problema molto più grande è il gonfiore del codice contorto. Funzioni wrapper, gerarchie di classi e ogni sorta di altri costrutti, in cui il codice circostante è abbastanza complesso da non essere ovvio che non servono allo scopo reale. Se nel codice è presente un gonfiamento evidente, è probabilmente presente un gonfiamento molto più evidente. È molto più difficile fare qualcosa, e più difficile da individuare, ma anche un problema molto più grande.

Sui clienti

I clienti tendono a concentrarsi su come ottenere un prodotto funzionante che risolva le loro esigenze. Anche se hai uno dei pochi clienti che si preoccupano della qualità del codice, sarà una priorità secondaria e la loro idea della qualità del codice potrebbe non essere perfettamente coerente con la tua. La società cliente può avere i suoi programmatori, ma è comunque la direzione che deciderà se hai fatto o meno un buon lavoro, e molto probabilmente la direzione non sa nemmeno cosa significhi qualità del codice.


Durante la revisione del codice cerco diverse cose che ritengo siano sicuramente importanti come la manipolazione diretta del DOM, stringhe non localizzate rivolte all'utente, opportunità di riutilizzo (un componente esistente, un aiuto, una libreria di terze parti già caricata ecc.), Modifiche incompatibili o improprie al codice condiviso, deviazione dalle convenzioni del cliente e del team. Il valore della coerenza dello stile e dei modelli di codifica non mi era chiaro, quindi non ero sicuro di come rispondere a quelli nelle recensioni di codice.
Andreas Warberg,

0

Riguarda molto la leggibilità delle differenze. Se lo stile del codice si blocca, le differenze nascondono le modifiche senza significato semantico per il programma e possono rendere le fusioni difficili o impossibili.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.