Est-il OK de vivre sans savoir comment fonctionne le programme que vous avez créé?

Je veux dire, il y a des bibliothèques vraiment utiles qui peuvent résoudre des problèmes lorsque vous êtes coincé et ne savez pas comment résoudre ceci ou cela avec votre connaissance du langage de programmation que vous utilisez ... Par exemple, Boost pour C ++ ou JQuery pour JavaScript ou Spring pour Java ... Ils résolvent les problèmes en quelques secondes et vous ne vous souciez pas vraiment de la façon dont ils l'ont fait (malgré le fait qu'ils soient écrits dans le même langage que vous programmez) ... Je me demande donc si je suis seul à utiliser des bibliothèques sans être capable d'écrire des solutions à mes problèmes à partir de zéro ou est-ce une pratique courante?

Est-il acceptable de ne pas comprendre comment résoudre les problèmes vous-même et d'utiliser des bibliothèques à la place?

En général, non, ce n'est pas le cas.

Une bibliothèque peut vous épargner le travail (difficile!) De trouver un moyen de résoudre un problème, puis de déboguer la solution, puis de la maintenir. Mais, si vous allez l'utiliser, vous feriez mieux de vous assurer de comprendre comment cela fonctionne - pourquoi la solution résout réellement le problème. Vous n'avez pas besoin de savoir comment inventer des voitures, des moteurs et des robots qui construisent des moteurs de voiture, si vous travaillez en tant que mécanicien - mais vous feriez mieux de comprendre comment les pièces fonctionnent, ce qu'elles font toutes et comment elles emboîter!

C'est la raison pour laquelle vous verrez de nombreuses personnes devenir très spécialisées - apprenant souvent à travailler avec une seule langue, une seule plate-forme, un seul cadre et un ensemble de bibliothèques.

Cela étant dit, vous n'aurez que peu de temps pour apprendre. Parfois, vous devez prendre des raccourcis - prenez-les, mais sachez que ce sont des raccourcis. Peut-être que vous ne lisez assez sur une bibliothèque que pour savoir si vous en avez le temps. Ou peut-être que vous ne comprenez que les deux fonctions que vous devez réellement appeler, et juste assez pour effectuer les appels correctement. C'est un raccourci, qui aura un prix - généralement plus tard, quand quelqu'un (peut-être un plus âgé et plus expérimenté, vous) doit corriger le code.

Une fois computerworld.com.au a demandé à Bjarne Stroustrup "Avez-vous des conseils pour les programmeurs en devenir?"
Et il a répondu"Connaissez les bases de l'informatique: algorithmes, architectures de machines, structures de données, etc. Ne copiez pas simplement des techniques d'une application à une autre. Sachez ce que vous faites, que cela fonctionne et pourquoi cela fonctionne. Ne pensez pas que vous savoir ce que l'industrie sera dans cinq ans ou ce que vous ferez alors, alors rassemblez un portefeuille de compétences générales et utiles. Essayez d'écrire un code meilleur et plus fondé sur des principes. Travaillez à faire de la "programmation" davantage une activité professionnelle et moins d'une activité de "piratage" de bas niveau (la programmation est aussi un métier, mais pas seulement un métier). Apprenez des classiques dans le domaine et des manuels les plus avancés; ne vous contentez pas du "comment" facilement digéré guides et documentation en ligne - c'est superficiel. "
J'espère que cela clarifiera vos doutes sur ce qui est requis pour unVéritable programmeur et ce qui est nécessaire pour que quiconque en soit un.

Oui - et nous le faisons tous!

Prenons, par exemple, un bogue très simple que je corrigeais dans du code graphique lié à Mac. Le code autour du bogue a impliqué plusieurs étapes:

1. Tout d'abord, une méthode Objective C alloue un tampon de pixels à l'aide de malloc () et l'attache à son objet Objective C.
2. Plus tard, quelque chose se produit et une routine C envoie un message à l'objet Objective C et récupère le tampon de pixels.
3. La routine C compresse le contenu du tampon de pixels à l'aide de jpeglib et l'envoie via une connexion TCP / IP.

Il se passe énormément de choses là-bas! Voici quelques éléments:

• Un allocateur de mémoire dynamique pour implémenter malloc (), qui suppose que la mémoire est physiquement contiguë et adressable linéairement.
• Le système de mémoire virtuelle du noyau Darwin sous-jacent pour mapper à la fois la RAM physique fragmentée et l'espace disque (qui est un périphérique physique différent de la RAM), en quelque chose qui apparaît à l'allocateur de mémoire dynamique comme s'il s'agissait d'une RAM physiquement contiguë et adressable linéairement.
• Système d'objet d'Objectif C
• Le système de messagerie d'exécution Mac OS et la façon dont il interagit avec les objets Objective C
• L'implémentation par la bibliothèque jpeglib de la norme de compression d'image raster avec perte JPEG, qui utilise un algorithme de transformation en cosinus discret
• La routine de mise en réseau de l'espace utilisateur pour l'envoi des données, qui appelle à travers les différentes implémentations des protocoles TCP et IP, qui à son tour appelle le noyau du système d'exploitation. Ensuite, selon ce que vous avez activé pour votre réseau, il peut appeler un pilote pour le port Ethernet, une puce Wi-Fi ou, plus inhabituellement, un pilote USB ou Firewire.

Comprenez-vous tous les détails de la façon dont toutes ces choses sont réellement mises en œuvre? Bien sûr que non! Je doute qu'il y ait beaucoup de gens sur la planète qui le fassent - peut-être même aucun. Je ne m'en inquiète donc pas.

Mais c'est une bonne chose d'être curieux et d'en apprendre au moins un peu sur les bibliothèques et les outils que vous utilisez. Quand j'ai commencé la programmation, je savais que les compilateurs et les systèmes d'exploitation ne pouvaient pas être magiques, mais ils me semblaient certainement de cette façon. En livrant ma curiosité à ces choses, j'ai beaucoup appris et j'ai eu une belle carrière jusqu'à présent.

Je trouve que la principale raison pour laquelle nous utilisons des bibliothèques est de ne pas "réinventer la roue" tout le temps, en faisant abstraction des problèmes qu'elles ont l'intention de résoudre. Vous pourriez essayer de résoudre les problèmes vous-même, mais cela prendrait plus de temps.

Cependant, je pense que nous devons également savoir ou deviner comment le problème est résolu par la bibliothèque. Ceci est généralement documenté dans la documentation utilisateur de la bibliothèque et avec un logiciel open source, vous pouvez toujours consulter le code vous-même.

De plus, nous résolvons généralement les problèmes en résumant les parties difficiles de toute façon, alors pourquoi ça ne va pas?

Les bibliothèques sont là pour apporter des solutions aux problèmes courants. Vous devez décider s'ils résolvent le problème particulier que vous résolvez. Ils NE SONT PAS un substitut pour ne pas savoir comment résoudre un problème. Par exemple, supposons que votre application nécessite une table de hachage, vous devez avoir suffisamment de connaissances pour comprendre le problème qu'une table de hachage résout. Vous devriez être en mesure d'évaluer les performances de la bibliothèque que vous utilisez pour décider si elle fonctionnera ou non dans votre application. Je crois que l'utilisation d'une bibliothèque pour couvrir des connaissances techniques inadéquates n'est pas le bon cas d'utilisation. La décision d'utiliser une bibliothèque devrait tourner autour de savoir si l'utilisation de la bibliothèque accélérera ou non le développement et fournira une solution testée et fiable. La décision d'utiliser une bibliothèque ne doit pas tourner autour de l'incapacité des programmeurs à résoudre un problème donné.

À vous, vraiment .

Mieux vous comprenez les outils avec lesquels vous travaillez, mieux vous pouvez en profiter.

Par exemple, j'utilise rarement jQuery, mais quand je le dois, je sais quoi en tirer parti et comment le faire coexister avec d'autres frameworks comme Mootools.

De plus, je vais bientôt m'aventurer dans gamedev avec UDK, et je suis sûr que plus j'en comprendrai plus je pourrai le plier à ma mauvaise volonté, mais je pourrais aussi simplement suivre des didacticiels simples. Je choisis le premier, juste un peu de temps et de cycles cérébraux supplémentaires et j'obtiendrai des résultats meilleurs et plus faciles .

Il est important de connaître votre domaine et votre partie du processus.

Par exemple, supposons que vous utilisez une bibliothèque de traitement d'images. Avez-vous vraiment besoin de tout savoir sur les flous gaussiens, les transformations et les espaces colorimétriques? Non. Mais vous devez d'abord savoir pourquoi vous utilisez la bibliothèque. Ou la fonction de tri d'un framework. Avez-vous besoin de connaître l'algorithme de tri réel utilisé? Dans la plupart des cas, non. Mais vous devez savoir pourquoi vous avez besoin de trier les données.

D'un autre côté, si vous écrivez un compilateur, vous savez bien mieux comment fonctionne un compilateur, car c'est votre rôle dans le processus.

Certains frameworks comme jQuery résument beaucoup. Avez-vous besoin de savoir exactement comment ils fonctionnent? Non. Mais avoir une compréhension solide et fondamentale de ce que fait la bibliothèque vous sera très bénéfique lorsque vous rédigerez du code, car vous comprendrez mieux pourquoi le cadre est conçu tel quel et vous pourrez l'utiliser à son plein potentiel. .

D'après mon expérience: comme vous ne pouvez pas éliminer la dépendance à la bibliothèque, vous et votre équipe devez en savoir suffisamment pour résoudre le problème.

En tant que programmeurs, nous avons peu de temps, nous devons donc choisir celui qui a la plus haute priorité. Le problème doit être résolu le plus rapidement et le plus doucement possible. Seule cette raison rend "tout apprendre sur les choses" quelque peu redondant.

Ce que je veux ajouter ici, c'est la "dépendance". En tant que communauté, nous dépendons tous des autres. Nous nous appuyons sur les Giants pour construire notre application: Java, .NET, API ... Et nous faisons confiance aux Giants pour leur travail; parce que ça marche pour tant de gens. Si vous avez un problème avec le framework ou l'API, il y a de fortes chances que d'autres y soient confrontés quelque part, et il existe une solution / solution.

Le seul problème ici: peut-être, quelque part, dans un critère restreint, les Giants se sont effondrés. Par exemple, le flash n'est pas pris en charge dans certains systèmes d'exploitation, et il y a beaucoup de choses que nous ne pourrions pas faire sans. Cette possibilité est plus que nulle, mais dans ce cas, nous avons peu de choses que nous pouvons faire. Ce n'est que dans ces cas que la connaissance de «ce qui se cache derrière les hottes» s'avère utile, car elle indique où se situe réellement le problème et peut créer un grand contournement; mais je ne suis pas sûr que le temps que nous investissons en vaille vraiment la peine.

Pour faire face à cette possibilité, je pense qu'il y a une solution: parce que la plupart des programmeurs peuvent facilement saisir le "travail de surface" d'une bibliothèque, et seulement parfois nous avons vraiment besoin de quelqu'un qui est très compréhensif: laissez diviser l'équipe pour le faire. Essayer de comprendre une équipe que chacun a expertisée sur 1,2 bibliothèques / outils / "compétences" utiles qui impliquaient : on a une bonne expérience de jQuery, on est spécialisé avec la base de données, ... Cela aidera beaucoup à minimiser les risques.

Un autre point de vue est la sécurité. Lorsque vous utilisez une bibliothèque dont vous ne connaissez pas le fonctionnement interne exact, vous faites des hypothèses sur ce qui se passe exactement. Chaque hypothèse ayant échoué peut ouvrir un vecteur d'attaque pour un attaquant malveillant.

Lorsque vous appelez un Quicksort, vous devez être conscient du comportement le plus défavorable. Sinon, un attaquant pourrait être en mesure d'injecter les données les plus défavorables et d'effectuer un DoS.

Lorsque vous appelez une bibliothèque de compression, vous devez savoir que lorsque certaines données sont compressées sur moins d'octets, il doit y avoir des données qui "compressent" sur plus d'octets que l'original. Ainsi, lorsque vous supposez que le tampon de sortie n'a besoin que de la taille des données d'entrée car il compresse [à moins d'octets], il y a alors un dépassement de tampon en attente.

Vous devriez connaître suffisamment de principes fondamentaux sur les choses que vous allez faire pour pouvoir prouver vos hypothèses. Sinon, la bibliothèque devrait explicitement prendre soin de cela, par exemple en lançant une exception lorsque le tampon de sortie fourni n'est pas assez grand.

C'est OK de ne pas comprendre tout ce que vous utilisez tant que vous êtes sûr que cela fonctionne. Une fois que vous êtes mordu par un bogue dans la bibliothèque, il est temps de voir comment cela fonctionne, pourquoi cela fonctionne et pourquoi il ne fonctionne pas. Bien sûr, vous êtes toujours le bienvenu et encouragé à regarder sous le capot même si vous n'y êtes pas obligé.

L'une des difficultés de la programmation est de surmonter la tentation de résoudre vous-même tous les problèmes.

C'est bon mais c'est dangereux. En pratique générale, il faut savoir travailler sur ce qu'il a développé.

Un peu ...

C'est bien aussi longtemps que vous obtenez l'essentiel de ce que la bibliothèque ou le framework essaie de faire. En ce qui concerne les parties internes et ce qui ne l'est pas alors, non. Adoptez une approche pragmatique. Ça marche, ça fait ce que je veux, d'accord.

Le but est de ne pas se laisser bousculer par un tas de petits détails et de simplement mettre en œuvre votre putain d'idée déjà.

Je suppose que le fait est que vous ne saurez pas tout. Sérieusement, vous avez si peu de temps pour tout enquêter, car cela vous distraira de votre objectif principal de créer cette idée. Peu à peu, peut-être, vous pouvez vous réserver du temps libre le week-end pour lire un chapitre ou plus sur le sujet.

Mais n'essayez pas de tout comprendre, sauf si vous avez beaucoup de temps libre ... Regardez-le de cette façon. La raison pour laquelle les langages de programmation sont le bouclier nous empêche de faire du code assembleur, la raison du code assembleur est de nous protéger contre les 1 et les 0. Je ne pense pas que vous ayez besoin de connaître tous les détails du mécanisme sous-jacent, mais connaissez simplement l'essentiel. Comme un garbage collector, je sais qu'il va gérer mes pointeurs / mémoire, je me fiche de l'algorithme magique qu'il utilise, je sais juste que cela fonctionne (pour ce dont j'ai besoin) et qu'il ne fait rien d'autre. Peut-être le con, mais meh. À moins bien sûr que vous ne soyez sur le terrain où vous devez vous en occuper. Alors vous ne poseriez pas cette question de toute façon car cela fait partie de votre travail haha.