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

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

Nel generale no, non lo è.

Una libreria può risparmiare il lavoro (duro!) di capire come risolvere un problema, quindi eseguire il debug della soluzione e quindi mantenerla. Ma, se lo userai, farai meglio a capire come funziona, perché la soluzione risolve il problema. Non devi sapere come inventare macchine, motori e robot che costruiscono motori per auto, se lavori come meccanico - ma è meglio capire come funzionano le parti, cosa fanno e come montare insieme!

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

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

Una volta computerworld.com.au chiesto Bjarne Stroustrup "Hai qualche consiglio per i programmatori emergenti?"
E ha risposto "Conoscere le basi dell'informatica: algoritmi, architetture di macchine, strutture dati, ecc. Non copiare le tecniche solo ciecamente dall'applicazione all'applicazione. Funziona e perché funziona. Non pensare di sapere quale sarà il settore tra cinque anni o cosa farai allora, quindi raccogli un portfolio di competenze generali e utili. Prova a scrivere codice migliore, più basato su principi Lavorare 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 libri di testo più avanzati; non essere soddisfatto con le guide "how to" e la documentazione online facilmente digeribili - è superficiale. "
Spero che chiarisca i tuoi dubbi su ciò che è necessario per un True Programmer e cosa è < strong> Necessario perché chiunque ne sia uno.

Sì - e lo facciamo tutti!

Prendiamo, per esempio, un bug molto semplice che stavo correggendo in alcuni codici grafici relativi a Mac. Il codice attorno all'errore riguardava diversi passaggi:

1. Innanzitutto, un metodo Objective C alloca un buffer di pixel usando malloc () e lo allega al suo oggetto Objective C.
2. Più tardi, 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 dei pixel utilizzando jpeglib e lo invia tramite una connessione TCP / IP.

C'è un sacco di cose 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 sottostante sistema di memoria virtuale del kernel di Darwin 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 dinamico come la RAM fisica contigua e indirizzabile linearmente.
• Sistema di oggetti dell'obiettivo C
• Il sistema di messaggistica runtime Mac OS e il modo in cui interagisce con gli oggetti Objective C
• L'implementazione della libreria jpeglib dello standard di compressione JPEG con perdita di immagini raster, 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 il tuo networking, potrebbe chiamare un driver per la porta Ethernet, un chip wi-fi o più insolitamente un driver USB o Firewire.

Capisci tutti i dettagli di come tutte queste cose sono effettivamente implementate? Io sicuramente no! Dubito che ci siano molte persone sul pianeta che lo fanno - forse nemmeno nessuno. Quindi non me ne preoccupo.

Ma è una cosa buona essere curiosi e imparare almeno un po 'sulle 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ì. Indulgiando la mia curiosità su queste cose, ho imparato moltissimo e finora ho avuto una grande carriera.

Trovo che il motivo principale per cui utilizziamo le librerie è non "reinventare la ruota" tutto il tempo, estrapolando i problemi che intendono risolvere. Potresti provare a risolvere da solo i problemi, ma ciò richiederebbe più tempo.

Tuttavia, sento che dobbiamo anche sapere o indovinare come il problema è risolto dalla biblioteca. Questo è solitamente documentato nella documentazione dell'utente della biblioteca e con il software open source, puoi sempre guardare il codice da solo.

Inoltre di solito risolviamo i problemi estraendo comunque le parti difficili, quindi perché non è ok?

Le librerie sono lì per fornire soluzioni a problemi comuni. Devi decidere se risolvono il problema specifico che stai risolvendo. NON sono un sostituto per non sapere come risolvere un problema. Ad esempio, supponiamo che la tua applicazione richieda una tabella hash, dovresti avere una conoscenza sufficiente per capire quale problema risolve 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 una conoscenza tecnica inadeguata non sia il caso d'uso corretto. La decisione di utilizzare una libreria dovrebbe ruotare attorno all'utilizzo o meno della libreria per accelerare lo sviluppo e fornire una soluzione testata e affidabile. La decisione di utilizzare una libreria non dovrebbe ruotare attorno all'incapacità dei programmatori di risolvere un determinato problema.

Fino a te, davvero .

Quanto meglio capisci gli strumenti con i quali stai lavorando, tanto meglio potrai trarne vantaggio.

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

Inoltre, presto mi avventurerò in gamedev con l'UDK, e sono sicuro che più lo capisco e più sarò in grado di piegarlo alla mia volontà malvagia, ma potrei anche solo seguire tutorial senza cervello . Scelgo il primo, solo un po 'di tempo in più e cicli cerebrali e otterrò risultati migliori e più facili .

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

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

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

Alcuni framework come jQuery si allontanano molto. hai bisogno di sapere come funzionano esattamente? No. Ma avere una strong e fondamentale comprensione di che cosa fa la libreria sarà molto utile per te mentre scrivi il codice perché capirai meglio perché il framework è fatto così com'è, e sii capace usarlo per il suo pieno potenziale.

Sulla base della mia esperienza: dato che non puoi eliminare la dipendenza dalla libreria, tu e il tuo team dovreste sapere 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ù veloce e gentile possibile. Solo questa ragione rende un po 'ridondante "imparare tutto sulle cose".

Le cose che voglio aggiungere qui sono "dipendenza". Come comunità, siamo tutti dipendenti dagli altri. Ci troviamo sui Giants per costruire la nostra applicazione: Java, .NET, API ... E crediamo ai Giants del loro lavoro; perché funziona per così tante persone. Se hai un problema con il framework, o API, ci sono buone possibilità che altri lo affrontino da qualche parte, e c'è una soluzione / funziona.

L'unico problema qui: forse, da qualche parte, in un criterio ristretto i Giants sono crollati. Ad esempio, il flash non è supportato in alcuni sistemi operativi, e ci sono molte cose che non potremmo fare a meno. Questa possibilità è più che 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 il problema è veramente e può creare un grande work-around; ma non sono sicuro che il tempo investito 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 catturare il "funzionamento superficiale" di una libreria, e solo a volte abbiamo davvero bisogno di qualcuno che abbia una comprensione molto buona: lascia che la squadra divida Fai quello. Cercando 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 database, ... Questo aiuterà molto a ridurre i rischi.

Un altro punto di vista è la sicurezza. Quando usi una libreria di cui non conosci esattamente il funzionamento interno, allora fai delle ipotesi su cosa sta succedendo esattamente. Ogni ipotesi fallita può aprire un vettore di attacco per un malintenzionato.

Quando chiami un Quicksort, dovresti essere consapevole del comportamento del caso peggiore. Altrimenti un hacker potrebbe essere in grado di iniettare dati peggiori e di eseguire un DoS.

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

Dovresti conoscere abbastanza basi su ciò che farai, per essere in grado di dimostrare le tue ipotesi. Altrimenti la biblioteca dovrebbe occuparsi esplicitamente di questo, ad es. lanciare un'eccezione quando il buffer di output fornito non è abbastanza grande.

Va bene non capire tutto ciò che usi finché 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é no. Ovviamente sei sempre il benvenuto e incoraggiato a guardare sotto il cofano anche se non devi.

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

È ok ma è pericoloso. Come pratica generale, si dovrebbe sapere di lavorare su ciò che ha sviluppato.

Un po '...

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

Il punto è non lasciarsi abbattere da un mucchio di piccoli dettagli e implementare la tua dannata idea già.

Suppongo, il punto è che non saprai tutto. Seriamente, hai così poco tempo per indagare su tutto, perché ti distrae dal tuo obiettivo principale di creare quella tua idea. A poco a poco, forse, puoi impostare una parte del tempo libero nel fine settimana per leggere un capitolo sull'argomento.

Ma non cercare di capire tutto, a meno che tu non abbia molto tempo libero ... Guarda in questo modo. Il motivo per cui i linguaggi di programmazione ci impediscono di fare codice assembly, la ragione per cui il codice assembly è quello di proteggerci dal fare 1 e 0. Non penso che tu abbia bisogno di conoscere tutti i dettagli del meccanismo che c'è dietro, ma solo conoscerne l'essenza generale. Come un netturbino, so che si occuperà dei miei puntatori / memoria, non mi interessa quale algoritmo magicamente pulito usi, so solo che funziona (per quello di cui ho bisogno) e non fa altro. Forse la truffa ma meh. A meno che tu non sia nel campo in cui devi affrontarlo. Allora non faresti questa domanda comunque perché fa parte del tuo lavoro haha.