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

The problem is getting even more pushing as I'm now working with a team of experienced developers, and sometimes my attempts at writing smart code seem foolish even to myself after time dispels the illusion of elegance.

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

Hai recensioni di codice con queste persone? Se è così, se non lo fanno già, chiedi esplicitamente di chiamarti con le tue cazzate. Menziona che hai notato una tendenza in te stesso a sovradimensionare, usare un martello pneumatico pneumatico top-of-the-line meticolosamente progettato (preferibilmente impugnato da una sorta di androide automatico di strada) quando un semplice artiglio sarebbe più che sufficiente .

Spesso ti ritrovi a dimenarti sul sedile mentre il tuo viso diventa rosso durante le revisioni del codice. Resistere. Stai imparando.

Quindi, una volta che hai alcuni di questi sotto la cintura, presta attenzione ai momenti in cui sospetti che forse stai forse sovrintendendo. Quando arrivano questi momenti, chiediti: "Se qualcuno mi chiama 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 peer review è il modo migliore per dare un'occhiata al tuo lavoro.

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

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

Di solito esistono almeno tre soluzioni ai 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:

Put down everything that comes into your head and then you're a writer. But an author is one who can judge his own stuff's worth, without pity, and destroy most of it. — Colette

Non sarai in grado di scrivere codice elegante finché non potrai giudicare il valore del tuo codice, senza pietà, e distruggerne la maggior parte. Se giudichi il codice elegante in base al risultato finale, sembra apparentemente facile, ma richiede un rallentamento, il superamento di molte bozze, la ricerca del consiglio degli altri e l'esclusione di ciò che non si trova nella pagina. Ciò significa che anche se il tuo codice funziona perfettamente, chiedi a te stesso oa un collega perché qualcosa non sembra giusto finché non sei soddisfatto della risposta. Forse sembra troppo lungo, o ripetitivo, o senti che il compilatore avrebbe dovuto essere in grado di catturare un certo tipo di bug. La maggior parte dei programmatori con un minimo di esperienza può facilmente riconoscere 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 raggiungere, ma aiuta a rallentare e basta pensare a un problema prima di immergerti nella codifica. Quando trovi una buona soluzione, cercane una migliore. Leggere 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 aiuta il codice che ammiri.

Vorrei aggiungere alle risposte esistenti, svilupparle in modo TDD, quindi prima scrivi test su cosa dovrebbe fare il tuo codice e poi implementalo per rendere i tuoi test verdi. In questo modo, soddisferà solo i requisiti imposti dai test. Dato che starai scrivendo il test, è un buon modo per un approccio autodisciplinato allo sviluppo.

Quando lavori per un team ampio e dinamico che si estende su molti set di abilità e anni diversi, lo sviluppo ha una naturale evoluzione da "sottovalutare" al livello più basso del membro più conservatore o intellettualmente deficiente del team, attuale o storico.

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

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

Il codice intelligente ha anche un modo di trasmettere un codice di sviluppo più veloce e più leggibile e comprensibile a una squadra che potrebbe non essere esposta a una nuova funzione di lingua o chiamata di libreria. Per 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 debellare, sciocco e "intelligente". Dopo aver giocato con me stesso e aver scoperto quanto siano utili e potenti le query di Linq, ho investito il tempo necessario per impararlo e il mio codice DAL non è mai stato più pulito e leggibile, oltre a facilitare il debug e l'estensione.

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

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

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

Se il 20% (la tua% può variare) o più delle tue linee aggiunte devono essere documentate - è il momento di fare un passo indietro e ripensare .

Penso davvero che dovresti sforzarti di essere intelligente, è un naturale effetto collaterale di diventare più abile. Darti una guida generale come% di commenti necessari per farti capire è un buon modo per costringerti a tirarti indietro e valutare se usare quella nuova cosa che hai imparato sia una scelta saggia o solo un modo per mostrare il tuo nuovo giocattolo.

Non posso resistere a provare qualcosa di intelligente.

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

Quando la novità svanisce - problema risolto.

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

If I were to give a printout of this code to someone who has never worked on this project / code, would they be able to read it and describe back to me what the function does (after giving them some brief context)? If not, how much explaining would I have to do? How would I explain this to someone taking CS101?

Se si scopre che dovresti camminare qualcuno attraverso ogni linea o più linee in un metodo o in una classe, è probabilmente troppo intelligente. Se devi spiegare costrutti linguistici (LINQ per esempio) a qualcuno che non ha familiarità con esso, probabilmente è OK. Se devi guardare una linea e pensarci per un po 'prima di poterla spiegare, il tuo codice deve essere rifatto.

1) Fatti bruciare prima, così sai che è una brutta cosa. Tentare di eseguire il debug di qualcosa di molto tempo fa che è stato scritto in modo intelligente è molto divertente. Penso che tu abbia quello coperto.
2) Commenta il tuo codice, spiega cosa stai facendo prima di ogni sezione di 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, finché non è necessario eseguirne il debug o l'espansione. A volte è l'unica soluzione. Se riesci a descrivere esattamente cosa diavolo fa e come funziona, soluzioni intelligenti possono essere accettabili.

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

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

Ci sono framework di integrazione delle dipendenze open source per lavorare su cui chiedere la conoscenza di trucchi Expression , c'è F # e meravigliosa gamma di compiti che si potrebbe desiderare di provare.

Se sei un esperto di matematica (e questo è agnostico della lingua ), c'è Project Euler per te.

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

Se non ci sono problemi, solo inizia la tua personale struttura di derisione : - )

Do you know that feeling when you just need to show off that new trick with Expressions or generalize three different procedures?

No

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

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

Su una nota diversa, intelligente o meno, il codice deve essere documentato. Esiste un disallineamento di impedenza intrinseca tra i linguaggi di programmazione accettati dal settore e i concetti di alto livello a cui noi esseri umani siamo abituati nel nostro modo di pensare. Il codice di auto-documentazione non è semplicemente realizzabile - finché non diventa un linguaggio naturale, cioè. Anche il codice Prolog deve essere documentato, poiché, per quanto alto possa essere, è ancora piuttosto formale.

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

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

E i commenti possono anche comportarsi come i sidenotes in un libro, quando abbiamo bisogno di spiegare il processo di ragionamento dietro un reclamo nel testo principale senza deragliare.

Con questo contesto, trovo che la mia precedente affermazione che si riferisce al linguaggio naturale che trascende la necessità di commenti non è corretta. Anche il linguaggio naturale, come in un libro, può prestarsi alla documentazione, spiegare in modo spoglio l'astrazione incorporata nel testo o fornire deviazioni senza far deragliare il testo principale. Con la nota che il codice ben astratto potrebbe già aver fatto molta strada per essere autodocumentato.

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 incluso in una lista di passaggi non parlano allo stesso livello di astrazione, che immediatamente garantisce uno sguardo critico su quello che sto facendo con quel codice.

Alcuni problemi trascendono la codifica e influenzano la codifica, proprio come altre attività. I commenti possono fornire quell'aiuto per chiarire la logica alla base, e le sfaccettature del nostro codice, e li trovo 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 vieni distrutto per essere alquanto sofisticato e appariscente, succhialo e chiedi loro come lo faranno e perché (in modo non conflittuale, ovviamente).

Modifica alla luce di -1:

Molte lune fa, ero nella stessa situazione - Avevo un capo che rabbrividiva ogni volta che usavo un puntatore in Delphi o il 'con costrutto', un altro che minacciava di licenziarmi se non smettevo di cortocircuitare tutti i miei booleani con 0-1 e usano variabili a lettera singola ovunque.

Ho imparato perché ho chiesto perché e si sono presi la briga di spiegare perché pensavano che potessi ammontare 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 cosciente e deliberata di tecniche appropriate. Lo fai abbastanza capirai il valore delle migliori pratiche e attraverso il loro uso costante svilupperai buone abitudini.

Comprendi anche che concentrandoti sul software funzionale, che è in tempo e facilmente gestito, otterrai il riconoscimento che cerchi. Gli sviluppatori esperti verranno da te e diranno "Man quel modulo che hai scritto era ben progettato. Ho solo dovuto implementare un 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 dell'abilità è il migliore risultato come sottoprodotto della soluzione dei problemi in modo intelligente.

Per me, il codice troppo intelligente si sforza spesso di risolvere i futuri requisiti immaginari invece di concentrarsi sui requisiti odierni. Grande trappola!

Lo 0% di codice troppo complicato non è un obiettivo raggiungibile. Forse nemmeno l'obiettivo migliore per cui lottare. Il codice troppo complicato è cattivo, 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.

Aiuto per la revisione del codice. Passare anni a sistemare il codice "intelligente" di altre persone aiuta. Rimanere concentrato su ciò di cui il cliente ha realmente bisogno oggi aiuta.

Le scuole e gli affari hanno personale di pulizia e manutenzione del personale. Il codice richiede anche pulizia e manutenzione! Quando possibile, ripulisci i pasticci (proprio tu stesso)! Penso che sia il migliore che si possa fare.

Oltre ai buoni consigli forniti fino ad ora (revisione del codice, debugging, approccio TDD) dovresti (ri) leggere di volta in volta i (migliori libri imho) sulle buone pratiche di codifica:

• Programmatore pragmatico
• Codice completo
• Pulisci codice

e altri, a seconda della tecnologia che usi.

Ricorda YAGNI - Non ne avrai bisogno .

programmer should not add functionality until deemed necessary...

YAGNI is a principle behind the XP practice of "do the simplest thing that could possibly work" (DTSTTCPW). It is meant to be used in combination with several other practices, such as continuous refactoring, continuous automated unit testing and continuous integration. Used without continuous refactoring, it could lead to messy code and massive rework...

According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

• The time spent is taken from adding, testing or improving the necessary functionality.
• The new features must be debugged, documented, and supported.
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature may preclude needed features from being added in the future.
• Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work correctly, even if it eventually is needed.
• It leads to code bloat; the software becomes larger and more complicated.
• Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards feature creep...