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

Metaprogramming è OK. Quello che stai cercando di fare non è OK.

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

Il problema non è metaprogrammazione, ma questo:

On the other hand we are all professional C++ developers and I think we should aspire to a higher standard than writing C with classes.

Questo è dove ti metti nei guai. Hai un'opinione. Va bene avere un'opinione che la metaprogrammazione sia buona. Va bene avere un'opinione che tutti dovremmo ambire a diventare migliori sviluppatori C ++.

Non è giusto obbligare i futuri assistenti a e a dover mantenere il codice che hai scritto per essere d'accordo con la tua opinione. Questo è il lavoro del tuo capo. Il tuo capo è quello che dovrebbe preoccuparsi di assicurarsi che il tuo codice sia mantenibile a lungo termine. Loro (si spera) hanno molta più esperienza d'affari, perché credimi quando dico che è una decisione commerciale, non una decisione ideologica.

Va bene volere metaprogram. Va bene voler insegnare agli altri a metaprogram. Ma capisci che va anche bene che gli altri scelgano di non imparare a metaprogrammi, e questo sarà vero finché non sarai in una posizione di potere. (e, come segreto del settore: quando alla fine sei uno sviluppatore principale, in una posizione di potere, non sei affatto in una posizione di potere. C'è qualcuno che controlla gli inseguimenti che è al potere).

Se vuoi incoraggiarli per essere a posto con metaprogramming, inizia in piccolo . Inizia con un singolo enable_if che rende l'API più facile da leggere. Quindi commenta le luci del giorno fuori di esso. Poi, forse, trovi un caso in cui una metafunzione del modello trasforma 10 grandi classi ripetitive in 1 classe con 10 piccoli aiutanti. Commenta il diavolo. Ottieni un feedback. Trova cosa ne pensa la gente. Stai bene se ti dicono di non farlo. Trova una nicchia in cui la metaprogrammazione guadagna la sua attenzione in modo così accurato che i tuoi colleghi tutti (a malincuore) concordano che è stato lo strumento giusto per il lavoro.

Come racconto, ho scritto una bella biblioteca una volta, usando una metaprogrammazione estesa. Ha esattamente ciò di cui avevamo bisogno al momento, quando nessun altro approccio poteva chiudersi da remoto. In realtà ha cambiato la direzione dell'applicazione in cui stavo scrivendo. Ma era metaprogrammazione. Solo una o due persone in tutta la mia azienda potrebbero leggerlo.

Più tardi, il mio collega ha preso un'altra pugnalata al problema. Invece di sfruttare la metaprogrammazione per precisamente fare ciò che era necessario, ha lavorato con la leadership per allentare i vincoli che erano stati posti sul problema in modo tale che non fosse necessaria la metaprogrammazione. Forse più accuratamente, 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 ampio mercato notevolmente , e questo è certamente in gran parte dovuto al fatto che il nuovo codice può essere mantenuto da una gamma molto più ampia di sviluppatori. Sono orgoglioso di aprire la strada con metaprogramming, ma è il codice del mio collega che sta per raggiungere il pubblico più ampio, e ci sono buone ragioni per questo.

Innanzi tutto, questo è il problema del team e devi risolverlo con il team. Se hai un backup dal team per la programmazione usando determinati elementi e costrutti, fallo; in caso contrario, discutine con loro e se non riesci a convincerli e fai un buon motivo per cui "il tuo approccio" è chiaramente migliore, starai meglio a non usarlo.

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

D'altra parte, questi benefici hanno un costo certo: 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 l'utilità della meta-programmazione nella programmazione delle applicazioni spesso discutibile. Quindi, supponendo che tu non abbia intenzione di creare il prossimo STL, ogni volta che sei tentato di usare la meta-programmazione, chiediti se valga davvero la pena di quegli inconvenienti. E se non sei sicuro, discuti di questo con il tuo revisore peer 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;
• Utilizza la metaprogrammazione del modello C ++ per automatizzare la generazione del codice;
• Utilizza un altro meccanismo di generazione del codice, come macro o un altro linguaggio di programmazione per generare file sorgente C ++

quindi la metaprogrammazione del modello, eseguita correttamente, sarà probabilmente la più leggibile e mantenibile delle tre opzioni. Questo è l'argomento che farei alla squadra, se fossi nella tua posizione. Gli esempi con il codice effettivo li aiuteranno a convincerli.

Quando usi Meta-Programmazione Template ( TMP ) per evitare ripetizioni, dovresti usarlo per costruire astrazioni ben documentate e testate che localizzino la complessità all'interno del codice TMP, rendendo più facile scrivi il codice cliente 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 revisionato, che possa essere sottoposto a debug e che possa essere adattato quando sono necessari cambiamenti. Se scrivere "C con le classi" raggiunge questo, allora va bene.

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

Un argomento dalla compassione:

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

In caso contrario, l'utilizzo di questi è essenzialmente un lavoro extra non retribuito. Potresti pensare che un programmatore C ++ dovrebbe conoscere l'intera lingua, o qualcosa del genere, ma un punto accademico non allevia l'onere che ti verrà imposto. I tuoi colleghi hanno figli, genitori malati, sposi malati - o inferno, solo una vita sociale ragionevole che non implichi l'apprendimento del C ++. L'oppositore più vocale della tua proposta potrebbe essere pigro - o potrebbe essere un duro periodo e non ha bisogno di merda in più nella loro vita in questo momento.

Il codice dovrebbe essere scritto in primo luogo affinché gli esseri umani possano leggere, e solo incidentalmente per essere analizzato dal compilatore.

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

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

Per me, un po 'più di digitazione, forse anche una duplicazione del codice, ma che posso mettere davanti a Mr "C con le classi più STL" quando ha bisogno di modifiche è molto più utile di qualche cosa TMP incredibilmente elegante che solo Posso mantenere (e sarà quindi per sempre mantenere). Ricorda anche che il C con il ragazzo delle classi potrebbe essere l'esperto in materia, e che l'esperienza è di solito molto più preziosa di un avvocato linguistico.

Ho dimenticato chi l'ha detto ma "Tutti sanno che il debugging è più difficile da scrivere in primo luogo, quindi se lo programmate nel modo più intelligente possibile, come fareste mai a debuggarlo?"

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

No, non dovresti. Sei impiegato per produrre codice che soddisfi una specifica. Questo codice deve essere mantenibile non un viaggio dell'ego. Potresti essere investito da un autobus domani, quindi qualcuno deve essere in grado di prendere il tuo codice e portare a termine il compito. Tuttavia, è positivo cercare di convincere i vostri datori di lavoro a incorporare nuove tecniche nei loro standard di programmazione.

L'unico modo per rispondere a questa domanda nel contesto è guardare i problemi specifici e il modo specifico con cui li hai risolti con la meta-programmazione. A meno che tu non invii il codice qui, non possiamo sapere se ti sei comportato in una complicazione inutile che è divertente solo per te "risolvere" un problema inesistente; o se hai utilizzato tutta la potenza del linguaggio 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 buona squadra deve fare revisioni di codice significative che discutano non solo i problemi di stile ma anche se la soluzione del programmatore utilizza l'approccio migliore, utilizza le funzionalità linguistiche appropriate, è gestibile e controllabile ecc. La tua soluzione di meta-programmazione dovrebbe occupare una di queste sessioni di revisione, probabilmente per un intero pomeriggio. I programmatori che rifiutano il tuo approccio dovrebbero disporre alternative (come la generazione del codice con perl, la duplicazione del codice ecc.) E mostrare come si comporta rispetto ai criteri menzionati, rispetto alla tua soluzione. Il tuo lavoro, come il loro amichevole "avversario" nell'argomento, è quello di mostrare che è un modo per portare a termine il lavoro velocemente, che la manutenzione è facile, il test è semplice e il codice è leggibile una volta superato l'ostacolo di analizzando la grammatica divertente. (Se sei strategico, puoi mostrarlo in anticipo ad un amico in ufficio e convincerlo che è davvero bello, che ti aiuterà nella discussione perché non sarai solo.)

La maggior parte dei programmatori è pigra e si avvale di soluzioni eleganti e di piccole dimensioni. Se il tuo è uno, è probabile che tu possa convincerli, specialmente se le alternative dimostrate sono insufficienti.

Non c'è una sola risposta corretta a questa domanda.

Perché la prima cosa che dovresti chiederti è: in che situazione tieni dal tuo lavoro? Alcune persone sono effettivamente impiegate come code-code per la codifica delle 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, infatti, spingere i tuoi colleghi a diventare migliori e padroneggiare le tecniche avanzate. Tuttavia, in una situazione diversa, potresti creare molti problemi e responsabilità e compromettere il successo dei progetti in cui sei coinvolto.

La questione non è in realtà se la metaprogrammazione sia OK o meno, ma piuttosto se sia OK essere migliore degli altri nel team quindi ecco alcuni punti controversi su come la vedo ...

I recently moved to a new job where I am working in a larger team and this [meta-programming] worries some of my colleagues, because they do not comprehend it.

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

I always try to leverage the full potential of the language, but some (not all) of my colleagues perceive that as a risk (some welcome the approach).

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

I agree it is a problem to write code that nobody else on the team can comprehend.

Non lo so. Penso che stia mostrando la tua esperienza.

My question is, who is right, what should I do?

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

So che verrò downvoted, ma è così che sembra. Non è un crimine essere migliori degli altri nella squadra, e non è un crimine usare le tue abilità. È solo che tutti hanno paura di ammetterlo ... perché sono dal lato non esperto e odiano il fatto che il nuovo tipo possa improvvisamente fare qualcosa che non possono. Se fossero intelligenti, ti chiederebbero aiuto e consiglio e non criticheranno il tuo codice per essere incomprensibili.

Modifica

Sembra che ci sia molta confusione su questa domanda. Come mostrano i commenti, molte persone pensano che riguardi la leggibilità generale del codice. No non lo è. Riguarda se certe caratteristiche / costrutti linguistici dovrebbero essere vietati o evitati perché alcuni membri del team non li capiscono.

La mia risposta è no . Non dovrebbero essere vietati. Se vuoi proibire qualcosa, come faresti? Dovresti preparare una sorta di questionario per scoprire cosa possono o non possono fare i membri del tuo team, o piuttosto non vuoi imparare, perché penso che tutte le caratteristiche languide siano utili da qualche parte, quindi conoscerle e poterle usare è 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: sarai assunto come ingegnere del software ma il tuo futuro capo ti dirà che non ti sarà permesso usare do/while loops perché lì ci sono un paio di persone nel team che non li hanno mai usati prima e inoltre non lo faranno perché hanno sempre utilizzato for loops per tutto, quindi trovano do/while loops confusion.

Ora pensi che sia stupido e pazzo, vero? Ma così è vietando altre funzionalità. Alcune persone possono usarle e altre non vogliono impararle.

Perché dovresti produrre codice peggiore se sai che c'è qualcosa che ti permette di fare lo stesso con molto meno sforzo e tuttavia ottenere un codice molto più leggibile?

E non importa se usi solo le funzioni linguistiche di base o quelle avanzate, puoi usare uno dei due per produrre un codice ugualmente incomprensibile e non gestibile, quindi questo è un argomento completamente diverso.