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

Ad esempio, esiste uno snippet comune in JS per ottenere un valore predefinito:

function f(x) {
    x = x || 'default_value';
}

Questo tipo di frammento non è facilmente comprensibile da tutti i membri del mio team, essendo il loro livello JS basso.

Non dovrei usare questo trucco allora? Rende il codice meno leggibile dai peer, ma più leggibile del seguente secondo qualsiasi sviluppatore JS:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

Certo, se uso questo trucco e un collega lo vede, allora possono imparare qualcosa. Ma il caso è spesso che vedono questo come "cercare di essere intelligenti".

Quindi, dovrei abbassare il livello del mio codice se i miei compagni di squadra hanno un livello inferiore a me?

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

Pro per mantenere il tuo stile di programmazione:

• Cose come x = x || 10sono 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ù alto di codice è spesso più espressivo, sai cosa ottieni ed è più facile da leggere tra professionisti altamente qualificati.
• Ti godrai di più il tuo lavoro. Personalmente apprezzo la creazione di un bel codice. Penso che mi porti molte soddisfazioni nel mio lavoro.
• Generalmente crea uno stile più leggibile. Attaccare con gli idiomi della lingua può essere molto prezioso - spesso sono idiomi per una ragione.

Contro per mantenere il tuo 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 effettivamente leggere le cose che scrivi.
• I gestori del codice, spesso il codice JavaScript provengono da altre lingue. I 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 ad imparare di quanto si possa pensare e sono disposte ad adattare nuovi costrutti quando sono convinti che siano migliori.

Se pensano che tu sia "solo intelligente", prova a discutere il tuo punto. Sii disposto ad ammettere che a volte ti sbagli, e in ogni caso, cerca di mantenere gli stili coerenti in tutto il tuo ambiente di lavoro. Ciò contribuirà ad evitare l'ostilità.

La cosa più importante è rimanere coerenti.

Il codice di una squadra dovrebbe essere scritto come se fosse stato codificato da una persona. Devi assolutamente concordare le linee guida per la codifica. È necessario attenersi a tali linee guida. Se le linee guida per la codifica specificano che la lettura di parametri opzionali dovrebbe essere fatta nel modo "meno intelligente", allora è così.

Commenta bene

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

La realtà è che essere leggermente più prolisso con i commenti può essere utile con i membri del team meno qualificati, ma quelli con la più bassa abilità li ignorano, specialmente se ce ne sono troppi, quindi non esagerare.

Una questione di stile?

L'esempio che hai fornito è piuttosto semplice, ma anche piuttosto stilistico. Un commento su ogni variabile predefinita sarebbe piuttosto noioso da mantenere e leggere. Invece, scorciatoie o schemi di codice stilistici o ripetuti dovrebbero probabilmente essere stabiliti come standard. Se pensi che qualcosa come quella forma di default dei parametri debba essere compreso da tutti e usato ogni volta, scrivi queste idee e portale al comando del tuo team. È possibile che tutto ciò che serve per insegnare ai tuoi compagni di squadra sia un semplice incontro in cui discuterai degli standard che hai proposto.

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

Insegnare a un uomo a pescare ...

Insegnare ai tuoi compagni di squadra è probabilmente il modo migliore per aiutare tutte le persone coinvolte. Metti in chiaro che se qualcuno ha una domanda su un pezzo di codice con il tuo nome nel registro di commit o nei timestamp, dovrebbe sentirti libero di chiedertelo. Se la tua squadra ha recensioni di codice, questa è una grande opportunità per spiegare ai tuoi compagni qualsiasi codice ben commentato (ahem) probabilmente confuso . Se la tua squadra non ha recensioni di codice, perché no? Arrivare ad essa!

Devi stare attento, però. Potresti non essere sempre presente per insegnare alle persone e potresti persino dimenticare cosa stavi cercando di fare in una data sezione di codice.

Trucchi "intelligenti"

Tenere a mente le capacità dei tuoi compagni di squadra è sicuramente importante, ma scrivere codice gestibile spesso significa non usare scorciatoie arcane per problemi che potrebbero avere soluzioni più comuni. Questo è importante anche quando i tuoi compagni di squadra sono intelligenti. Non si desidera che il codice impieghi troppo tempo a comprendere o ad avere effetti collaterali sottili ma importanti che potrebbero essere persi. In generale, è meglio evitare trucchi "intelligenti" quando ci sono alternative adatte. Non si sa mai chi potrebbe dover mantenere il codice in linea - spesso le versioni precedenti di noi stessi non ricorderanno i dettagli o i motivi di questi trucchi.

Se scopri che devi implementare un trucco intelligente, almeno segui il prossimo consiglio ...

BACIO

In caso di dubbio, mantenerlo semplice . Il fatto che il codice sia semplice o meno non corrisponde necessariamente all'abilità del programmatore come si potrebbe pensare. In effetti, alcune delle soluzioni più brillanti a un problema sono le più semplici e alcune delle soluzioni più complicate finiscono su TheDailyWTF . Mantenere il codice semplice e conciso può rendere alcune delle decisioni più intelligenti ma forse controintuitive più facili da comprendere.

Sembra esserci un'enorme avversione per la creazione di una funzione in JS. Questa avversione fa sì che le persone provino ad essere intelligenti e usano trucchi ridicoli solo per mantenere le cose in una riga come sarebbe stata una chiamata di funzione. Naturalmente il nome della funzione in una chiamata funge anche da documentazione aggiuntiva. Non possiamo allegare un commento a un'espressione complicata perché in tal modo si annullerebbe il punto di farlo, quindi lo chiamiamo semplicemente "idioma" e improvvisamente è comprensibile.

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

x = x || 'default_value';

Il joe medio non capirà questo o ha memorizzato che è il linguaggio per valore predefinito. Entrambi sono dannosi, infatti quest'ultimo è ancora più dannoso. Non capirà le ipotesi e i casi limite qui. Non gli interesserà leggere le specifiche e capirle mai.

Quando guardo quel codice che vedere "se è nullo undefined, quindi impostare a questo valore predefinito. Anche se sarà anche implicitamente il trattamento +0, -0, NaN, false, e ""valori come non adatto. Dovrò ricordare che 3 mesi da oggi, quando che i bisogni per cambiare. Probabilmente lo dimenticherò ".

Il presupposto implicito è 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à di tenerli tutti in testa ogni volta che stai pensando a quale modifica avrà effetto. E questo è per "JS pro", il joe medio avrebbe scritto il bug anche se i requisiti dovessero accettare un valore errato per cominciare.

Il tuo nuovo frammento 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 client 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 come || "default"?

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

| 0oppure la versione cargo di culto ~~numutilizzata per la pavimentazione assume limiti interi positivi e con segno a 32 bit.

|| "default" presume che tutti i valori di falsità siano gli stessi del non passare affatto un argomento.

E così via.

Non dovresti ridurre le tue capacità di programmazione, ma potresti dover modificare il modo in cui scrivi il codice. L'obiettivo, quasi soprattutto, è chiarire il codice alle persone che devono leggerlo e mantenerlo.

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

In alcuni casi è necessario insegnare loro modi migliori per codificare, ma altre volte è necessario scendere a compromessi per motivi di chiarezza.

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

Linee guida generali

Quando lavori in una squadra, non sei il destinatario di un pezzo di codice. Il tuo pubblico è lo sviluppatore del tuo team. Non scrivere codice che non possono capire senza una buona ragione.

1. A meno che non vi sia un aspetto negativo specifico, tutto il codice dovrebbe essere scritto seguendo uno schema o una linea guida specifici che consentano una facile manutenzione da parte degli sviluppatori che lo manterranno. (Un avvertimento: seguire modelli sbagliati solo perché sono attualmente nella base di codice è una pratica terribile.)
2. Se trovi un buon motivo per usare un linguaggio specifico per la lingua che non è facilmente leggibile dal pubblico di destinazione, aggiungi un commento. Se ritieni di dover aggiungere un commento a tutte le altre righe, potresti voler riscrivere il codice per renderlo più leggibile dal tuo pubblico. Non trovo prezioso essere idiomatico per il gusto di essere idiomatico.

Esempio specifico

Abbiamo un gran numero di script perl nella nostra base di codice. Solitamente usiamo il perl solo per operazioni molto semplici e la stragrande maggioranza del codice è scritta da sviluppatori java, quindi ha uno stile 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 dei linguaggi perl più oscuri e nessuno dei nostri sviluppatori, incluso me stesso, è in grado di leggere questo codice perl senza sforzo prolungato. Lo malediciamo spesso per questo. :)

Se scrivi un buon codice ma pensi che i tuoi colleghi presenti o futuri potrebbero 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 qualcuno in una discussione di gruppo.

Non definirei il tuo esempio un trucco, ma solo idiomatico. Se dovessi usarlo dipende da IMHO non tanto dal livello attuale della tua squadra, ma se (almeno alcuni di) i tuoi compagni di squadra sono disposti a imparare alcuni nuovi modi di dire. Naturalmente, dovresti discutere di questo argomento con loro e non applicare questo stile su di loro. E non dovresti chiedere loro di imparare ogni giorno 5 nuove cose o "trucchi". Ma onestamente, se hai solo 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 una squadra diversa.

Leggendo questa domanda e le successive risposte e discussioni sembrano esserci due punti. Il primo: va bene usare funzionalità linguistiche avanzate? Il secondo: come posso farlo senza apparire come se stessi "mettendomi in mostra"?

Nel primo caso, ha senso utilizzare miglioramenti e funzionalità avanzate. Ad esempio: in C # non devi usare 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 sai effettivamente cosa sta facendo. All'inizio sembra strano.

Le persone si abituano ai modelli e in molti casi usano il modo stabilito di fare le cose solo per fare il lavoro. Sono colpevole di questo come il prossimo uomo. Tutti abbiamo delle scadenze. Per certi aspetti sei colpevole di introdurre nuove idee e nuovi modi di pensare! Questo arriva al secondo punto e probabilmente è qui che potresti incontrare più resistenza.

Alla persona che utilizza il sito Web non importa quale stile viene utilizzato, tutto ciò che gli interessa è funziona? È veloce? Quindi, se non ci sono vantaggi prestazionali sulla tua strada, non c'è modo giusto o sbagliato nell'esempio che dai. La tua strada rende il codice più leggibile o no? Potrebbe fare una volta che i tuoi colleghi sono abituati.

Quindi, come si introducono questi cambiamenti? Prova a discutere con i tuoi colleghi in questo modo: sapevi che questa funzione può essere scritta in questo modo? Revisioni del codice e programmazione di coppie possono essere dei bei momenti per consentire una "impollinazione incrociata" di idee. È difficile per me prescrivere cosa fare perché non conosco l'ambiente in cui stai lavorando. Trovo che alcuni programmatori possano essere molto difensivi e resistenti ai cambiamenti. Ancora una volta sono stato colpevole di questo. Il modo migliore di lavorare con questo tipo di programmatori è di dedicare un po 'di tempo all'apprendimento di ciò che li spinge, 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, cerca di incoraggiarli.

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

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

ciò che è importante, tuttavia, è la capacità del tuo codice di vivere oltre i pochi minuti necessari per scriverlo. Certo, è semplice e veloce e puoi eliminarlo e andare avanti, ma se devi tornare ad esso anni dopo, è allora che potresti pensare "quale muppet ha scritto questo", e realizzare che sei stato tu! (L'ho fatto, certo che anche la maggior parte delle persone ha .. Incolpo le scadenze eccessivamente aggressive, onesto).

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

Ad ogni modo, se potessi leggere la storia di Mel , ti renderesti conto che i trucchi non sono la cosa migliore da inserire in qualsiasi codice, anche se Mel era un vero programmatore del primo ordine. Questo pone in risalto qualsiasi argomento in cui qualcuno dice 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 hack intelligenti, per parafrasare "il debug è due volte più difficile della programmazione. Se scrivi codice il più intelligente possibile, allora per definizione non sei in grado di eseguirne il debug".

Ciò non significa che dovresti evitare il codice solo perché gli altri non lo capiscono - dovresti scrivere il codice nel modo più chiaro e coerente possibile. Ma i tuoi criteri per chiarire dovrebbero essere "capirò questo in prima lettura tra un anno", non "nessuno può capirlo".

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

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

In caso contrario, probabilmente prenderei in considerazione quale tipo di standard proposto ha senso e inizierò a metterlo in pratica dopo averlo chiarito con la direzione e alcuni membri del team. L'idea qui è di assicurarsi che il management sia d'accordo con questa idea e che non sto solo andando a fare le mie cose e quindi costringendo tutti gli altri a prenderle.

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

Il problema è che vuoi una buona leggibilità della fonte, ma la leggibilità è agli occhi di chi guarda.

Suggerirei che abbiamo bisogno di strumenti migliori per risolvere questo problema. Niente di complesso, intendiamoci, abbiamo la tecnologia per farlo da oltre 50 anni. Includi un parser nell'editor e chiedi all'editor di salvare la fonte in forma di sexps (sì, proprio come lisp). Quindi la fonte viene letta, l'editor la analizza in modo sintattico e tipografico (sai, spazi, tabulazioni, virgole), forma che l'utente preferisce.

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

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

emacs ha tutti i pezzi per farlo facilmente.

Invece di smorzare il codice, perché non migliorare la qualità della squadra? La formazione, il coaching, l'istruzione e le migliori pratiche di assunzione possono fare molto per garantire un miglioramento continuo.
Statismo, marciume del codice, rifiuto di migliorare e innovare perché qualcuno non vuole lavorare sull'auto-miglioramento provoca solo problemi lungo la linea, e prima piuttosto che dopo.

Naturalmente nel caso specifico che mostri, stai solo cercando di essere intelligente e scrivere deliberatamente codice offuscato, che non è mai una buona idea. Il codice dovrebbe prima di tutto essere leggibile, facilmente comprensibile, non scritto per mostrare quanto sei intelligente nel creare qualcosa nel minor numero possibile di affermazioni (casi speciali esclusi, come nel caso in cui più dichiarazioni porterebbero a prestazioni inaccettabilmente scadenti, nel qual caso vengono chiamati copiosi commenti per).