Se la mia squadra ha poca abilità, dovrei abbassare l'abilità del mio codice? [chiuso]

Ok, ecco la mia opinione su questo argomento grande e complicato.

Pro per mantenere lo stile di codifica:

• Cose come x = x || 10 sono idiomatiche nello sviluppo di JavaScript e offrono una forma di coerenza tra il tuo codice e il codice delle risorse esterne che usi.
• Il livello più elevato di codice è spesso più espressivo, sai cosa ottieni ed è più facile da leggere tra professionisti altamente qualificati.
• Ti divertirai di più il tuo lavoro. Io personalmente valore creando un bel codice. Penso che mi porti molte soddisfazioni nel mio lavoro.
• Generalmente crea uno stile più leggibile. Attenersi agli idiomi della lingua può essere molto prezioso: spesso sono idiomi per una ragione.

Contro per mantenere lo stile di codifica:

• Sarà più difficile per i programmatori di livello inferiore tenere il passo. Queste sono spesso le persone che mantengono il tuo codice e quelle che dovranno leggere effettivamente le cose che scrivi.
• Manutentori del codice, spesso il codice JavaScript proviene da altre lingue. I tuoi programmatori potrebbero essere competenti in Java o C # ma non capire come e quando JavaScript differisce esattamente. Questi punti sono spesso idiomatici - un espressione di funzione immediatamente invocata (IIFE) è un esempio di tale costrutto.

La mia opinione personale

Non dovresti abbassare l'abilità del tuo codice. Dovresti aspirare a scrivere un codice che sia espressivo, chiaro e conciso. Se hai dei dubbi sul livello della tua squadra, educali . Le persone sono più che disposte a imparare di quanto si possa pensare, e sono disposte ad adattare nuovi costrutti quando sono convinti di essere migliori.

Se pensano che tu sia "solo intelligente", prova a discutere il tuo punto. Sii disposto ad ammettere che a volte ti sbagli e, indipendentemente da cosa, prova a mantenere gli stili coerenti in tutto il tuo ambiente di lavoro. Fare così aiuterà ad evitare l'ostilità.

La cosa più importante è rimanere coerenti.

Il codice di una squadra dovrebbe essere scritto come se una persona lo codificasse. Devi assolutamente essere d'accordo sulle linee guida sulla codifica. Dovresti rispettare queste linee guida. Se le linee guida di codifica specificano che la lettura dei parametri opzionali dovrebbe essere fatta nel modo "meno intelligente", allora questo è il modo.

Commento Bene

Dovresti abbassare la capacità del tuo codice? Non necessariamente, ma dovresti aumentare decisamente l'abilità dei tuoi commenti . Assicurati di includere buoni commenti nel tuo codice, specialmente intorno alle sezioni che ritieni possano essere più complicate. Non usare così tanti commenti che il codice diventa difficile da seguire, ma assicurati di rendere chiaro lo scopo di ogni sezione.

La realtà è che essere un po 'più prolissi con commenti può essere utile con membri meno esperti del team, ma quelli con l'abilità più bassa li ignorano, specialmente se ce ne sono troppi, quindi non esagerare.

A Matter of Style?

L'esempio che hai fornito è in qualche modo basilare, ma anche piuttosto stilistico. Un commento su ogni variabile predefinita sarebbe piuttosto noioso da mantenere e leggere. Invece, le scorciatoie stilistiche o ripetute o i modelli di codice dovrebbero probabilmente essere stabiliti come standard. Se pensi che qualcosa come quella forma di default dei parametri debba essere compresa da tutti e utilizzata ogni volta, scrivi queste idee e prendi loro alla guida della tua squadra. È possibile che tutto ciò che serve per insegnare ai tuoi compagni di squadra sia un incontro semplice in cui discuti degli standard che hai proposto.

Come già affermato in un'altra risposta, mantieni coerente .

Insegna a un uomo a pescare ...

Insegnare ai tuoi compagni di squadra è probabilmente il modo migliore per aiutare tutte le persone coinvolte. Fai in modo che chiunque abbia una domanda su un pezzo di codice con il tuo nome nel log di commit o nei timestamp libero di chiederlo a riguardo. Se la tua squadra ha revisioni del codice, questa è una grande opportunità per spiegare qualsiasi codice (ehm) ben commentato che possa confondere i tuoi compagni di squadra. Se la tua squadra non ha recensioni sul codice, perché no? Vai ad esso!

Devi stare attento, però. Potresti non essere sempre in giro per insegnare alle persone e potresti addirittura dimenticare ciò che cercavi in origine in una determinata sezione di codice.

Trucchi "intelligenti"

Tenere a mente le abilità dei tuoi compagni di squadra è sicuramente importante, ma scrivere codice gestibile spesso significa non usare scorciatoie arcane a problemi che potrebbero avere soluzioni più comuni. Questo è importante anche quando i tuoi compagni di squadra sono intelligenti. Non vuoi rendere il codice troppo lungo da cogliere o avere effetti collaterali impercettibili ma importanti che potrebbero mancare. In generale, è meglio evitare i trucchi "intelligenti" quando ci sono alternative adatte. Non si sa mai chi potrebbe dover mantenere il codice lungo la linea - spesso le versioni precedenti di noi stessi non ricorderanno i dettagli o ragioni per questi trucchi.

Se trovi che devi attuare un trucco intelligente, segui almeno il prossimo consiglio ...

BACIO

In caso di dubbi, mantieni semplice . Se il codice è semplice o no non lo fa t corrisponde necessariamente all'abilità del programmatore come si potrebbe pensare. In effetti alcune delle soluzioni più brillanti per un problema sono le più semplici e alcune delle soluzioni più complesse finiscono su TheDailyWTF . Mantenere il tuo codice semplice e conciso può rendere più facili da afferrare alcune delle decisioni più intelligenti ma anche contro-intuitive.

Sembra esserci un'enorme avversione per la creazione di una funzione in JS. Questa avversione fa sì che le persone cerchino di essere intelligenti e usino trucchi ridicoli solo per mantenere roba in una riga come sarebbe stata una chiamata di funzione. Ovviamente la funzione il nome in una chiamata funge anche da documentazione aggiuntiva. Non possiamo allegare un commento a un'espressione ingannevole perché poi avrebbe vanificato il punto di farlo quindi lo chiamiamo "js idiom" e all'improvviso è comprensibile.

Javascript è estremamente accessibile, la maggior parte delle persone non mangia le specifiche per colazione come noi facciamo. Quindi non capiranno mai quali sono le ipotesi nascoste e i casi limite di un idioma è.

x = x || 'default_value';

Il joe medio non lo capirà o ha memorizzato che è l'idioma per il valore predefinito. Entrambi sono dannosi, infatti il secondo è ancora più dannoso. lui non capirò le ipotesi e i casi limite qui. Non gli interesserà leggere le specifiche e capirlo sempre.

Quando guardo quel codice vedo "se è null o undefined , quindi impostalo su questo valore predefinito. tratterà implicitamente anche +0 , -0 , NaN , false e "" come valori non adatti. dovrò ricordati che 3 mesi da ora in poi che deve cambiare. Probabilmente lo dimenticherò. "

L'ipotesi implicita è estremamente probabile che causi un bug in futuro e quando la tua base di codice è piena di trucchi come questo allora non c'è alcuna possibilità che tu li tenga tutti nella tua testa ogni volta che stai pensando a cosa una modifica interesserà. E questo è per il "JS pro", il joe medio avrebbe scritto il bug anche se i requisiti dovessero accettare un valore falsato all'inizio.

Il tuo nuovo snippet ha una sintassi più familiare ma presenta ancora il problema sopra riportato.

Puoi andare con:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

Ora puoi avere una logica molto complessa per gestire i casi limite e il codice cliente sembra ancora bello e leggibile.

Ora, come si fa a distinguere tra funzionalità linguistiche avanzate come passare una funzione come argomento o un trucco intelligente mi piace || "default" ?

I trucchi intelligenti funzionano sempre sotto alcune ipotesi nascoste che potrebbero essere ignorate quando il codice è stato inizialmente creato. Lo farò non devo mai modificare un IIFE in qualcos'altro perché un requisito è cambiato, sarà sempre lì. Forse nel 2020, quando posso usare moduli reali ma sì.

| 0 o la versione di culto cargo ~~num utilizzata per pavimentazione presuppone limiti di interi con segno positivo e 32 bit.

|| "default" presuppone che tutti i valori di falsy siano gli stessi di non passare affatto un argomento.

E così via.

Non dovresti abbassare la tua abilità di programmazione, ma potresti dover regolare come scrivere codice. L'obiettivo, quasi soprattutto, è rendere il tuo codice chiaro alle persone che devono leggerlo e mantenerlo.

Sfortunatamente può essere un po 'un giudizio se uno stile particolare è "intelligente" o solo un uso avanzato. Il codice nella domanda è un buon esempio di questo: la tua soluzione non è necessariamente migliore dell'altra. Alcuni sostengono che sia, alcuni non saranno d'accordo. Poiché entrambe le soluzioni hanno effettivamente prestazioni di runtime uguali (leggi: l'utente non conoscerà mai la differenza), scegli lo stile con cui il team nel suo complesso è più a suo agio.

In alcuni casi è necessario insegnare loro modi migliori per codificare, ma in altri casi è necessario scendere a compromessi nell'interesse della chiarezza.

Questo potrebbe essere già stato detto in un'altra risposta, ma vorrei rispondere a questa domanda con i miei ordini.

Linee guida generali

Quando lavori su una squadra, non sei il pubblico di destinazione di un pezzo di codice. Il tuo pubblico è lo sviluppatore della tua squadra. Non scrivere codice che non possono capire senza una buona ragione.

1. A meno che non vi sia uno svantaggio specifico, tutto il codice dovrebbe essere scritto seguendo uno schema o una linea guida specifica che consentirà una facile manutenzione da parte degli sviluppatori che la manterranno. (Un avvertimento: seguire cattivi modelli solo perché sono attualmente nella base del codice è una pratica terribile.)
2. Se riesci a trovare un buon motivo per utilizzare un linguaggio specifico della lingua che non è facilmente leggibile dal pubblico di destinazione, aggiungi un commento. Se trovi che è necessario aggiungere un commento ad ogni altra linea, potresti voler riscrivere il tuo codice per essere più leggibile dal tuo pubblico. Non trovo utile essere idiomatico per il gusto di essere idiomatico.

Esempio specifico

Abbiamo un numero elevato di script perl nella nostra base di codice. Solitamente usiamo perl solo per operazioni molto semplici e la maggior parte del codice è scritta dagli sviluppatori java, quindi è molto simile a java. Abbiamo una serie di script perl e un framework che è stato scritto da un "perl guru" che da allora ha lasciato la nostra azienda. Questo codice contiene molti degli idiomi perl più oscuri e nessuno dei nostri sviluppatori, incluso me stesso, può leggere questo codice perl senza sforzi prolungati. Spesso lo malediciamo per questo. :)

Se scrivi un buon codice ma ritieni che i tuoi colleghi presenti o futuri possano avere difficoltà a seguirlo, dovresti aggiungere un breve commento per spiegarlo.

In questo modo, potresti insegnare loro qualcosa senza insultare la loro intelligenza individuale o imbarazzare chiunque in una discussione di gruppo.

Non definirei il tuo esempio un trucco, ma solo un idioma. Se dovessi usarlo, IMHO dipende non tanto dal livello attuale della tua squadra, ma se (almeno alcuni) i tuoi compagni di squadra sono disposti a imparare alcuni nuovi idiomi. Certo, dovresti discutere questo argomento con loro e non imporre questo stile su di essi. E non dovresti chiedere loro di imparare ogni giorno 5 cose nuove o "trucchi". Ma onestamente, se solo i compagni di squadra non sono disposti a imparare qualcosa di nuovo, anche se è così semplice e piccolo di questo idioma, dovresti considerare di passare a un altro team.

Leggendo questa domanda e le successive risposte e discussioni sembra che ci siano due punti. Il primo: è OK usare le funzionalità linguistiche avanzate? Il secondo: come posso farlo senza apparire come se fossi "in mostra"?

Nel primo caso, ha senso utilizzare miglioramenti e funzionalità avanzate. Ad esempio: in C # non è necessario utilizzare le espressioni Linq o Lambda, ma la maggior parte delle persone lo fa perché rende il codice più ordinato e più facile da capire, una volta che si è effettivamente a conoscenza di ciò che sta facendo. All'inizio sembra strano.

Le persone si abituano ai pattern e in molti casi le persone usano il modo stabilito di fare le cose solo per portare a termine il lavoro. Sono colpevole di questo come il prossimo. Abbiamo tutti delle scadenze. Per certi versi sei colpevole di aver introdotto nuove idee e nuovi modi di pensare! Questo arriva al secondo punto e questo è probabilmente il punto in cui potresti incontrare la maggior resistenza.

Per la persona che usa il sito web a cui non interessa quale stile è usato, tutto ciò che gli interessa è che funziona? È veloce? Quindi, se non vi è alcun vantaggio in termini di prestazioni, non esiste un modo giusto o sbagliato nell'esempio che si fornisce. Il tuo modo di rendere il codice più leggibile o meno? Potrebbe fare una volta che i tuoi colleghi sono abituati.

Quindi, come si introducono queste modifiche? Prova a discutere con i tuoi colleghi in questo modo: lo sapevi che questa funzione può essere scritta in questo modo? Le revisioni del codice e la programmazione della coppia possono essere dei buoni tempi per consentire una "impollinazione incrociata" di idee. È difficile per me prescrivere cosa fare perché non conosco l'ambiente in cui lavori. Trovo che alcuni programmatori possano essere molto difensivi e resistenti ai cambiamenti. Di nuovo sono stato colpevole di questo. Il modo migliore per lavorare con questi tipi di programmatori è dedicare un po 'di tempo all'apprendimento di ciò che li rende interessanti, a imparare il loro background e quindi confrontare e confrontare i tuoi stili ed esperienze con i loro. Ci vuole tempo ma è tempo ben speso. Se possibile, prova a incoraggiarli.

Allora non andare a lavorare per la Royal McBee Computer Corp, perché chi è che non sei il programmatore inesperto.

certo, è fantastico scrivere un codice teso e breve e potrebbe essere utile in un ambiente javascript (beh, fino a quando qualcuno non produce un compilatore js da scaricare nei browser, ma questa è un'altra storia).

tuttavia, ciò che è importante è la capacità del tuo codice di superare i pochi minuti necessari per scriverlo. Certo, è facile e veloce e puoi tagliarlo e andare avanti, ma se devi tornare ad anni dopo, è allora che potresti pensare "quale muppet ha scritto questo", e capire che eri tu! (L'ho fatto, certo che anche la maggior parte della gente lo ha fatto .. Do la colpa alle scadenze eccessivamente aggressive, oneste)

Questa è l'unica cosa importante da tenere a mente, quindi mentre direi di sì - vai con quel particolare operatore se funziona e è chiaro, e i tuoi sviluppatori "inesperti" (anche se, a loro è un dispregio, Conosco un sacco di sviluppatori inesperti che conoscono tutti gli operatori e i trucchi che hanno memorizzato vari tutorial e riferimenti alle pagine Web, scrivono il codice peggiore anche se sanno ogni piccolo trucco ... potrebbe esserci di più a questo rispetto alla coincidenza)

Ad ogni modo, se tu potessi leggere la storia di Mel , ti accorgerai che i trucchi non sono la cosa migliore da inserire in qualsiasi codice, anche se Mel era un vero programmatore del primo ordine. Questo mette a disposizione qualsiasi argomento in cui qualcuno afferma di poter scrivere un buon codice e tutti gli altri devono imparare di più per tenere il passo.

Bene, per i principianti che mi sembrano JS di base.

Ma in generale - non dovresti usare gli hack intelligenti, per parafrasare "il debugging è due volte più difficile della programmazione.Se scrivi codice il più intelligente possibile, allora per definizione non sei in grado di eseguirne il debug".

Questo non significa che dovresti evitare il codice solo perché gli altri non lo capirebbero: dovresti scrivere il codice nel modo più chiaro e coerente possibile. Ma i tuoi criteri chiari dovrebbero essere "lo comprenderò in prima lettura tra un anno", non "qualcuno può capirlo".

Scrivi in modo chiaro, che non hai alcuna difficoltà a capire e lascia che gli altri lavorino per aumentare le loro abilità - non ostacolare te stesso per salvare altri problemi ipotetici.

Discuterò con i miei compagni di squadra che tipo di standard di codifica vogliamo avere in quanto questo è principalmente su come dovrebbe essere fatto qualcosa in dozzine di modi per la nostra base di codice. Se c'è un consenso che sarebbe il mio primo tentativo di risposta.

Se non c'è, allora probabilmente considererò quale tipo di standard proposto ha senso e inizierò a metterlo in pratica una volta che l'avrò chiarito con il management e alcuni membri del team. L'idea qui è assicurarsi che la gestione sia a posto con questa idea e che non stia solo andando a fare le mie cose e poi costringendo tutti gli altri a prenderlo.

Guarderei questo più come la domanda su quale tipo di standard e pratiche ha il tuo team piuttosto che sul livello di abilità in quanto vi sono molti modi per valutare il codice. Quanto bene gli altri possono mantenerlo è uno di quei criteri.

Il problema è che si desidera una buona leggibilità della sorgente, ma la leggibilità è negli occhi di chi guarda.

Suggerirei che abbiamo bisogno di strumenti migliori per risolvere questo problema. Nulla di complesso, badate bene, abbiamo avuto la tecnologia per farlo da oltre 50 anni. Includere un parser nell'editor e fare in modo che l'editor salvi l'origine in forma di sexps (sì, proprio come il lisp). Quindi la sorgente viene letta, l'editor la scompone nel sintattico e tipografico (lo sai, spazi, tabulazioni, virgole), l'utente preferisce.

In questo modo, puoi digitare e leggere x = x || 10 e altri programmatori lo leggeranno come

if (0 == x) { x = 10;}

emacs ha tutti i pezzi per farlo facilmente.

Piuttosto che sminuire il codice, perché non migliorare la qualità della squadra? Formazione, coaching, istruzione e migliori pratiche di assunzione possono fare molto per garantire il miglioramento continuo.
Lo statismo, il marciume del codice, il rifiuto di migliorare e di innovare perché qualcuno non vuole lavorare sull'autostimolazione causa solo problemi lungo la linea, e prima o poi.

Naturalmente nel caso specifico che mostri, stai solo cercando di essere intelligente e deliberatamente di scrivere codice offuscato, che non è mai una buona idea. Il codice dovrebbe essere innanzitutto leggibile, facilmente comprensibile, non scritto per mostrare quanto sei intelligente nel creare qualcosa nelle minime affermazioni possibili (eccetto casi speciali, come quando più affermazioni porterebbero a prestazioni inaccettabilmente scarse, nel qual caso vengono chiamati commenti copiosi per).