Va bene vivere senza sapere come funziona il programma che hai creato?

Voglio dire, ci sono librerie davvero utili che possono risolvere problemi quando sei bloccato e non sai come risolvere questo o quello con la tua conoscenza del linguaggio di programmazione che usi ... Ad esempio, Boost per C ++ o JQuery per JavaScript o Spring for Java ... Risolvono i problemi in pochi secondi e non ti interessa davvero come l'hanno fatto (nonostante siano scritti nella stessa lingua in cui stai programmando) ... Quindi mi chiedo se sono solo nell'usare le librerie senza essere in grado di scrivere da zero soluzioni ai miei problemi o è pratica standard?

Va bene non capire come risolvere i problemi da soli e utilizzare invece le librerie?

In generale, no, non lo è.

Una libreria può salvarti il ​​lavoro (difficile!) Di capire come risolvere un problema, quindi eseguire il debug della soluzione e quindi mantenerla. Ma, se hai intenzione di usarlo, è meglio assicurarsi di capire come funziona - perché la soluzione risolve effettivamente il problema. Non devi sapere come inventare auto, motori e robot che costruiscono motori per auto, se lavori come meccanico - ma faresti meglio a capire come funzionano i pezzi, cosa fanno tutti e come stanno bene insieme!

Questo è il motivo per cui vedrai molte persone diventare molto specializzate - molte volte imparando solo a lavorare con una sola lingua, una singola piattaforma, un singolo framework e un insieme di librerie.

Detto questo, c'è solo così tanto che avrai tempo per imparare. A volte devi prendere scorciatoie: prendile, ma sappi che sono scorciatoie. Forse hai letto abbastanza su una biblioteca per sapere che potresti capirlo, se ne avessi il tempo. O forse capisci solo le due funzioni che devi effettivamente chiamare e abbastanza per effettuare correttamente le chiamate. Questa è una scorciatoia, che avrà un prezzo - di solito più tardi, quando qualcuno (forse un vecchio, e più esperto, tu) deve riparare il codice.

Una volta computerworld.com.au ha chiesto a Bjarne Stroustrup "Hai qualche consiglio per i programmatori emergenti?"
E lui rispose"Conoscere le basi dell'informatica: algoritmi, architetture di macchine, strutture dati, ecc. Non limitarti a copiare alla cieca tecniche da un'applicazione all'altra. Sai cosa stai facendo, che funziona e perché funziona. Non pensare che tu sapere quale sarà il settore tra cinque anni o cosa farai allora, quindi raccogli un portfolio di competenze generali e utili. Cerca di scrivere codice migliore e più basato sui principi. Lavora per rendere la "programmazione" più di un'attività professionale e meno di un'attività di "hacking" di basso livello (la programmazione è anche un mestiere, ma non solo un mestiere). Impara dai classici sul campo e dai migliori libri di testo avanzati; non essere soddisfatto del "come" digerito facilmente guide e documentazione online: è superficiale ".
Spero che chiarirà i tuoi dubbi su ciò che è necessario per unVero programmatore e ciò che è necessario per chiunque sia uno.

Sì, e lo facciamo tutti!

Prendiamo, ad esempio, un bug molto semplice che stavo risolvendo in alcuni codici grafici relativi al Mac. Il codice attorno al bug comportava diversi passaggi:

1. Innanzitutto, un metodo Obiettivo C alloca un buffer di pixel usando malloc () e lo collega al suo oggetto Obiettivo C.
2. Successivamente, succede qualcosa e una routine C invia un messaggio all'oggetto Objective C e recupera il buffer dei pixel.
3. La routine C comprime il contenuto del buffer di pixel usando jpeglib e lo invia tramite una connessione TCP / IP.

C'è molto da fare lì! Ecco alcune cose:

• Un allocatore di memoria dinamica per implementare malloc (), che presuppone che la memoria sia fisicamente contigua e indirizzabile linearmente.
• Il sistema di memoria virtuale del kernel Darwin sottostante per mappare sia la RAM fisica frammentata, sia lo spazio su disco (che è un dispositivo fisico diverso dalla RAM), in qualcosa che appare all'allocatore di memoria dinamica come se fosse RAM fisicamente contigua e indirizzabile in modo lineare.
• Sistema di oggetti dell'obiettivo C.
• Il sistema di messaggistica di runtime di Mac OS e il modo in cui interagisce con gli oggetti Obiettivo C.
• L'implementazione della libreria jpeglib dello standard di compressione delle immagini raster lossy JPEG, che utilizza un algoritmo di trasformazione del coseno discreto
• La routine di networking dello spazio utente per l'invio dei dati, che chiama attraverso le varie implementazioni del protocollo TCP e IP, che a sua volta chiama nel kernel del sistema operativo. Quindi, a seconda di ciò che hai attivato per la tua rete, potrebbe chiamare un driver per la porta Ethernet, un chip Wi-Fi o più insolitamente un driver USB o Firewire.

Comprendi tutti i dettagli di come tutte queste cose sono effettivamente implementate? Di sicuro no! Dubito che ci siano moltissime persone sul pianeta che lo fanno - forse nemmeno nessuna. Quindi non me ne preoccupo.

Ma è una buona cosa essere curiosi e conoscere almeno un po 'le librerie e gli strumenti che usi. Quando ho iniziato a programmare, sapevo che i compilatori e i sistemi operativi non potevano essere magici, ma sicuramente mi sembravano così. Concedendo la mia curiosità per quelle cose, ho imparato moltissimo e finora ho avuto una grande carriera.

Trovo che la ragione principale per cui usiamo le biblioteche sia quella di non "reinventare la ruota" continuamente, astraggendo i problemi che intendono risolvere. Potresti provare a risolvere i problemi da solo, ma ciò richiederebbe più tempo.

Tuttavia, ritengo che dobbiamo anche sapere o indovinare come il problema viene risolto dalla biblioteca. Questo di solito è documentato nella documentazione per l'utente della biblioteca e con il software open source, puoi sempre guardare tu stesso il codice.

Inoltre di solito risolviamo i problemi astrattando comunque le parti difficili, quindi perché non va bene?

Le librerie sono lì per fornire soluzioni ai problemi più comuni. Devi decidere se risolvono il problema particolare che stai risolvendo. NON sono un sostituto per non sapere come risolvere un problema. Ad esempio, supponendo che l'applicazione richieda una tabella hash, è necessario disporre di conoscenze sufficienti per comprendere quale problema sta risolvendo una tabella hash. Dovresti essere in grado di valutare le prestazioni della libreria che stai utilizzando per decidere se funzionerà o meno nella tua applicazione. Credo che l'uso di una biblioteca per coprire conoscenze tecniche inadeguate non sia il caso d'uso corretto. La decisione di utilizzare una libreria dovrebbe riguardare se l'utilizzo della libreria accelererà o meno lo sviluppo e fornirà una soluzione testata e affidabile. La decisione di utilizzare una libreria non dovrebbe riguardare l'incapacità dei programmatori di risolvere un determinato problema.

Dipende da te, davvero .

Meglio capisci gli strumenti con cui stai lavorando e meglio puoi sfruttarli.

Ad esempio, uso raramente jQuery, ma quando devo sapere cosa trarne vantaggio e come posso farlo coesistere con altri framework come Mootools.

Inoltre, presto avrò un'avventura in Gamedev con UDK, e sono sicuro che più capisco al riguardo, più sarò in grado di piegarlo alla mia volontà malvagia, ma potrei anche solo seguire tutorial senza sforzo. Scelgo il primo, solo un po 'di tempo extra e cicli cerebrali e otterrò risultati migliori e più facili .

È importante conoscere il tuo regno e la tua parte del processo.

Ad esempio, supponiamo di utilizzare una libreria di elaborazione delle immagini. Hai davvero bisogno di sapere tutto su sfocature gaussiane, trasformazioni e spazi colore? No. Ma devi prima sapere perché stai usando la libreria. O una funzione di ordinamento di un framework. Devi conoscere l'algoritmo di ordinamento utilizzato? Nella maggior parte dei casi, no. Ma devi sapere perché hai bisogno dei dati ordinati.

D'altra parte, se stai scrivendo un compilatore, sai benissimo come funziona un compilatore, dal momento che è la tua parte nel processo.

Alcuni framework come jQuery si allontanano molto. Avete bisogno di sapere esattamente come stanno lavorando? No. Ma avere una conoscenza forte e fondamentale di ciò che la libreria sta facendo ti sarà molto utile mentre scrivi il codice perché capirai meglio perché il framework è fatto così e sarai in grado di usarlo al massimo delle sue potenzialità .

In base alla mia esperienza: poiché non è possibile eliminare la dipendenza dalla libreria, tu e il tuo team dovreste conoscere abbastanza per risolvere il problema.

Come programmatori, abbiamo poco tempo, quindi dobbiamo scegliere quello che ha la massima priorità. Il problema deve essere risolto, il più rapidamente e delicatamente possibile. Solo questa ragione rende "apprendere tutto sulle cose" in qualche modo ridondante.

Le cose che voglio aggiungere qui sono "dipendenza". Come comunità, siamo tutti dipendenti dagli altri. Siamo in piedi sui Giganti per costruire la nostra applicazione: Java, .NET, API ... E ci fidiamo dei Giganti per il loro lavoro; perché funziona per così tante persone. Se hai un problema con il framework o API, ci sono buone probabilità che altri lo abbiano affrontato da qualche parte, e c'è una soluzione / soluzione.

L'unico problema qui: forse, da qualche parte, in un criterio ristretto i Giganti sono crollati. Ad esempio, il flash non è supportato in alcuni sistemi operativi e ci sono molte cose che non possiamo farne a meno. Questa possibilità è più di zero, ma in questo caso abbiamo piccole cose che possiamo fare. Solo in questi casi, la conoscenza di "cosa c'è dietro le cappe" si rivela utile, in quanto indica dove si trova veramente il problema e può creare un grosso problema; ma non sono sicuro che ne valga davvero la pena.

Per far fronte a questa possibilità, penso che ci sia una soluzione: perché la maggior parte dei programmatori può facilmente cogliere il "lavoro di superficie" di una biblioteca, e solo a volte abbiamo davvero bisogno di qualcuno che sia molto ben compreso: lasciamo dividere il team per farlo. Cercare di comprendere un team che ognuno ha sperimentato circa 1,2 utili librerie / strumenti / "set di abilità" che ha coinvolto : uno ha una buona esperienza su jQuery, uno si è specializzato con il database, ... Ciò aiuterà molto a minimizzare i rischi.

Un altro punto di vista è la sicurezza. Quando usi una libreria di cui non conosci i meccanismi interni esatti, fai delle ipotesi su cosa sta succedendo esattamente. Ogni ipotesi non riuscita può aprire un vettore di attacco per un malintenzionato malintenzionato.

Quando chiami un Quicksort, dovresti essere consapevole del comportamento peggiore. Altrimenti, un utente malintenzionato potrebbe essere in grado di immettere dati nel caso peggiore ed eseguire un DoS.

Quando si chiama una libreria di compressione, è necessario tenere presente che quando alcuni dati vengono compressi in meno byte, devono essere presenti dati che "comprimono" in più byte rispetto all'originale. Pertanto, quando si presuppone che il buffer di output abbia bisogno solo della dimensione dei dati di input perché comprime [in meno byte], è presente un overflow del buffer in attesa di verificarsi.

Dovresti conoscere abbastanza concetti fondamentali sulle cose che farai, per essere in grado di dimostrare che le tue assunzioni sono vere. In caso contrario, la libreria dovrebbe occuparsene esplicitamente, ad esempio generando un'eccezione quando il buffer di output fornito non è abbastanza grande.

Va bene non capire tutto quello che usi fintanto che sei sicuro che funzioni. Una volta che sei stato morso da un bug nella libreria, allora c'è tempo per vedere come funziona, perché funziona e perché non funziona. Ovviamente sei sempre il benvenuto e l'incoraggiamento a guardare sotto il cofano, anche se non è necessario.

Una delle cose difficili della programmazione è superare la tentazione di risolvere tutti i problemi da soli.

Va bene ma è pericoloso. Come pratica generale, si dovrebbe sapere come funziona ciò che ha sviluppato.

Tipo...

Va bene finché si ottiene l'essenza generale di ciò che la libreria o il framework sta cercando di fare. Per quanto riguarda le parti interne e cosa no, no. Prendi l'approccio pragmatico. Funziona, ha fatto quello che voglio che faccia, va bene.

Il punto è non impantanarsi con un mucchio di piccoli dettagli e implementare già la tua maledetta idea.

Immagino che il punto sia che non saprai tutto. Seriamente, hai così poco tempo per indagare su tutto, perché ti distoglierà dal tuo obiettivo principale di creare quell'idea. A poco a poco, forse, puoi dedicare un po 'di tempo libero nel fine settimana per leggere un capitolo o giù di lì sull'argomento.

Ma non cercare di capire tutto, a meno che tu non abbia molto tempo libero ... Guardalo in questo modo. Il motivo dei linguaggi di programmazione è che ci impedisce di fare il codice assembly, il motivo del codice assembly è quello di proteggerci dal fare 1 e 0. Non penso che tu abbia bisogno di conoscere tutti i dettagli del meccanismo che sta dietro, ma solo di conoscerne l'essenza generale. Come un garbage collector, so che avrà a che fare con i miei puntatori / memoria, non mi interessa quale algoritmo magicamente pulito utilizzi, so solo che funziona (per quello che mi serve) e non fa altro. Forse il trucco ma meh. A meno che, naturalmente, tu non sia nel campo in cui devi affrontarlo. Quindi non faresti questa domanda comunque perché fa parte del tuo lavoro ahah.