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

16

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?

Kabumbus
la source
Ils ne résolvent pas les problèmes des individus, ils sont juste une solution aux problèmes communs dans les domaines connexes.
Abimaran Kugathasan
alors est-ce OK de ne pas savoir comment résoudre les problèmes communs dans le domaine connexe et de dire "utilisez simplement *** (votre bibliothèque préférée ici)" cela éviterait-il de voir comment ils l'ont fait?
Kabumbus
1
Avez-vous déjà programmé des programmes évolutifs? Honnêtement, aucune bibliothèque n'est parfaite à 100% du temps, et des bugs sont susceptibles de se produire. Maintenant, si ce bogue se trouve dans l'une des nombreuses bibliothèques externes que vous utilisez, et 2 ans plus tard dans le cycle de développement, vous commencez à rencontrer des problèmes, et que savez-vous? C'est l'une de ces bibliothèques que vous utilisez! Donc, pour être franc: non, cela n'a aucun sens d'utiliser des bibliothèques comme solution miracle (du moins pas pour les logiciels de niveau entreprise, etc.) car elles deviennent un peu une limitation à mesure que vous progressez.
jerluc
5
@jerluc: les bibliothèques standard sont souvent bien mieux développées et prises en charge que le code de n'importe quelle organisation. Par exemple, le shared_ptr de boost est considéré comme un "must have" par tout le monde dans l'industrie avec lequel j'ai été en contact et divers autres morceaux de code fournis par boost ont permis au projet sur lequel je travaille de se concentrer sur les détails du problème et non passer du temps à travailler sur des choses moins importantes qui ont déjà été faites. Vous pouvez rencontrer des problèmes en fin de compte, vous devez donc être sélectif des bibliothèques que vous choisissez, mais généralement elles sont bonnes. Le syndrome "non développé ici" est cependant mauvais.
TZHX
@TZHX Je suppose que je devrais être plus catégorique en disant que ce que j'ai déclaré s'applique principalement aux bibliothèques qui peuvent faire des choses comme emballer ce qui pourrait être considéré comme du code "chaudière". Il est logique de faire confiance à la "roue inventée" en n'écrivant pas les wrappers IO (lorsque des bibliothèques sont disponibles pour de tels wrappers), mais cela n'a pas de sens de faire confiance à une "roue quelque peu ronde", ou en d'autres termes, une bibliothèque qui ne une sorte de magie de boîte noire et fonctionne pour ce dont vous avez besoin à ce moment-là.
jerluc

Réponses:

22

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.

blueberryfields
la source
13

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.

Ranger
la source
4
+1 - Je pense qu'il est important de noter que - même si je suis à 100% d'accord avec Stroustrup - le PO ne devrait pas avoir l'idée que cela signifie qu'il devrait réinventer la roue sur chaque chose qu'il fait. La principale raison pour laquelle l'enseignement de l'informatique implique la mise en œuvre de la classe String et de MergeSort et d'autres algorithmes est que lorsque nous utilisons les bibliothèques disponibles dans la langue de notre choix, nous comprendrons ce qui se passe sous le capot. Traitez suffisamment de bibliothèques avec une bonne compréhension des fondations, et on peut à peu près prédire ce qui se trouve sous le capot de la bibliothèque X, Y ou Z.
jmort253
Venant de l'homme qui a besoin de plusieurs dizaines de paragraphes pour analyser en profondeur, justifier et expliquer pourquoi la marque et la saveur particulières du thé ont piqué son intérêt, tout en renonçant complètement au point de la question initiale. MAIS, je l' aime toujours !
Filip Dupanović
1
Franchement, je connais beaucoup de choses sur les algorithmes, les architectures de machines, les structures de données et bien d'autres choses. Cela ne signifie pas que je comprends précisément ce que chacune de nos bibliothèques tierces fait précisément, ni même toute la théorie qui la sous-tend. Je pense que ce sont tous de bons conseils, mais cela ne signifie pas que vous devez tout savoir sur votre application.
David Thornley
12

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.

Bob Murphy
la source
1
Si je devais comprendre tout le code que j'utilise régulièrement, je devrais comprendre la compression des données, y compris les JPEG, la représentation des données géométriques, y compris tout dans <i> The Nurbs Book </i>, les subtilités des formats PDF et U3D, et beaucoup plus. J'ai des références sur tout, mais je n'aurai jamais tout ça.
David Thornley
Je dois admettre que je ne comprends pas toujours en détail tous les blocs de construction que j'utilise pour écrire du code de travail, mais je ne suis pas satisfait lorsque cela se produit. Comprendre, ou du moins savoir que si je le dois, je peux comprendre les composants de base, rend la vie beaucoup plus facile. Je suis content de savoir comment fonctionne un allocateur, quels principes sont utilisés pour compresser une image JPEG, comment TCP / IP fonctionne, comment la mémoire virtuelle peut être implémentée, comment un CPU fait son travail, etc. c'est bien, mais ne pas avoir accès aux détails est vraiment mauvais ...
Pierre Arnaud
5

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?

Spoike
la source
5

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

Pemdas
la source
Cela signifierait que, pour mon projet actuel, je devrais connaître les détails des spécifications PDF et U3D. Pour un certain projet d'école d'études supérieures, j'aurais dû en savoir beaucoup sur certains algorithmes de programmation linéaire (simplex aurait été sans espoir pour mon cas). S'il était nécessaire de comprendre exactement ce que fait une bibliothèque pour l'utiliser, je ne ferais jamais rien.
David Thornley
Je ne prétends pas que vous devez comprendre tous les détails de la mise en œuvre. Mais il faut savoir à quoi s'attendre du résultat. Reprenons l'exemple de la table de hachage. Si vous constatez de mauvaises performances, comment commencer à évaluer la raison. La première chose à laquelle je commencerais à penser est le taux de collision entre mes clés. Si vous ne savez pas comment quelque chose fonctionne, comment pouvez-vous même commencer à émettre des hypothèses sur les raisons pour lesquelles quelque chose ne fonctionne pas ou ne fonctionne pas comme prévu?
Pemdas
5

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

dukeofgaming
la source
5

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

GrandmasterB
la source
2

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.

Hoàng Long
la source
2

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.

Sécurise
la source
1
L'allocation de tampons de taille fixe pour quoi que ce soit est un débordement de tampon en attente de se produire. Il est préférable d'utiliser un langage qui prend en charge les tableaux dynamiques et de laisser l'appelé gérer ses propres tampons.
Mason Wheeler
1

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.

Kamil Szot
la source
1

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

Rachel
la source
1

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.

programmeur mythique
la source