Ultimamente ho notato molte domande relative a diverse tecniche di astrazione e risposte affermando in sostanza che le tecniche in questione sono "troppo intelligenti". Penso che parte del nostro lavoro di programmatori sia quello di determinare le migliori soluzioni ai problemi che ci vengono dati per risolvere, e l'intelligenza è utile per farlo.

Quindi la mia domanda è: le persone che pensano che certe tecniche di astrazione siano troppo intelligenti rispetto all'intelligenza di per sé , o c'è qualche altra ragione per l'obiezione?

EDIT: Questo combinatore parser è un esempio di quello che considererei un codice intelligente. L'ho scaricato e l'ho guardato per circa mezz'ora. Poi ho attraversato l'espansione macro su carta e ho visto la luce. Ora che lo capisco, sembra molto più elegante del combinatore di parser Haskell.

Le soluzioni semplici sono migliori per la manutenzione a lungo termine. E non si tratta sempre solo di familiarità linguistica. Una linea (o linee) complesse richiede tempo per capire anche se sei un esperto in una determinata lingua. Apri un file e inizi a leggere: "ok, semplice, semplice, capito, sì, WTF ?!" Il tuo cervello si ferma e ora devi fermarti e decifrare una linea complicata. A meno che non ci fosse una ragione misurabile e concreta per questa implementazione, è "troppo intelligente".

Capire cosa sta succedendo diventa progressivamente più difficile man mano che la complessità passa da un metodo intelligente a una classe intelligente a un modello intelligente. A parte approcci ben noti, devi capire il processo di pensiero che ha portato alla creazione di una soluzione "intelligente", che può essere abbastanza difficile.

Detto questo, odio evitare un modello (quando il suo uso è giustificato) solo perché qualcuno potrebbe non capirlo. Spetta a noi come sviluppatori continuare a imparare e se non capiamo qualcosa, è un motivo per impararlo, non per evitarlo.

Principio KISS

Mantenerlo semplice, stupido. Le soluzioni intelligenti sono eccezionali, ma spesso la soluzione più semplice e semplice è la migliore.

"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. "

Brian Kernighan

Gli sciocchi ignorano la complessità; i pragmatici lo soffrono; gli esperti lo evitano; i geni lo rimuovono. - Alan Perlis

La soluzione migliore non è sempre la soluzione più intelligente. A volte le soluzioni semplici sono ugualmente buone.

Nel software devi sempre pensare in termini di manutenibilità. Se un pezzo di codice è troppo intelligente per qualcuno che lo manterrà, direi che l'intelligenza non ne vale la pena.

Per citare 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. "

l'intelligenza è uno strumento; da solo non è dannoso. Diventa dannoso solo nel contesto in cui non è necessario.

"Clever", quando applicato al codice, è quasi sempre solo un eufemismo per "inutilmente complicato".

Leggere un codice semplice, chiaro e semplice è abbastanza difficile. Leggere un codice "intelligente" è come studiare nuovamente la poesia latina.

La confusione sorge perché "intelligente" come attributo di una persona ha un significato completamente diverso. Questo caso può anche essere visto come un esempio del motivo per cui progettare software per persone reali è difficile: perché sono ambigui.

E poiché alcuni programmatori soffrono nel comprendere i protocolli sociali che la maggior parte delle persone segue, il che proibisce loro di denunciare direttamente il codice come "inutilmente complicato", possono trovare difficoltà a distinguere i due significati della parola intelligente . Contrariamente a quanto alcuni potrebbero pensare, in definitiva penso che "persone persone" migliori (ovvero persone che hanno empatia, introspezione e pazienza) siano sviluppatori migliori. Perché sanno per chi scrivere.

Molte persone si stanno concentrando sull'intelligenza da un aspetto di "Il codice richiede troppe decifrazioni per capire cosa sta facendo" e tutte le cose cattive che vanno di pari passo con quelle come

1. Nessun altro può capirlo, figuriamoci mantenerlo / eseguirne il debug.
2. La persona che ha scritto non sa nemmeno cosa fa.
3. In realtà potrebbe non essere così brillante per cominciare
4. eccetera....

Tutti i punti positivi, ma c'è un altro aspetto negativo dell'abilità e questo è il vecchio problema dell'ego. Ciò causa problemi sulla falsariga di

1. Qualcuno che è troppo "intelligente" per utilizzare le soluzioni di qualcun altro. Perché cercare cosa hanno fatto gli altri quando puoi inventare il tuo modo di scuoiare lo stesso gatto?
2. Qualcuno che pensa di aver inventato la soluzione più interessante a un problema spesso rifiuta di accettare qualsiasi input.
3. Non permettere a nessuno di modificare il "proprio" codice anche quando ci sono problemi evidenti o è necessaria una banale modifica.
4. In qualche modo al contrario, pensano di essere intelligenti e hanno bisogno di usare la tecnica "più recente" per dimostrare quanto sono intelligenti ma non riescono a controllarlo in progetti personali o in altri codici non di produzione prima di farlo scorrere in parti critiche di il sistema.

A volte siamo tutti colpevoli di troppo ego, ma quando si mette in mezzo alla squadra è un problema.

Buona intelligenza: elevato rapporto tra linee di codice intelligenti e linee di un'alternativa non intelligente. 20 righe di codice che ti salvano dalla scrittura di 20000 sono estremamente intelligenti. Bravo intelligente, ti risparmia il lavoro.

Bad Clever: basso rapporto tra righe di codice scritte e righe di codice salvate. Una riga di codice intelligente che ti salva dalla scrittura di cinque righe di codice è Bad Clever. La cattiva intelligenza riguarda la "masturbazione sintattica".

Solo per notare: Bad Clever non viene quasi mai chiamato "Bad Clever"; viaggerà spesso sotto gli alias "bello", "elegante", "conciso" o "succinto".

Devo chiedermi quale sia la definizione intelligente di tutti.

Personalmente, mi sento come se fossi stato intelligente quando ho affrontato un problema difficile e complesso e l'ho implementato in un modo molto semplice e diretto, pur mantenendo un livello accettabile di efficienza.

tl; dr mi sento intelligente quando, durante una revisione del codice, il mio recensore dice "wow, è stato più facile di quanto pensassi che sarebbe stato", al contrario di "wtf è tutto questo .."

A parte le risposte teoriche elencate, spesso questo viene utilizzato nel contesto di troppo intelligente per tutti gli altri.

Spostati tra un team ad alto rendimento ad alto livello e un team di manutenzione di livello medio per vedere le differenze nella vita reale in ciò che è "troppo intelligente".

Tralasciando gli argomenti della teoria, troppo intelligente si basa spesso su ciò con cui i membri del team meno abili possono lavorare in modo ragionevole, quindi è molto relativo all'ambiente.

A volte sono stato così intelligente che ho sbagliato.

Prestazioni, mantenibilità, puntualità ed economicità sono i modi in cui misuro una soluzione. Immagino che anche l'intelligente possa far parte di una soluzione purché non influisca negativamente su quelle qualità.

Se il codice intelligente + la quantità di commenti richiesti per renderlo comprensibile <= codice semplice, allora dico di usare il codice intelligente. Ogni volta.

Penso che il problema si presenti quando le persone che scrivono "codice intelligente" deliberatamente non riescono a commentarlo correttamente, perché solo quando sarà inizialmente incomprensibile le generazioni future che lo incontreranno dovranno trascorrere del tempo "apprezzando" quanto sia intelligente.

Mi viene in mente una citazione che ho visto attribuito a molte persone diverse, come spesso fanno le buone citazioni.

Per parafrasare:

Qualsiasi persona intelligente può rendere il complesso semplice, ci vuole un genio per rendere semplice il complesso.

Prendere un'idea complessa e semplificarla in modo che sia comprensibile mostra l'intelligenza del costruttore, ma prendere un'idea semplice e renderla complessa mostra che il costruttore vuole essere visto come intelligente.

Se la soluzione "intelligente" è difficile da capire, allora non dovrebbe essere utilizzata. Ad esempio, se attraverso effetti collaterali è possibile contrarre un calcolo complesso su una riga, è intelligente. Ma se ci vuole un'ora per qualcun altro a capire cosa hai fatto nel mondo, è troppo intelligente.

Secondo me, l'intelligenza in sé non è un problema. Di solito possiamo fare confusioni sul codice "intelligente" (senza sarcasmo) e "insightfull". Quello che vedo come un problema, è il fatto che di solito il codice "intelligente" (con sarcasmo) contiene requisiti impliciti non visibili, rendendo più difficile il debug e il mantenimento nel tempo.

Esistono diversi algoritmi noti che sono intelligenti. Quicksort è uno, IMO.

Il codice "intelligente" (con sarcasmo) di solito fa ipotesi sull'impostazione delle variabili e sugli stati del sistema che sono virtualmente disconnessi dal codice "intelligente" (come file aperti in precedenza, connessioni di rete, database, ecc ...).

La quantità di dati che devi caricare sul tuo cervello per mantenere correttamente un codice "intelligente" è di solito troppo grande per avere un buon rapporto costi-benefici.

"Codice intelligente" è qualsiasi codice per il quale il programmatore ha dovuto pensare molto o usare qualche abilità avanzata per scriverlo. Il problema è che non tiene conto della necessità di un certo "margine di intelligenza", meglio espresso da Brian W. Kernighan:

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

Perché ciò che sembra intelligenza a uno sviluppatore in un'esplosione di creatività può semplicemente passare come un casino ed essere semplicemente un blocco illeggibile e non realizzabile di oscuri enigmi per gli altri.

Tuttavia, un blocco di enigmi bello, intelligente e ben funzionante, ma se hai l'esperienza, spesso ti renderai conto che costerà molto di più alla tua attività (non a te, allo sviluppatore) mantenere quella cosa sul mezzo- o a lungo termine. Quindi preferisci calmare l'ardore dei tuoi colleghi sviluppatori quando vengono trasportati.

Tranne, ovviamente, se c'è una giustificazione per l'intelligenza. E se c'è una buona documentazione che accompagna la cosa offuscata che hai appena scritto. Hai commentato quel pezzo di codice intelligente, giusto? Spiega che intento, perché deve essere simile e come si comporta?

Se non ci sono giustificazioni, probabilmente si tratta solo di un problema di ottimizzazione prematura, di ingegneria eccessiva o di un tipo YAGNI. Se ci vogliono 15 livelli di indiretta per fare qualcosa di semplice, allora ci sono buone probabilità di rientrare anche nelle categorie precedenti. E se non è documentato, allora è solo un problema.

Un ottimo codice non dovrebbe richiedere al manutentore di essere sempre al 100% per capirlo. Il buon codice è intelligente. Un ottimo codice può essere altrettanto efficiente, ma migliore in molti altri aspetti. Un ottimo codice non dovrebbe richiedere un IDE con 15 viste per seguire il design della tua applicazione.

Nota: ehi, ho scritto alcune cose che ho pensato di essere intelligente ma che ha disegnato WTF? fuori - se non dai miei co-sviluppatori - la bocca del mio manager. Devono guardarlo dalla loro prospettiva.

Tendo ad essere intelligente , ma mi sforzo di essere elegante .

Sviluppa il codice ora che altri non proveranno ad evitare in seguito .

Questa è la mia comprensione del problema, in base alla mia esperienza e alle altre risposte:

1. Il codice che ha richiesto intelligenza per scrivere, ma risulta leggibile e mantenibile non è considerato dannoso. Tuttavia, la maggior parte degli sviluppatori non chiamerebbe quel tipo di codice "intelligente"; possono usare un termine diverso come "elegante". Potrebbe esserci o meno un dibattito sull'esistenza di tale codice.
2. Il codice di produzione che richiede tempo e sforzi significativi per comprendere anche uno sviluppatore esperto che abbia familiarità con il linguaggio è "intelligente" e considerato dannoso da tutti.
3. Il codice di produzione che richiede tempo e sforzi significativi da sviluppatori inesperti è considerato dannoso da alcuni. Ho visto le risposte in entrambi i modi e ho lavorato con sviluppatori che hanno detto esplicitamente che avrebbero preferito mantenere tutto "il minimo comune denominatore".

Conosco un ragazzo; è probabilmente la persona più brillante che abbia mai incontrato. È sicuramente un programmatore incredibile, probabilmente migliore di quanto sarò mai in tutta la mia vita in termini di semplici programmi di programmazione. Scrive codice come se stesse scrivendo un documento word e può invertire un elenco collegato come non crederesti. Se vuoi parlare di scrivere un codice molto complesso, è il tuo uomo e se incontro un problema incredibilmente difficile, mi rivolgo sempre a lui. Tuttavia, lavorare su un progetto con lui in un ambiente di squadra è lancinante. Non è in grado di affrontare direttamente il problema aziendale e di fornire una soluzione logica, efficiente e concisa. Per lui, un elenco di 1000 righe di codice sarebbe meglio di 100. Invece di utilizzare gli strumenti forniti tramite IDE o framework, lancerà il suo strumento super ottimizzato.

Mentre ammiro la sua capacità di fare queste cose complesse, ciò di cui ho bisogno è qualcuno che possa risolvere il problema e andare avanti. Non è bello da dire o da ammettere, ma a volte in un momento di impostazione aziendale è tutto e devi solo risolvere il problema e andare avanti con la tua vita, puoi sempre tornare su di esso in seguito e rifattorizzare l'inferno per migliorare il tuo codice. C'è una linea sottile tra l'essere intelligente e anche essere un dolore al sedere. Il mio motto per la mia squadra è sempre, qual è la cosa più semplice possibile che funzionerà in questa situazione e poi andrà da lì. A volte più semplice non è sempre la risposta, ma è un dannatamente un buon punto di partenza.

"Intelligente" in questo contesto significa "troppo intelligente per il suo bene", vale a dire qualcosa che funziona ora ma sarà un incubo da capire e cambiare in seguito.

Soprattutto se si tratta di un trucco che sfrutta una caratteristica oscura del linguaggio di programmazione, o fa uso di strani effetti collaterali o è un modo davvero bizzarro di risolvere il problema nel linguaggio di destinazione.

Preferisco soluzioni semplici, mi piace molto il modo rubino. Ad esempio, quando si desidera sommare i primi 2 elementi dell'elenco. prima tagli la lista per farla avere size = 2 e poi la sommi.

Ricordo che una volta ho usato 1 elenco invece di 3 e ho creato una grande funzione che era molto difficile da mantenere / cambiare.

nel mondo di oggi non dobbiamo sacrificare la chiarezza del codice per le prestazioni (tranne c ++, non devono, ma lo faranno).

Di solito, quando devi essere "intelligente", puoi risolvere un problema nel codice. Se è una soluzione alternativa e non molto semplice, otterrai molte facce confuse o altri strani effetti collaterali quando si assumono determinate condizioni (che potrebbero essere corrette al 100% al momento della scrittura del codice)

Così intelligente == confuso == cattivo :( Ma è anche fantastico come li ho usati per soluzioni pratiche a problemi limitati.

Re-quoting per contesto e comprensione più semplice:

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

Ciò che Brian Kernighan ha scritto qui si riferisce ovviamente alla convoluzione, e ha erroneamente usato la parola intelligente.

"Il debug è due volte più difficile della scrittura del codice in primo luogo. Pertanto, se si scrive il codice il più [contorto] possibile, non si è, per definizione, abbastanza intelligenti da eseguirne il debug."

convoluzione:

A thing that is complex and difficult to follow.

Intelligente:

Showing intelligence or skill; ingenious

I programmatori istruiti sanno che il semplice codice è geniale. Il codice più intelligente possibile dovrebbe essere semplice per definizione. I programmatori istruiti eviteranno anche di lavorare e scrivere codice contorto come la peste. Trasformeranno anche il codice contorto in codice intelligente ogni volta che ne avranno la possibilità. Il codice di solito inizia contorto e si avvicina all'intelligenza poiché la conoscenza del dominio e la comprensione delle capacità cognitive umane nella programmazione sono meglio comprese attraverso l'esperienza e la conoscenza condivisa.

A causa della popolarità di questa citazione e del fatto che Brian Kernighan sia piuttosto popolare nel settore, questo uso improprio della parola ha un impatto sociale negativo e sinceramente mi piacerebbe vedere quello affrontato dall'uomo stesso. Prima di scrivere questo articolo ho provato a vedere se potevo semplicemente inviargli un'e-mail, ma non sono riuscito a trovare le informazioni di contatto e-mail che ho capito :(.

L'impatto sociale negativo che ho visto è che altri programmatori stanno ostracizzando i loro colleghi più intelligenti, perché ora vedono l'intelligenza come un problema. Il vero problema sono gli stupidi colleghi che pensano di essere intelligenti facendo le cose in un nuovo modo unidiomatico e inventando costantemente nuove cose quando non c'è vantaggio invece di ottenere e comprendere la comunità più grande e riutilizzare idee intelligenti il ​​più possibile.

Devo chiarire che spesso ottenere una comprensione è più difficile che inventare la tua. A causa del problema comune nell'industria per scadenze non realistiche, inventare il proprio per il problema di nicchia più piccolo verrà utilizzato per risparmiare tempo. Ciò si basa sull'osservazione che le cose utili e riutilizzabili di solito prendono di mira una nicchia più ampia o forniscono un'astrazione utile per l'invenzione. Si basa anche sul fatto che le persone si rivolgono a grandi nicchie per fare più soldi, quando spesso questo rende lo strumento estremamente difficile da usare a causa della complessità implicata nel rendere qualcosa utilizzabile per un'ampia area di applicazioni.

L'altro impatto sociale negativo è che questo impedisce il progresso e il desiderio di comprendere perché nel nostro mondo egocentrico rinunceremo immediatamente alla nostra mancanza di comprensione e cancelleremo il codice di come contorto anche se, una volta compresa, l'idea è effettivamente abbastanza intelligente.

TODO Vorrei citare alcuni riferimenti, ma vorrei anche la mancanza di riferimenti per non ostacolare la mia capacità di condividere informazioni, quindi citerò rapidamente ciò che ricordo come fonte delle mie informazioni e forse troverò le informazioni reali giorno (o puoi trovarlo per me! :)

• Il discorso di Guido Van Rossum sui loop degli eventi e su come è arrivato a capirli
• Un dipendente GitHub che ha dichiarato di evitare di assumere persone intelligenti su Y-Combinator
• Gran parte della discussione e dell'apprendimento che si svolgono nella comunità di Python. La community di Python è particolarmente critica nei confronti delle nuove idee, ma non ignora le nuove idee che non capiscono a portata di mano, e in genere puoi vedere le funzionalità che sono state inizialmente viste come contorte, vedere la luce del giorno come una funzionalità / pacchetto del linguaggio di base.
• La mia esperienza e opinione professionale basata sulle mie osservazioni di 10000 piedi. Non riesco davvero a vedere i dettagli per illuminare da ogni parte lassù :( Spero che la tua esperienza e osservazione ti diranno la stessa cosa e qualcun altro possa commentare di seguito per dare un merito a questa risposta.

Sentiti libero di aggiungere le tue citazioni! Inoltre, sentiti libero di aggiungere virgole al mio testo. Non ho aggiornato la mia conoscenza dell'uso della virgola in inglese da un po 'di tempo ...

Perché spesso le persone non conoscono una lingua, modi di dire e schemi. Potrebbero prendere un libro e impararlo, ma non lo fanno. E a causa di quelle persone dovresti scrivere un codice semplice.

Non è un'intelligenza. È una conoscenza.

Non sono riuscito a trovare la parola disciplina menzionata da nessuna parte qui intorno, quindi inserirò la parola. Non voglio pubblicare la risposta, ma condividere una visione diversa della questione, forse una che la domanda originale non aveva in mente .

Uno sviluppatore intelligente è una buona cosa.

Tuttavia, prima dell'intelligenza arrivano altri tratti. Come avrai capito, parlerò della disciplina . Uno sviluppatore intelligente e indisciplinato può essere molto negativo per la manutenibilità a lungo termine del sistema.

Supponiamo che insorga un bug o che insorgano nuovi requisiti. Uno sviluppatore intelligente potrebbe presto rendersi conto che un paio di correzioni locali porteranno a termine il lavoro in 2 minuti. Se lo sviluppatore è disciplinato, si asterrà dall'applicare quelle correzioni al codice sorgente e troverà invece un modo significativo per comporre il comportamento desiderato nel sistema. In questo modo, la prossima volta che sorgerà la necessità di modificare particolari parti di codice, il manutentore avrà un momento facile per comprendere il codice e implementare le nuove modifiche senza interrompere nulla. Altrimenti, ottieni l'immagine.