Va bene usare la meta-programmazione anche se non tutti i miei colleghi lo capiscono?

Uso molte meta-programmazioni per evitare compiti ripetitivi e costruire astrazioni più sicure da usare.

Di recente mi sono trasferito in un nuovo lavoro dove lavoro in un gruppo più ampio e questo preoccupa alcuni dei miei colleghi, perché non lo comprendono.

Cerco sempre di sfruttare tutto il potenziale della lingua, ma alcuni (non tutti) dei miei colleghi lo percepiscono come un rischio (alcuni apprezzano l'approccio).

Sono d'accordo che è un problema scrivere codice che nessun altro membro del team può comprendere. D'altra parte siamo tutti sviluppatori C ++ professionisti e penso che dovremmo aspirare a uno standard più elevato rispetto alla scrittura in classe C.

La mia domanda è: chi ha ragione, cosa devo fare?

Chiarimento: cercare di sfruttare tutto il potenziale della lingua, non significa che lancio TMP ad ogni problema. C ++ è una cassetta degli attrezzi e per me la competenza C ++ riguarda la possibilità di utilizzare tutti gli strumenti dalla scatola e di scegliere quello giusto per un determinato lavoro.

La metaprogrammazione è OK. Quello che stai cercando di fare non è OK.

Uso sempre la metaprogrammazione nel mio lavoro. È uno strumento potente che può essere utilizzato per fare molte cose in un modo più leggibile e mantenibile. È anche uno dei più difficili da comprendere stili di programmazione là fuori, quindi ha davvero bisogno di guadagnarsi da vivere. Mi piace quando riesco a ridurre 1000 righe di codice a 50, ma provo a limitarlo in quanto tale.

Il problema non è la metaprogrammazione, ma questo:

D'altra parte siamo tutti sviluppatori C ++ professionisti e penso che dovremmo aspirare a uno standard più elevato rispetto alla scrittura in classe C.

Questo è dove ti trovi nei guai. Hai un'opinione. Va bene avere un'opinione che la metaprogrammazione è buona. Va bene avere un'opinione secondo cui tutti dovremmo aspirare a essere sviluppatori C ++ migliori.

Non va bene obbligare sia i tuoi colleghi che i futuri assunti che dovranno mantenere il codice che hai scritto per essere d'accordo con la tua opinione. Questo è il lavoro del tuo capo. Il tuo capo è colui che dovrebbe preoccuparsi di assicurarsi che il tuo codice sia mantenibile a lungo termine. Speriamo che abbiano molta più esperienza di affari, perché credimi quando dico che è una decisione commerciale, non una decisione ideologica.

Va bene voler metaprogramma. Va bene voler insegnare agli altri a metaprogramma. Ma capisci che va bene anche per gli altri scegliere di non imparare a metaprogrammare, e ciò sarà vero fino a quando non sarai in una posizione di potere. (e, come un segreto del settore: quando finalmente sei uno sviluppatore principale, in una posizione di potere, non sei affatto in una posizione di potere. C'è qualcuno che controlla i perseguimenti che è al potere).

Se vuoi incoraggiarli a stare bene con la metaprogrammazione, inizia in piccolo . Inizia con un singolo enable_ifche semplifichi la lettura dell'API. Quindi commenta la luce del giorno . Quindi magari trova un caso in cui una metafunzione modello trasforma 10 grandi classi ripetitive in 1 classe con 10 piccoli aiutanti. Commenta diamine. Ottieni feedback. Trova cosa ne pensano le persone. Va bene se ti dicono di non farlo. Trova una nicchia in cui la metaprogrammazione guadagni il suo mantenimento così a fondo che tutti i tuoi colleghi (a malincuore) concordano sul fatto che fosse lo strumento giusto per il lavoro.

Come racconto, ho scritto una bellissima biblioteca una volta, usando metaprogrammi approfonditi. Ha fatto esattamente ciò di cui avevamo bisogno in quel momento, quando nessun altro approccio poteva avvicinarsi da remoto. In realtà ha cambiato la direzione dell'applicazione in cui stavo scrivendo. Ma era metaprogrammazione. Solo una o due altre persone in tutta la mia compagnia potevano leggerlo.

Più tardi, il mio collega ha preso un'altra pugnalata al problema. Invece di sfruttare la metaprogrammazione per fare esattamente ciò che era necessario, ha lavorato con la leadership per allentare i vincoli che erano stati posti sul problema in modo tale che la metaprogrammazione non fosse necessaria. Forse più precisamente, la metaprogrammazione era meno necessaria. È stato in grado di limitarlo a ciò che la metaprogrammazione fa meglio.

La libreria risultante è ora in grado di essere utilizzata in un mercato notevolmente ampio, e questo è certamente in piccola parte a causa del fatto che il nuovo codice può essere gestito da una gamma molto più ampia di sviluppatori. Sono orgoglioso di spianare la strada alla metaprogrammazione, ma è il codice del mio collega che raggiungerà il vasto pubblico, e ci sono buone ragioni per questo.

Innanzitutto, questo è il problema del team e devi risolverlo con il team. Se si dispone di backup dal team per la programmazione utilizzando determinati elementi e costrutti, farlo; in caso contrario, discuterne con loro e se non riesci a convincerli e ad affermare con forza perché "il tuo approccio" è chiaramente migliore, starai meglio a non usarlo.

Si noti che l'utilizzo della meta-programmazione di modelli in C ++ è sempre un compromesso: certo, a volte può aiutare a progettare alcune parti di un'applicazione più ASCIUTTA, ed è sicuramente utile per creare librerie altamente efficienti e riutilizzabili.

D'altro canto, questi vantaggi hanno un certo costo: il codice diventa più astratto, spesso molto più difficile da leggere, molto più difficile da eseguire il debug e molto più difficile da mantenere. Ciò rende spesso discutibile l'utilità della meta-programmazione nella programmazione dell'applicazione. Quindi, supponendo che non creerai il prossimo STL, ogni volta che sei tentato di utilizzare la meta-programmazione, chiediti se questi svantaggi valgono davvero la pena. E se non si è sicuri, discuterne con il proprio peer reviewer durante la revisione del codice.

La mia opinione generale: se hai una scelta, come spesso accade, tra le seguenti tre opzioni:

• Digitare ripetutamente a mano molte strutture di codice non banali;
• Usa la metaprogrammazione del modello C ++ per automatizzare la generazione del codice;
• Utilizzare alcuni altri meccanismi di generazione del codice, ad esempio macro o altri linguaggi di programmazione per generare file sorgente C ++

quindi la metaprogrammazione dei template, eseguita correttamente, sarà probabilmente la più leggibile e gestibile delle tre opzioni. Questo è l'argomento che vorrei fare alla squadra, se fossi nella tua posizione. Gli esempi con il codice attuale potrebbero aiutare a convincerli.

Quando si utilizza la Meta-Programmazione dei modelli ( TMP ) per evitare la ripetizione, è necessario utilizzarlo per costruire astrazioni ben documentate e accuratamente testate che localizzano la complessità all'interno del codice TMP, facilitando la scrittura del codice client corretto. Questo è il design della libreria standard C ++.

Non penso che possiamo giudicare chi ha ragione o torto senza vedere un esempio del tipo di codice che stai cercando di scrivere.

Gli sviluppatori di software dovrebbero aspirare a scrivere codice che funzioni, che funzioni ovviamente, che possa essere testato, che possa essere rivisto, che possa essere sottoposto a debug e che possa essere adattato quando sono necessarie modifiche. Se scrivere "C con le classi" lo raggiunge, allora va bene.

E questi sono gli standard su cui dovresti misurare il tuo codice. In particolare: funziona ovviamente, può essere testato, può essere rivisto, può essere sottoposto a debug e può essere adattato quando necessario?

Un argomento dalla compassione:

Il tuo lavoro offre tempo libero per l'apprendimento o, in alternativa, puoi convincere i tuoi capi ad assegnare alcune ore all'apprendimento di queste funzionalità linguistiche?

In caso contrario, l'utilizzo di questi sta essenzialmente dando loro un lavoro extra non retribuito. Potresti pensare che un programmatore C ++ dovrebbe conoscere l'intero linguaggio, o qualcosa del genere, ma un punto accademico non allevia l'onere che ti importerai. I tuoi colleghi hanno figli, genitori malati, coniugi malati - o diavolo, solo una ragionevole vita sociale che non comporta l'apprendimento del C ++. L'avversario più vocale della tua proposta potrebbe essere pigro, oppure potrebbe andare a fondo in un momento difficile e non ha bisogno di merda extra nella sua vita in questo momento.

Il codice dovrebbe essere scritto in primo luogo per essere letto dagli umani e solo per inciso affinché il compilatore possa analizzare.

Ora la cosa da ricordare sul TMP non banale è che stai limitando il numero di persone che possono leggere quel codice, può essere un compromesso valido, ma direi che è molto più di un ragionevole compromesso nelle biblioteche e in cui hai un piccolo team specializzato di esperti quindi è in un'applicazione più grande.

Quando tiri fuori tutti i trucchi del libro che imponi a tutti gli altri in quanto ora devono capire la lingua, compresi tutti i casi legali che hai sfruttato, imponi anche un costo per l'assunzione in quanto hai alzato il tiro lavorare sull'applicazione in modo utile, ora forse ne vale la pena, ma guarda i costi ....

Per me, un po 'più di battitura, forse anche un po' di duplicazione del codice, ma che posso mettere di fronte al signor "C con classi più STL" quando ha bisogno di modifiche è molto più utile di qualcosa di incredibilmente elegante TMP che solo io posso mantenere (E sarà quindi sempre per sempre). Ricorda anche che il tipo C con classi potrebbe essere l'esperto in materia, e che l'esperienza di solito è molto più preziosa dell'essere un avvocato linguistico.

Dimentico chi lo ha detto, ma "Tutti sanno che il debug è più difficile che scriverlo in primo luogo, quindi se lo programmate nel modo più intelligente possibile, come lo debug mai?".

Anche se riesco a scrivere davvero sul moderno C ++ di solito preferisco non farlo, significa che devo fare meno della programmazione di manutenzione.

No non dovresti. Siete impiegati per produrre codice che soddisfi una specifica. Questo codice deve essere mantenibile, non un viaggio nell'ego. Domani potresti essere investito da un autobus, quindi qualcuno deve essere in grado di ritirare il codice e portare avanti l'attività in corso. Tuttavia, è positivo cercare di convincere i tuoi datori di lavoro a incorporare nuove tecniche nei loro standard di programmazione.

L'unico modo per rispondere a questa domanda nel contesto è quello di esaminare i problemi specifici e il modo specifico in cui li hai risolti con la meta-programmazione. A meno che non pubblichi un codice qui, non possiamo sapere se ti sei lasciato andare a una complicazione inutile che è divertente per te da solo "risolvere" un problema inesistente; o se hai impiegato tutta la potenza della lingua per scrivere una soluzione semplice ed elegante non disponibile con altri mezzi.

Se è quest'ultimo, ti incoraggio a continuare a farlo insieme al tuo team.Ogni buon team deve fare revisioni significative del codice che discutono non solo di problemi di stile, ma anche se la soluzione del programmatore utilizza l'approccio migliore, utilizza le funzionalità linguistiche appropriate, è gestibile e testabile ecc. La tua soluzione di meta-programmazione dovrebbe riempire una di queste sessioni di revisione, probabilmente un tutto il pomeriggio. I programmatori che rifiutano il tuo approccio dovrebbero presentare alternative (come la generazione di codice con perl, duplicazione del codice ecc.) E mostrare come si comporta rispetto ai criteri citati, rispetto alla tua soluzione. Il tuo lavoro, come loro "avversario" amichevole nell'argomento, è dimostrare che è un modo per fare il lavoro velocemente, che la manutenzione è facile, i test sono facili e il codice è effettivamente leggibile una volta superato l'ostacolo di analizzare la grammatica divertente.

La maggior parte dei programmatori è pigra e gode di soluzioni eleganti e piccole. Se il tuo è uno, è probabile che tu riesca a convincerli, specialmente se le alternative dimostrate non sono all'altezza.

Non esiste un'unica risposta corretta a questa domanda.

Perché la prima cosa che dovresti chiederti è: in quale situazione ti trovi nel tuo lavoro? Alcune persone sono effettivamente impiegate come scimmie codici per codificare le specifiche, altre sono impiegate come giocatori di squadra, altre sono impiegate come knowledge worker o esperti.

L'unica linea di fondo costante è che devi guardarlo dal punto di vista del tuo datore di lavoro, dal momento che essenzialmente questo significa essere un dipendente. A volte è nel migliore interesse del tuo datore di lavoro spingere davvero i tuoi colleghi a diventare migliori e padroneggiare tecniche avanzate. Tuttavia, in una situazione diversa, potresti semplicemente creare molti problemi e responsabilità e mettere in pericolo il successo dei progetti in cui sei coinvolto.

La domanda non è davvero se la meta-programmazione sia OK o meno, ma piuttosto se sia OK essere migliore degli altri nel team, quindi ecco alcuni punti controversi su come la vedo ...

Di recente mi sono trasferito in un nuovo lavoro dove lavoro in un team più ampio e questa [meta-programmazione] preoccupa alcuni dei miei colleghi, perché non lo comprendono.

Sono preoccupati che tu sia migliore di loro. Quello è buono. Sarai il nuovo esperto. Hai appena distrutto il loro mondo status quo.

Cerco sempre di sfruttare tutto il potenziale della lingua, ma alcuni (non tutti) dei miei colleghi lo percepiscono come un rischio (alcuni apprezzano l'approccio).

Certo, a nessuno piace essere meno abile di chiunque altro, quindi stanno cercando di impedirti di usare tecniche troppo complesse per loro. O non possono comprenderlo o non lo faranno, perché ora si sentono sicuri.

Sono d'accordo che è un problema scrivere codice che nessun altro membro del team può comprendere.

Io non. Penso che stia mostrando la tua esperienza.

La mia domanda è: chi ha ragione, cosa devo fare?

Dovresti usare tutte le tue abilità per scrivere il miglior codice che puoi scrivere e non guardare dietro a chi non lo capisce. Altrimenti rimarrai bloccato al loro livello e sarai solo un normale programmatore. È una buona cosa essere migliori degli altri, ed è una buona cosa cercare di essere migliori di loro. Non otterrai mai nuove esperienze se non provi a usare qualcosa di nuovo o fare cose in modo diverso.

So che sarò sottoposto a downgrade, ma è così. Non è un crimine essere migliore degli altri nella squadra, e non è un crimine usare le tue abilità. È solo che tutti hanno paura di ammetterlo ... perché sono dalla parte non qualificata e odiano il fatto che il nuovo ragazzo improvvisamente possa fare qualcosa che non può. Se fossero intelligenti, ti chiederebbero aiuto e consigli e non criticano il tuo codice per essere incomprensibile.

MODIFICARE

Sembra esserci molta confusione su questa domanda. Come mostrano i commenti, molte persone pensano che si tratti della leggibilità del codice generale. No non lo è. Si tratta di vietare o evitare determinate caratteristiche / costrutti del linguaggio perché alcuni membri del team non li comprendono.

La mia risposta è no . Non dovrebbero essere vietati. Se vuoi vietare qualcosa come lo faresti? Dovresti preparare una sorta di questionario per scoprire cosa possono e non possono fare i membri del tuo team - o piuttosto non vogliono imparare come penso che tutte le funzionalità di languague siano utili da qualche parte, quindi conoscerle ed essere in grado di usarle è sempre buono e più conosci il codice migliore che puoi scrivere. Avresti anche bisogno di una scala per definire quali funzioni sono principianti, intermedie o avanzate.

Per dimostrare quanto siano sciocche tali restrizioni, facciamo un esempio molto semplice: verrai assunto come ingegnere del software, ma il tuo futuro capo ti dirà che non ti sarà permesso di usare i do/whileloop perché ci sono un paio di persone su la squadra che non li ha mai usati prima e che non lo faranno perché usano sempre i forloop per tutto, quindi trovano do/whileloop confusi.

Ora pensi che sia stupido e folle, vero? Ma così è vietare altre funzionalità. Alcuni possono usarli e altri non vogliono impararli.

Perché dovresti produrre codice peggiore se sai che esiste qualcosa che ti consente di fare lo stesso con molto meno sforzo e che tuttavia risulta in un codice robusto molto più leggibile?

E non importa se usi solo funzionalità di linguaggio di base o avanzate, puoi usare uno di essi per produrre un codice altrettanto incomprensibile e non realizzabile, quindi questo è un argomento completamente diverso.