In parole povere, sono piuttosto nuovo per l'azienda, dovrei piuttosto scrivere tecniche avanzate con elementi come template s, std techniques..etc per fare una buona impressione e avere fiducia dei miei colleghi / essere impressionato dal mio lavoro o dovrei essere più interessato a scrivere più codice standard solido / basato per ogni problema corrente da risolvere?
Assolutamente no.
Se ti sei unito al mio team e hai speso tutto il tuo tempo utilizzando tecniche più avanzate di quelle necessarie per l'attività in corso, sarei certamente meno impressionato. Faresti più difficile leggere, capire e mantenere il codice ... non solo per i tuoi compagni di squadra, ma anche per te stesso. E per quale motivo? Mettersi in mostra? Non fantastico.
Anche se per lo meno saresti facile per me trovare contenuti per la tua prima recensione sul rendimento!
Il modo per impressionarmi è usare lo strumento giusto per il lavoro. Se si verifica un problema che è meglio risolvere con una "tecnica avanzata", e si è in grado di fornire una tale soluzione in modo tale che la stabilità del codice e la manutenibilità non siano compromesse, allora sarei impressionato.
Per essere chiari, tuttavia, l'uso di modelli e strutture di libreria standard non è affatto "avanzato". Richiedo a chiunque si unisca al mio team C ++ per avere familiarità con questi come ovvio.
Come disclaimer, sto interpretando "avanzato" qui come non come un modello di classe base per una struttura dati o un modello di funzione per un algoritmo generico che immette gli iteratori. Questo non sembra quasi un territorio da showboating a meno che non si tratti di un gruppo di persone che non sanno come usare il C ++. Sto assumendo cose come, ad esempio, modelli di classi di policy che consentono infinite combinazioni nelle policy quando solo una combinazione è effettivamente utile: soluzioni esotiche ben oltre la norma ... forse anche più avanzate delle policy class: cose senza un nome che le persone non ho mai visto prima, trucchi che usano il linguaggio che non è mai stato ancora applicato nel codice di produzione.
Il segno distintivo di uno sviluppatore esperto non è colui che applica metatemplates ricorsivi per creare qualcosa che assomiglia a un DSEL di base per risolvere un compito di routine. Questa è la masturbazione programmata: è meglio salvare i progetti di scarto sul lato per capire meglio come funziona la lingua o quando si scrive un libro su come esplorare i confini più profondi di un linguaggio di programmazione.
Non viene nemmeno da un meccanismo elaborato per sostituire 3 linee di semplice testo in 50 file sorgente con 1 riga di codice. Se non altro, l'esperienza ti entusiasmerà inizialmente con tali soluzioni solo nel corso degli anni, tornando alla soluzione semplice quando realizzi che la manutenibilità è stata effettivamente degradata invece di essere migliorata diventando così fantasiosa.
Una delle principali metriche nascoste di manutenzione che non è stata discussa così spesso è "familiarità". Il codice esotico è un codice non familiare, e probabilmente non è familiare neanche a te stesso dopo che è passato del tempo a rivederlo. Questo è il motivo per cui il codice idiomatico è così prezioso - migliora la manutenibilità migliorando la familiarità. Siamo saturi di codice idiomatico e quindi tende a rimanere sempre familiare. "Esotico" è l'esatto contrario, ed è solitamente associato al desiderio di rimodellare il linguaggio di programmazione usato piuttosto che abbracciare i suoi punti di forza e accettare le sue debolezze.
I modelli possono essere modi meravigliosi e semplici per ottenere astrazioni in fase di compilazione senza penalità di runtime, e talvolta sono persino usati correttamente in un contesto ricorsivo o simile a DSEL per qualcosa che la lingua sarebbe altrimenti incredibilmente inetta da gestire. Suppongo che, quando dici "avanzato", usi i modelli in un modo molto insolito. Ma abbracciati troppo in fretta, possono rapidamente finire per neutralizzare gli obiettivi che erano destinati a servire: possono trasformarsi nella macro elaborata.
Se vuoi stupire le persone, usa la soluzione più semplice, più idiomatica e semplice con cui scappare: meno esotico e meglio è. A volte ci sono sezioni in una base di codice che hanno una domanda insolitamente complessa in cui dobbiamo rompere con la norma. Tuttavia, la chiave qui è di fare questo con parsimonia, a malincuore, per non applicare soluzioni complesse per compiti semplici. La soluzione geniale consiste nel trovare una soluzione semplice e simmetrica a un compito apparentemente molto complesso, spesso molto difficile, ma non è così difficile evitare l'applicazione di soluzioni complesse per compiti semplici.
Mentre questo è C anziché C ++, controlla il kernel di Linux. È scritto nel modo più incredibilmente semplice data la combinazione di complessità e natura critica di ciò che sta facendo, eppure è organizzato logicamente e meglio di alcune basi di codice di base che stanno facendo cose molto più semplici. Prendi questo tipo di fonti di semplicità e semplicità come ispirazione e come mezzo per impressionare i tuoi colleghi.
È bello comprendere tecniche davvero avanzate come la complessità di SFINAE, ma salvare tale conoscenza avanzata per i problemi più avanzati in cui le soluzioni avanzate finiscono per essere le soluzioni più eleganti e semplici.
A volte l'ambiente è conservatore o semplicemente non è aperto a fare le cose in un altro modo rispetto a ciò a cui le persone sono abituate e quindi a proprio agio. Poi incontrerai l'opposizione ogni volta che uscirai dal percorso che i tuoi colleghi conoscono e ti tireranno addosso ragionamenti falsi per non usare una particolare tecnica piuttosto che cercare di recuperare e imparare qualcosa di nuovo. Non esiste un modo standard per affrontarlo. A volte è meglio farlo e lasciare che i risultati parlino da soli, altre volte è meglio non mescolare troppo il piatto e lasciare che tutti si abituino al nuovo ragazzo per guadagnare credito, accettazione e disponibilità. È più una sfida sociale che tecnica.
È facile dire "No, non farlo" o "scrivi solo codice gestibile". È facile presumere che ogni programmatore sano di mente graviterà verso la stessa soluzione ovvia, semplice e bella. Ma sono qui per dirti che è un'assurdità. La complessità (se possiamo chiamarla così) di qualsiasi progetto è determinata da alcune dinamiche difficili da definire tra cui la cultura istituzionale, la cultura linguistica di programmazione, i gusti individuali, i gusti della comunità e i cambiamenti in tutte queste cose nel tempo. In parole povere, quello che è ovvio oggi non era ovvio ieri e non sarà scontato domani. Per me, questo significa che il modo ovvio di fare le cose non lo è.
A titolo illustrativo, fai pratica come DI . Quando ho iniziato a lavorare su grandi progetti, DI non esisteva. Poi improvvisamente è stato dappertutto. Ero confuso. Perché aggiungere uno strato di riferimento indiretto al codice straight-forward? Dove prima era facile seguire le dipendenze dall'implementazione all'implementazione fino all'implementazione, ora dovevo navigare verso un'interfaccia e capire quale implementazione concreta avevo a che fare. Non era ovvio. Ma ... ha avuto i suoi benefici. Ha reso i test più facili e, con un po 'di fortuna, ha creato un cambiamento nel modo di pensare che ha reso i test una preoccupazione primaria. Quindi, mi piace DI. Ma dire che è ovvio e semplice è una mezza verità. È ovvio e semplice a determinati obiettivi (testabilità, programmazione su un'interfaccia) ma non è ovvio e semplice per un nuovo programmatore.
Come esempio di minore impresa, guarda il Lua codice sorgente rispetto al codice del kernel di Linux. Entrambi i progetti sono molto attenti alla semplicità e alle prestazioni, eppure entrambi i progetti sembrano molto, molto diversi. Come può essere se tutti i bravi programmatori arrivassero alla stessa soluzione semplice? (Vi assicuro che entrambi i progetti godono degli sforzi dei programmatori eccellenti Personalmente, trovo che la fonte Lua sia stimolante e piacevole).
Ciò significa per te che è impossibile per noi dire se dovrebbe o non dovrebbe usare tecniche "avanzate". Dipende davvero dalla tua squadra e dal tuo progetto. Ciò che è avanzato per una squadra non è per un'altra. Prestare particolare attenzione durante la revisione del codice. (Hai recensioni del codice, giusto?) Se un membro del team o due commenta che il tuo codice è un po 'complicato, elabora il tuo feedback e prova a rendere il tuo codice "localmente idiomatico". Se lo stai facendo bene, dovrebbe essere difficile dire chi ha scritto quale codice in un progetto. Miscela. Se ciò non sembra giusto, (succede), forse il progetto o la squadra non fanno per te.
Leggi altre domande sui tag c++