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 recensioni di codice sulla codebase lato client (React e javascript).

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

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 ad alcuniFunc 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 (evita di passare 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 del codice base, né con lo stile e i modelli che Facebook (l'autore di React) suggerisce in tutorial ed esempi.

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

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

Domanda:

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

    
posta Andreas Warberg 07.07.2015 - 22:11
fonte

7 risposte

48

Vantaggio trasferimento codice

I seguenti modelli forniti da una libreria, React nel tuo caso, indicano che il prodotto che offri sarà facilmente raccolto e gestito da altri sviluppatori che hanno familiarità con React.

Potenziali problemi di compatibilità con le versioni precedenti

Alcune librerie dispongono di una nuova versione principale e la compatibilità con le versioni precedenti potrebbe essere compromessa se i tuoi pattern sono significativamente diversi, rallentando / fermando il tuo aggiornamento futuro. Non sono sicuro di come React gestirà le nuove versioni, ma ho già visto questo in precedenza.

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

Se segui ciò che viene fornito dall'autore, è più probabile che tu ingagga sviluppatori di talento utilizzando il tuo framework e avvialo più rapidamente con il tuo sistema piuttosto che insegnare nuovi modelli.

Potenziali problemi non scoperti

Potrebbero esserci problemi in futuro che non hai ancora scoperto con il tuo approccio, che sono risolti dall'approccio dell'autore.

Detto questo, l'innovazione è sempre un rischio, se ritieni che il tuo approccio sia migliore e funzioni per il tuo team, fallo!

    
risposta data 07.07.2015 - 22:25
fonte
53

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

  • Quando leggi una parte del codice e vedi che utilizza uno stile diverso dal resto del codice, ti chiedi: perché questa parte è diversa? Ha una ragione speciale di cui devo essere consapevole? Questo è pericoloso, perché se c'è davvero un motivo per cui quella parte è diversa devi essere consapevole di ciò, altrimenti potresti creare alcuni 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 riesci a capirlo, quindi vai all'autore originale per chiedere loro, perdendo anche il loro tempo, e ancora peggio: nel processo perdi entrambi il modello mentale dei problemi su cui stavi lavorando.

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

  • Quando è necessario aggiungere a un codice che utilizza più stili, è necessario interrompere e decidere lo stile quale da utilizzare per l'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, perché la coerenza ti aiuta a trovare rapidamente dove si trova . Con lo stile incoerente, anche lo sbroglio diventa più difficile perché non sai quale stile sta usando la cosa che stai cercando.

risposta data 07.07.2015 - 22:37
fonte
4

Il codice potrebbe essere ben scritto ma non perfettamente coerente, quindi ad alcuni clienti non interessa. Quando le cose cominciano a peggiorare, vuoi darle un altro colpo contro di te? Se assumessi un'azienda per lavorare su un progetto multi-sviluppatore e non mi avessero indicato che avevano uno standard di codifica e lo seguissi, sarei scettico.

We need to keep a fast pace in order to deliver on time and I don't want to burden the team unnecessarily.

Finché gli standard di codifica non sono troppo pazzi, non dovrebbe essere così difficile per tutti salire a bordo. I progetti vengono bloccati perché le persone non sanno quale codice scrivere o non scrivere e non a causa della digitazione e della formattazione. Saprai che sei andato lontano quando ci vuole un tempo sproporzionato per aderire. Spero che questo non sia il tuo primo rodeo.

Esegui il tuo test Tutto quello che devi fare è passare le assegnazioni a metà strada da un dev all'altro e farle finire il file di qualcun altro. Passano del tempo a riformattare completamente le cose alla loro versione? È troppo difficile da seguire? Sarà peggio per il team di manutenzione del tuo cliente.

    
risposta data 07.07.2015 - 22:31
fonte
2

Ho avuto la fortuna di trattare gli stili di codice proprio come considero gli stili di scrittura in inglese naturale. C'è una vasta gamma di stili dall'inglese conversazionale, che imita il modo in cui parliamo nella conversazione di tutti i giorni, nell'inglese formale, che è spesso pesante e truccato da sempre molto preciso nel suo significato.

Pensa a cosa vorresti che il prodotto finale assomigliasse in quel senso. Alcune situazioni sono di grande aiuto nell'usare qualsiasi struttura sia la migliore al momento. Altri richiedono una cadenza e una struttura uniformi. Questo è particolarmente vero se il tuo prodotto è il meglio di come se fosse scritto in inglese formale. In questo caso, i colloquialismi possono essere d'aiuto, ma sono una lacerazione della sensazione generale del prodotto.

In generale, più coerente è lo standard di codifica, minore è lo sforzo che uno sviluppatore deve compiere per richiamare la propria attenzione su qualcosa di interessante. Se si supporta una grande diversità negli standard di codifica, gli sviluppatori devono essere più rumorosi 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 degli errori perché è semplicemente troppo difficile vederli.

Sul rovescio della medaglia, più sciolti sono gli standard di codifica, più gli sviluppatori di libertà devono adattare la loro sintassi al problema. In ironico contrasto con l'argomentazione degli standard pro-coding, un'eccessiva standardizzazione può portare a una struttura stilistica del codice, che può anche facilitare l'insinuazione degli errori.

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

    
risposta data 09.07.2015 - 01:10
fonte
2

Come molti altri hanno sottolineato, quando gli sviluppatori di manutenzione devono seguirti, una sezione di codice in uno stile diverso li fermerà e cercherà di capire cosa è speciale in quella sezione. Esiste anche il rischio reale che lo stile inconsistente venga propagato ad altre sezioni, causando un enorme disordine in seguito.

Ho l'impressione che, in fondo, tu sappia già la risposta a questa domanda, e non avresti nemmeno la possibilità di affrontarla se non fosse per questo:

We need to keep a fast pace in order to deliver on time and I don't want to burden the team unnecessarily.

Questo sembra essere sempre il trade-off universale ... farlo velocemente vs farlo nel modo giusto. Solo tu puoi valutare le conseguenze del sacrificare buone pratiche di codifica sull'alterazione delle scadenze dei clienti. Tuttavia, devo concordare con JeffO quando osserva che seguire uno stile di codifica (possibilmente insolito o controintuitivo) non dovrebbe rallentare la tua squadra in modo così drastico che le scadenze scendono significativamente.

Sebbene conosca il concetto da anni, ho appreso solo di recente il termine " debito tecnico" ". Hai davvero bisogno di considerare il debito tecnico che alla fine dovrà essere pagato se non segui uno stile disciplinato ora.

Sfortunatamente, come dichiarato da eBusiness, a meno che il cliente non sia particolarmente esperto dal punto di vista tecnico o in seguito si manterrà il codice, è difficile per loro apprezzare il valore degli standard di codifica coerenti. Tuttavia, ogni ragionevole uomo d'affari dovrebbe essere in grado di cogliere il concetto che "un po 'di manutenzione preventiva ora" (sotto forma di buona codifica) "aiuterà a evitare costi di riparazione significativi in seguito" (sotto forma di tempo di sviluppo sprecato dopo la pulizia del pasticcio).

    
risposta data 09.07.2015 - 04:14
fonte
2

Le risposte più votate qui ripetono le pratiche teoriche facilmente condivisibili che descrivono dettagliatamente il modo in cui vorremmo che fossero le nostre codebase. Ma il codice reale 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 meglio, ma ci deve essere un limite per quanto lontani dal raggiungere realisticamente i nostri obiettivi.

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

Non mi riferirò al primo esempio come stile, lo stile è la scelta in cui non vi è alcun chiaro o sbagliato, in questo caso la funzione extra è il codice gonfio senza rialzo. Sono solo 2 righe aggiuntive, ancora facili da leggere e facili da correggere, quindi questo esempio non è un grosso problema.

Il problema più grande è il complicato numero di codice. Funzioni wrapper, gerarchie di classi e tutti i tipi di altri costrutti, in cui il codice circostante è abbastanza complesso da non risultare ovvio che non servano a scopi reali. Se il codice è evidentemente gonfio, probabilmente c'è molto più evidente non evidente. È molto più difficile fare qualcosa, e più difficile da individuare, ma anche un problema molto più grande.

Informazioni sui clienti

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

    
risposta data 08.07.2015 - 16:05
fonte
0

È molto importante la leggibilità dei diff. Se lo stile del codice si aggroviglia, le differenze si nascondono senza alcun significato semantico per il programma e possono rendere le fusioni difficili o impossibili.

    
risposta data 08.07.2015 - 21:09
fonte

Leggi altre domande sui tag