Come allenarsi per evitare di scrivere un codice "intelligente"? [chiuso]

Conosci quella sensazione quando hai solo bisogno di mostrare quel nuovo trucco con Expressions o generalizzare tre diverse procedure? Questo non deve essere su scala di Architecture Astronaut e in effetti può essere utile ma non posso fare a meno di notare che qualcun altro implementerebbe la stessa classe o pacchetto in un modo più chiaro, diretto (e talvolta noioso).

Ho notato che spesso disegno programmi risolvendo il problema , a volte deliberatamente e talvolta per noia. In entrambi i casi, di solito credo onestamente che la mia soluzione sia cristallina ed elegante, fino a quando non vedo prove del contrario, ma di solito è troppo tardi. C'è anche una parte di me che preferisce ipotesi non documentate alla duplicazione del codice e intelligenza alla semplicità.

Cosa posso fare per resistere alla tentazione di scrivere un codice "intelligente" e quando dovrebbe suonare la campana che sto facendo ?

Il problema sta diventando ancora più urgente poiché ora sto lavorando con un team di sviluppatori esperti, e talvolta i miei tentativi di scrivere codice intelligente sembrano sciocchi anche a me stesso dopo che il tempo dissipa l'illusione dell'eleganza.

Il problema sta diventando ancora più urgente poiché ora sto lavorando con un team di sviluppatori esperti, e talvolta i miei tentativi di scrivere codice intelligente sembrano sciocchi anche a me stesso dopo che il tempo dissipa l'illusione dell'eleganza.

La tua soluzione sta qui. Presumo che "sperimentato" in questo contesto significhi "più esperto di te". Per lo meno, li rispetti chiaramente. Questa è una preziosa opportunità di apprendimento - supponendo che il tuo ego possa subire il colpo. (Cose fastidiose, ego. Peccato che ne abbiamo bisogno.)

Hai recensioni di codice con queste persone? Se è così, se non lo stanno già facendo, chiedi loro esplicitamente di chiamarti per le tue cazzate. Ricorda che hai notato una tendenza in te stesso a progettare in modo eccessivo, a utilizzare un martello pneumatico pneumatico top-of-the-line progettato meticolosamente (esercitato preferibilmente da una sorta di androide automatizzato per i lavoratori della strada) quando un semplice martello da carpentiere sarebbe più che sufficiente .

Spesso potresti ritrovarti a dimenarti sul sedile mentre il tuo viso diventa rosso durante le revisioni del codice. Sopportalo. Stai imparando.

Quindi, una volta che hai alcuni di questi sotto la cintura, presta attenzione ai momenti in cui sospetti che forse stai sovrascrivendo. Quando arrivano quei momenti, chiediti: "Se qualcuno mi chiama a questo durante la revisione del codice, posso difendere la mia soluzione come la migliore disponibile? O c'è una soluzione più semplice che sto abbandonando?"

A volte, la revisione tra pari è il modo migliore per dare una buona occhiata al proprio lavoro.

La cosa migliore da fare è tenere presente la massima di Brian Kernighan:

“Il debug è due volte più difficile della scrittura del codice in primo luogo. Pertanto, se scrivi il codice nel modo più intelligente possibile, per definizione, non sei abbastanza intelligente da eseguirne il debug. "

Di solito ci sono almeno tre soluzioni a problemi software di qualsiasi significato: il modo ovvio, un modo complesso non ovvio (intelligente) e un modo semplice non ovvio (elegante). Una citazione sugli autori è applicabile qui:

Metti giù tutto quello che ti viene in mente e poi sei uno scrittore. Ma un autore è colui che può giudicare il valore delle sue cose, senza pietà, e distruggere la maggior parte. - Colette

Non sarai in grado di scrivere un codice elegante fino a quando non potrai giudicare il valore del tuo codice, senza pietà, e distruggere la maggior parte di esso. Se giudichi un codice elegante in base al risultato finale, sembra ingannevolmente facile, ma richiede un rallentamento, passare attraverso molte bozze, cercare il consiglio di altri ed eccitare ciò che non si trova proprio sulla pagina. Ciò significa che anche se il tuo codice funziona perfettamente, chiedi a te stesso oa un collega perché qualcosa non va bene, fino a quando non sei soddisfatto della risposta. Forse sembra troppo lungo o ripetitivo o ritieni che il compilatore avrebbe dovuto essere in grado di rilevare un certo tipo di bug. La maggior parte dei programmatori con una piccola esperienza può riconoscere facilmente il codice inelegante. Il trucco è capire perché .

Questo è il modo metodico per scrivere codice più elegante. Spesso richiede anche un lampo di intuizione che ti aiuta a guardare un problema in un modo nuovo. Questo è più difficile da ottenere, ma aiuta a rallentare e pensare a un problema prima di immergerti nella programmazione. Quando trovi una buona soluzione, cercane una migliore. La lettura di altro codice aiuta. Prendere lezioni o leggere libri sulle migliori pratiche aiuta. L'apprendimento di altri paradigmi di programmazione aiuta. Chiedere consiglio ai colleghi di cui ammiri il codice che ammiri.

Aggiungerei le risposte esistenti, svilupperei in modo TDD, quindi prima scrivi test su cosa dovrebbe fare il tuo codice, e poi implementa per rendere i tuoi test verdi. In questo modo, soddisferai solo i requisiti imposti dai test. Dal momento che scriverai il test, è un buon modo per un approccio autodisciplinato allo sviluppo.

Quando si lavora per un team ampio e dinamico che si estende su diversi set di competenze e anni, lo sviluppo ha una naturale progressione da "attenuare" al livello più basso del membro del team più conservatore o intellettualmente più carente, attuale o storico.

Questo potrebbe non essere necessariamente una cosa negativa perché il codice intelligente può essere più difficile da eseguire il debug, più difficile da trasmettere in una specifica tecnica e impiegare più tempo a scrivere, rallentando i tempi di sviluppo.

Ci sono momenti in cui il codice intelligente è importante, come quando il codice intelligente fornisce efficienza e guadagni in termini di prestazioni più avanti nel ciclo di maturità del software quando le prestazioni diventano un requisito.

Il codice intelligente ha anche un modo per trasmettere un codice più rapido da sviluppare e più leggibile e comprensibile a un team che potrebbe non essere esposto a una nuova funzione linguistica o alla chiamata in biblioteca. Ad esempio, quando sono stato presentato a Linq per la prima volta da uno sviluppatore junior, ho avuto un disgusto immediato in quanto inutile, difficile da debug, sciocco e "intelligente". Dopo aver giocato con me stesso e aver scoperto quanto possano essere utili e potenti le query Linq, ho investito il tempo per impararlo e il mio codice DAL non è mai stato più pulito e leggibile, oltre che più facile da eseguire il debug e l'estensione.

Mi dispiace non avere una mente aperta prima e vorrei non essere stato così duro con uno sviluppatore junior "intelligente".

Il mio punto è che il codice "intelligente" DOVREBBE essere sospetto, ma non dovremmo andare in crociata contro di esso perché potrebbe soffocare la creatività e l'innovazione.

EDIT: Ho appena realizzato che non ho risposto completamente alla tua domanda. Se hai la capacità nel tuo progetto di scrivere molto facilmente un codice intelligente, forse il team dovrebbe adottare standard di codifica più rigorosi per seguire un modello e uno stile uniformi e distinti. Questo ti aiuterà a tracciare le linee della tua sandbox in modo da non vagare per la strada inseguendo una palla.

Se il 20% (la tua% può variare) o più delle tue righe aggiunte devono essere documentazione, è tempo di fare un passo indietro e ripensare .

Penso davvero che dovresti sforzarti di essere intelligente, è un effetto collaterale naturale di diventare più abile. Darti una linea guida generale come% dei commenti necessari per chiarirti è un buon modo per forzarti a indietreggiare e valutare se usare quella nuova cosa che hai imparato è una scelta saggia o solo un modo per sfoggiare il tuo nuovo giocattolo.

Non posso resistere a provare qualcosa di intelligente.

Quindi lo faccio su un progetto giocattolo, nel mio tempo libero, a casa.

Quando la novità svanisce - problema risolto.

Credo che un modo per scoprire se il tuo codice è troppo "intelligente" è fare un passo indietro e chiederti quanto segue:

Se dovessi dare una stampa di questo codice a qualcuno che non ha mai lavorato su questo progetto / codice, sarebbero in grado di leggerlo e descrivermi cosa fa la funzione (dopo aver dato loro un breve contesto)? In caso contrario, quanta spiegazione avrei dovuto fare? Come lo spiegherei a qualcuno che prende CS101?

Se si scopre che dovresti percorrere qualcuno attraverso ogni linea o la maggior parte delle linee in un metodo o in una classe, probabilmente è troppo intelligente. Se devi spiegare i costrutti del linguaggio (LINQ per esempio) a qualcuno che non ha familiarità con esso, probabilmente è OK. Se devi guardare una linea e pensarci un po 'prima di poterlo spiegare, il tuo codice deve essere sottoposto a refactoring.

1) Bruciati da esso prima in modo da sapere che è una brutta cosa. Tentare di eseguire il debug di qualcosa di molto tempo fa scritto in modo intelligente è molto divertente. Penso che tu l'abbia coperto.
2) Commenta il tuo codice, spiega cosa stai facendo prima di ogni sezione del codice.
3) Se ti trovi in ​​difficoltà a spiegarlo, o senti la necessità di inserire un diagramma, allora quello che hai appena fatto è troppo intelligente e probabilmente potrebbe essere fatto in modo più pulito.

Le soluzioni intelligenti ai problemi possono essere fantastiche, fino a quando non è necessario eseguire il debug o espanderle. A volte è l'unica soluzione. Se riesci a descrivere accuratamente cosa diavolo fa e come lo fa, soluzioni intelligenti possono essere accettabili.

Di solito uso i commenti per descrivere cosa sto facendo con una sezione di codice. Se sembra minimamente confuso, descrivo anche come lo sto facendo. Idealmente, il codice dovrebbe essere semplice e autoesplicativo. Ma se faccio fatica a spiegare come ho fatto quello che ho appena fatto, allora è un chiaro segnale che devo fare un passo indietro e riprovare.

Probabilmente un buon modo per iniziare a scrivere codice semplice è quello di rilasciare la passione di intelligenza in un progetto che richiede intelligenza . Il resto della risposta è specifico di .NET ma sono sicuro che si possano trovare progetti di livello simile in qualsiasi altra lingua.

Ci sono framework di iniezione di dipendenze open source su cui lavorare, per cui basta chiedere Expressionconoscenze di trucchi, c'è F # e una vasta gamma di attività che potresti voler provare.

Se sei un appassionato di matematica (e questo è il linguaggio agnostico ), c'è Project Euler per te.

Ultimo, ma non meno importante, nel mondo .NET c'è Mono Project che ha molte aree che richiedono attenzione da parte degli sviluppatori , alcune delle quali piuttosto complicate. Che ne dici di contribuire a uno strumento di analisi del codice .NET statico open source ? Ci sono alcune analisi IL coinvolte, così come roba di alto livello. Jb Evain funziona sempre su qualcosa di interessante, che si tratti della libreria di riflessione Cecil, del Expressionsupporto o di un decompilatore .NET.

Se nulla si adatta, basta avviare il proprio framework beffardo :-)

Conosci quella sensazione quando hai solo bisogno di mostrare quel nuovo trucco con le espressioni o generalizzare tre diverse procedure?

No

Questo è uno dei motivi per cui dico sempre che è una buona cosa quando i nuovi sviluppatori vengono gettati in un grande vecchio pasticcio di codice speghetti non documentato da mantenere e refactoring. Insegnerà loro la realtà di mantenere un codice troppo "intelligente" che non hanno scritto, e si spera di instillare un po 'di empatia per il povero schmuck che dovrà eseguire il debug del loro codice tra 5 anni.

Penso che l'argomento sia ben scelto. È "bello" scrivere una riga di Perl che fa diecimila cose tutte in una volta, ma poi fa schifo quando devi rivederlo.

Su una nota diversa, intelligente o no, il codice deve essere documentato. Esiste una discrepanza intrinseca di impedenza tra i linguaggi di programmazione accettati dall'industria e i concetti di alto livello a cui noi come esseri umani siamo abituati nel nostro pensiero. Il codice auto-documentante non è semplicemente realizzabile - fino a quando non diventa linguaggio naturale, cioè. Anche il codice Prolog deve essere documentato, poiché, per quanto possa essere di alto livello, è ancora piuttosto formale.

Il codice imperativo a grana fine serve per implementare piani a grana grossa, che devono essere documentati. Non voglio leggere tutte le 50 righe del metodo quando verrà eseguito un rapido commento sulla roadmap a 3 righe.

Modifica successiva: un esempio più eloquente è quello che trascende i computer. Un libro può essere scritto molto bene, ma spesso vogliamo elaborarlo a diversi livelli di astrazione. Spesso, farà un riassunto del libro, ed è quello che i commenti possono offrire al codice. Ovviamente un codice ben astratto può fare molto per l'autodocumentazione, ma non può darti tutti i livelli di astrazione.

E i commenti possono anche agire come sidenotes in un libro, quando dobbiamo spiegare il processo di ragionamento alla base di un'affermazione nel testo principale senza far deragliare.

In questo contesto, trovo che la mia precedente dichiarazione relativa al linguaggio naturale che trascende la necessità di commenti sia errata. Anche il linguaggio naturale, come in un libro, può prestarsi alla documentazione, per spiegare in modo scarso l'astrazione incorporata nel testo o per fornire deviazioni senza far deragliare il testo principale. Con la nota che un codice ben astratto potrebbe già aver fatto molto per essere auto-documentante.

Ultimo, ma non meno importante, i commenti possono aiutare il programmatore a mantenere un alto livello di astrazione. Spesso mi rendo conto che due commenti consecutivi che ho inserito in un elenco di passaggi non parlano allo stesso livello di astrazione, il che merita immediatamente uno sguardo critico a ciò che sto facendo con quel codice.

Alcuni problemi trascendono la codifica e influiscono sulla codifica proprio come altre attività. I commenti possono fornire quell'aiuto per chiarire la logica alla base e le sfaccettature del nostro codice, e trovo loro un compagno piacevole che parla un linguaggio più morbido a beneficio della persona per un cambiamento.

Come? Continua a mostrare il tuo codice a quegli sviluppatori esperti. e quando ti fai saltare in aria per essere sofisticato e appariscente, succhialo e chiedi loro come lo farebbero e perché (in modo non conflittuale ovviamente).

Modifica alla luce di -1:

Molte lune fa, mi trovavo nella stessa situazione: avevo un boss che si irritava ogni volta che usavo un puntatore in Delphi o il "con costrutto", un altro che minacciava di licenziarmi se non avessi smesso di cortocircuitare tutti i miei booleani con 0-1 e usando variabili a lettera singola ovunque.

Ho imparato perché ho chiesto perché e si sono presi la briga di spiegare perché pensavano che potessi equivalere a qualcosa - LOL ....

Sento il bisogno di mettermi in mostra? No non più. Come l'ho superato? Come la maggior parte delle persone supera qualsiasi altra cattiva abitudine ... pratica consapevole e deliberata di tecniche adeguate. Se lo fai abbastanza capirai il valore delle migliori pratiche e attraverso il loro uso costante svilupperai buone abitudini.

Renditi anche conto che concentrandoti sul software funzionale, che è puntuale e facilmente gestibile, otterrai il riconoscimento che cerchi. Gli sviluppatori esperti verranno da te e diranno "Amico, quel modulo che hai scritto era ben progettato. Ho dovuto implementare un solo componente per collegarlo al mio progetto." al contrario di "Ho dovuto rielaborare l'intero modulo che hai scritto solo per usarlo in un altro componente? Hai mai sentito parlare di Bob Martin o Ward Cunningham?"

TLDR: non sei solo. Il riconoscimento delle competenze si ottiene meglio come sottoprodotto della risoluzione dei problemi in modo intelligente.

Per me, un codice eccessivamente intelligente spesso si sforza di risolvere i futuri requisiti immaginari invece di concentrarsi sui requisiti di oggi. Grande trappola!

Lo 0% di codice troppo complicato non è un obiettivo raggiungibile. Forse nemmeno l'obiettivo migliore per cui lottare. Il codice troppo complicato è negativo, ma devi provare nuove cose per crescere come programmatore. Non dovresti provarli sul codice di produzione se puoi evitarlo. A differenza delle macchine, gli umani commettono errori.

Guida recensioni di codice. Passare anni a sistemare il codice "intelligente" di altre persone aiuta. Rimanere concentrati su ciò di cui il cliente ha veramente bisogno oggi aiuta.

Le scuole e le imprese hanno personale addetto alla pulizia e alla manutenzione del personale. Anche il codice necessita di pulizia e manutenzione! Quando possibile, pulisci i pasticci (soprattutto i tuoi)! Penso che sia il migliore che si possa fare.

Oltre ai buoni consigli dati finora (revisione del codice, debug, approccio TDD) dovresti (ri) leggere di volta in volta i (migliori libri imho) sulle buone pratiche di codifica:

• Programmatore pragmatico
• Codice completo
• Codice pulito

e altri, a seconda della tecnologia utilizzata.

Ricorda solo YAGNI: non ne avrai bisogno .

il programmatore non dovrebbe aggiungere funzionalità fino a quando ritenuto necessario ...

YAGNI è un principio alla base della pratica XP di "fare la cosa più semplice che potrebbe funzionare" (DTSTTCPW). È pensato per essere utilizzato in combinazione con diverse altre pratiche, come il refactoring continuo, il test automatico continuo delle unità e l'integrazione continua. Utilizzato senza refactoring continuo, potrebbe portare a codice disordinato e rilavorazioni di massa ...

Secondo coloro che sostengono l'approccio YAGNI, la tentazione di scrivere codice che al momento non è necessario, ma che potrebbe essere in futuro, presenta i seguenti svantaggi:

• Il tempo impiegato viene impiegato per aggiungere, testare o migliorare la funzionalità necessaria.
• Le nuove funzionalità devono essere sottoposte a debug, documentate e supportate.
• Qualsiasi nuova funzione impone vincoli su ciò che può essere fatto in futuro, quindi una funzione non necessaria può impedire l'aggiunta di funzioni necessarie in futuro.
• Fino a quando la funzionalità non è effettivamente necessaria, è difficile definire completamente cosa dovrebbe fare e testarla. Se la nuova funzionalità non è definita e testata correttamente, potrebbe non funzionare correttamente, anche se alla fine è necessaria.
• Porta a codice gonfio; il software diventa più grande e più complicato.
• A meno che non ci siano specifiche e un qualche tipo di controllo di revisione, la funzione potrebbe non essere nota ai programmatori che potrebbero farne uso.
• L'aggiunta della nuova funzionalità può suggerire altre nuove funzionalità. Se anche queste nuove funzionalità sono implementate, ciò può provocare un effetto valanga verso lo scorrimento delle funzionalità ...