Va bene non capire completamente la funzionalità del codice? [duplicare]

L'unico scopo delle astrazioni software è quello di nascondere i dettagli funzionali. Se non fosse per quelle astrazioni, non sarebbe possibile progredire oltre un certo punto dell'informatica, perché i sistemi semplicemente collasserebbero sotto il peso della propria complessità. I cervelli umani possono solo comprendere così tante informazioni contemporaneamente.

Considera cosa succede quando scrivi un metodo. Quando scrivi un metodo, ciò che stai facendo nasconde un po 'di funzionalità del software dietro una chiamata al metodo. Una volta che il metodo è stato scritto e provato a funzionare scrivendo unit test su quel metodo, non devi più pensare a cosa c'è dentro quel metodo a meno che tu non debba modificare qualcosa sulla sua implementazione.

I grandi sistemi software sono costruiti su molti livelli di queste astrazioni. Hai un livello microcodice nel processore, codice macchina, bus dati e indirizzi, compilatori di lingue, orientamento agli oggetti, strutture dati, dominio lingue specifiche e così via. Hai librerie costruite su altre librerie, che a loro volta sono costruite su un sistema operativo. Non capisci bene come funziona nessuna di quelle cose, ma sei comunque in grado di scrivere programmi per computer che fanno qualcosa di utile.

Detto questo ...

Non puoi semplicemente copiare / incollare il codice senza capire come funziona . La persona che cerca di far funzionare il suo programma copiando il codice di incollatura che non capisce si sta preparando a fallire. Devi capire il codice che scrivi. Questo non significa che devi sapere come funziona WCF internamente, ma tu fai devi sapere qual è lo scopo di WCF , come scrivere codice che lo interfaccia correttamente e come il codice che scrivi funzioni di concerto con esso. Molti programmatori di copia / incolla non hanno nemmeno una conoscenza decente del linguaggio di programmazione che stanno copiando / incollando, per non parlare della conoscenza approfondita delle librerie che stanno usando.

Quindi è necessario disporre di alcune competenze decenti, e devi capire il codice che scrivi (o incolla) che chiama WCF. Ma non è necessario avere una conoscenza approfondita di come WCF funziona internamente.

Allo stesso modo, i programmatori che pensano di poter unire insieme un programma collegando casualmente i modelli software non hanno senso. Chiamiamo quei programmatori Cargo Cult .

Penso che la risposta sia contestualizzata.

Una delle tecniche più potenti per gestire la complessità del codice - che è il vero lavoro di un ingegnere del software, nella mia mente - è l'astrazione. Un ingegnere elettronico non deve riprovare le equazioni di Maxwell per sviluppare un nuovo prodotto, e non ho bisogno di sapere nulla di un'auto per poter usare un volante. Entrambe sono importanti astrazioni perché ci permettono di intuire e usare le cose senza comprenderle. Questo a sua volta ci consente di costruire astrazioni più grandi.

Per inciso, perché l'astrazione è così importante penso che a volte sia anche utile applicarla ad altri sviluppatori. Ad esempio, nel mio ufficio a volte uno sviluppatore scrive i test di unità per un blocco di codice prima che il blocco di codice venga scritto da un secondo sviluppatore. Rafforza l'idea di interfacce semplici e astrazioni chiare.

Detto questo, l'astrazione non è una scusa per non capire come funziona il codice quando è importante che tu sappia come funziona . Il codice di refactoring è uno scenario ovvio in cui i dettagli di implementazione sono importanti. Non ho bisogno di sapere come funziona una macchina per guidarla, ma un ingegnere meccanico e un meccanico dovrebbero entrambi capire come funziona una macchina, probabilmente in modi diversi.

Per inciso, una delle mie prime lezioni sul lavoro è stata quella di non toccare mai il codice che non ho veramente capito. Ad esempio, una volta stavo lavorando su una nuova funzionalità e ho notato un'altra riga di codice nel modulo che non aveva senso, quindi l'ho "corretto" e poi rilasciato un bug. Questo mi ha insegnato una lezione abbastanza grande, che è quella di ammettere quando non capisco prontamente un pezzo di codice e di riconoscere che il codice buono, complesso e non banale può essere non ovvio. Sono abbastanza nuovo nello sviluppo di software, ma ho trovato l'idea che "il buon codice è facile da leggere" per essere uno insidioso che nessuno sviluppatore di software che conosca metta in pratica. Certo, non scrivere codice oscuro o cattivo, ma i problemi più complessi richiedono spesso un codice complesso. Non essere arrabbiato se ti ci vuole tempo per capire le cose. La mia frase preferita di Feynman è "Ma non è complicato, ce n'è molto."

Quindi quando ti astraggono e quando fai a pezzi l'orologio svizzero? Suppongo che dipenda da quando stai indossando l'orologio e quando lo stai costruendo. La mia opinione è che le persone migliori in qualsiasi campo siano a forma di T , nel senso che capiscono il loro lavoro in un contesto - qualcosa che si ottiene solo attraverso l'astrazione - ma anche sapere cosa hanno bisogno di sapere profondamente.

Ci sono tre diverse parti per comprendere il software:

1. Per prima cosa comprendo perché esiste un software (grande come un'applicazione o piccolo come una singola funzione). Devi sapere il punto, perché è stato scritto.
2. Quindi penso che comprenda cosa fa un pezzo di codice.
3. Finalmente è sapere in che modo funziona un pezzo di codice, come sono e come funzionano gli interni.

Quale di questi è necessario avere una presa per comprendere un pezzo di software diverso a seconda di cosa devi fare con quel codice.

Ad esempio, prendi il metodo String.ToUpper () di .NET. So cosa fa questo metodo e perché vorresti usarlo, ma non so come è scritto (è un dettaglio di implementazione) e non mi interessa davvero - finché posso usarlo correttamente. Non avrò mai bisogno di modificare questo metodo, quindi la mia comprensione degli interni non è necessaria.

Se dovessi copiare il codice da Internet, ho bisogno di essere completamente sicuro di cosa fa il codice e perché. Se lo stavo copiando e non lo modificavo mai (improbabile), allora non sento alcun bisogno di capire come funziona. Ma se dovessi modificarlo (probabilmente), allora avrò bisogno di sapere come funziona, altrimenti sto solo usando congetture per modificare il codice, e probabilmente non finirà bene.

Non che io non sia d'accordo con le altre risposte, ma lascia che risponda a ciò che leggo tra le righe. Se il tuo capo ti sta informando che non hai bisogno di capire come funziona qualcosa, potrebbe essere un feedback che stai impiegando troppo tempo per fare qualcosa. Alcune persone vengono facilmente distratte da dettagli non importanti e per loro è consigliabile lavorare per rimanere in pista.

D'altra parte, se la programmazione è la professione scelta e hai la curiosità intellettuale di scavare più a fondo in una tecnologia che è importante per quello che fai, allora ti incoraggerei a prendere del tempo extra per seguire i tuoi interessi quando possibile. Le informazioni che ottieni, anche se non immediatamente gratificanti, pagheranno dividendi nel lungo periodo. Ti aiuterà a dare un senso alla tecnologia, ti metterà in grado di estenderla in molti casi e ti preparerà per una comprensione ancora più profonda in futuro. Nel corso del tempo, questo è ciò che distingue un esperto da un utente occasionale.

Nel grande programmatore pragmatico del libro si parla di "programmazione per coincidenza" ( link )

Il problema più grande con questo è, se non sai perché un pezzo di codice funziona quando questo pezzo di codice fallisce per qualsiasi motivo, non sai perché fallisce e non puoi ripararlo.

Non sono completamente d'accordo con la dichiarazione: "Non puoi semplicemente copiare / incollare il codice senza capire come funziona."

Perdona la mia stupidità, ma da un punto di vista programmatico, non è inclusa una libreria di metodi / funzioni che non so che funzionino essenzialmente come copiare / incollare quel codice nel mio?

I., se sto programmando usando jQuery, includo la libreria jQuery e poi la uso. Usando la risposta di Robert Harvey, questo va bene dal momento che jQuery ha astratto tutte le cose che ho bisogno di usare senza dover scrivere il codice da solo o addirittura capirlo completamente. Devo davvero sapere esattamente come funziona jQuery dietro le quinte prima che io possa usarlo?

Detto questo, sono d'accordo con il principio alla base della dichiarazione, ma volevo sottolineare che il concetto di "copiare / incollare" il codice (senza una completa comprensione) è in realtà più comune di quanto si possa pensare e non così oneroso come questo la dichiarazione lo farebbe sembrare.

Come la maggior parte delle volte, tutto dipende. All'estremità estrema, c'è l'uso di una biblioteca. Non dovresti sapere o preoccuparti di come funziona. Dovresti sapere cosa mettere e cosa esce, cosa può e cosa non può fare.

All'altro capo, non sai come eseguire un compito perché non lo hai mai fatto prima. Trovate dieci righe di codice su Internet, il che sembra più facile che trovare le informazioni giuste nella documentazione (e spesso lo è). A quel punto suggerirei caldamente che ora è il momento giusto per imparare come farlo. Quindi prendi il codice, capiscilo, fallo tuo. Renditi conto che un sacco di codice su Internet non è necessariamente scritto dalle persone più intelligenti, quindi potrebbero esserci punti deboli e incomprensioni, quindi imparando ora puoi essere sicuro che il codice funzioni. E nel punto in cui includi quelle dieci linee nel tuo progetto, sono tue responsabilità. Se il codice non funziona, è colpa tua. Quindi devi capirlo, come se lo avessi scritto.

Quindi qual è la differenza per la biblioteca? Non è questa anche la tua responsabilità? Il codice della libreria non lo è. La scelta della libreria e l'uso della libreria è. Se la libreria blocca la tua applicazione dieci volte al giorno, è perché hai scelto una libreria inaffidabile. Non devi capire il codice della libreria, ma devi capire i suoi problemi di affidabilità e agire.

Il comando del tuo capo potrebbe funzionare bene, ma è rischioso. C'è il pericolo che a lungo termine si entrino in problemi più grandi, che potrebbero essere evitati prendendo il tempo per capire le cose in primo luogo. Se questa è una cosa da fare una sola volta, il rischio è relativamente piccolo. Se costruisci un intero sistema software in questo modo, hai una bomba a orologeria sulle tue mani. Quello che non capisci, non hai alcuna speranza di correggere o modificare senza causare bug.

D'altra parte, se disobbedisci al tuo capo, il tuo lavoro potrebbe essere a rischio. Se ti piace il tuo lavoro, quindi, in futuro, prova a risolvere autonomamente i problemi tecnici prima che sia coinvolto. Una volta avevo un capo che faceva confusione ogni volta che veniva coinvolto in decisioni tecniche (sebbene fosse stellare nelle vendite e nelle relazioni con i clienti). La maggior parte dello staff tecnico ha imparato ad ascoltare ciò che avrebbe detto, quindi si è girato e ha fatto qualcosa di diverso. Finché il software ha funzionato, non avrebbe mai seguito e verificato se i suoi consigli tecnici fossero effettivamente implementati. Il lavoro ha pagato bene, ma sono contento di non esserci più.

Se questo atteggiamento è pervasivo sul posto di lavoro, prenderei in considerazione almeno altre opzioni di lavoro.