Développer des connaissances approfondies en programmation

136

De temps en temps, je vois des questions sur les cas extrêmes et d'autres problèmes étranges liés à Stack Overflow auxquelles Jon Skeet et Eric Lippert répondent facilement, démontrant ainsi une connaissance approfondie de la langue et de ses nombreuses subtilités, comme celle-ci:

Vous pourriez penser que pour utiliser une foreachboucle, la collection sur laquelle vous effectuez une itération doit être implémentée IEnumerableou IEnumerable<T>. Mais il s'avère que ce n'est pas une exigence. Ce qui est requis, c’est que le type de la collection ait une méthode publique appelée GetEnumerator, qui doit renvoyer un type comportant un getter de propriété publique appelé Currentet une méthode publique MoveNextrenvoyant a bool. Si le compilateur peut déterminer que toutes ces exigences sont remplies, le code est généré pour utiliser ces méthodes. Nous ne vérifions si l'objet implémente IEnumerableou IEnumerable<T>.

C'est cool de savoir. Je peux comprendre pourquoi Eric le sait. il fait partie de l'équipe de compilation, il doit donc savoir. Mais qu'en est-il de ceux qui démontrent une connaissance aussi profonde qui ne sont pas des initiés?

Comment les simples mortels (qui ne font pas partie de l'équipe du compilateur C #) découvrent-ils de telles choses?

Plus précisément, existe-t-il des méthodes que ces personnes utilisent pour extraire systématiquement cette connaissance, l'explorer et l'intérioriser (en faire sa propre propriété)?

Robert Harvey
la source
10
Je pense que c'est particulièrement là où le logiciel open source brille. C'est bien de pouvoir entrer dans le framework, le système et les bibliothèques. J'avais l'habitude de mieux comprendre les composants internes du framework lorsque je travaillais avec Qt que lorsque je travaillais avec WinForms.
Vitor Py
2
Quand auriez-vous besoin de connaître cet exemple spécifique, autrement que de ne pas avoir l'air bête devant une foule spéciale? Ils ont imbécile cela. En dehors de cela, les séries Effective C #, Java, C ++, etc. peuvent contenir des éléments intéressants. Le blog d'Eric Lippert est également une bonne source. En général, nous ne savons souvent pas ce que nous ne savons pas, alors comme on dit "vis cent ans, apprends cent ans et meurt insensé".
Job
26
Cela en vaut-il la peine? Je suis bilingue et j'essaie d'apprendre quelques autres langues parlées. J'ai pris des cours de mathématiques, mais pas assez. J'aimerais apprendre à jouer au tennis de manière décente et apprendre à nager en utilisant le trait de papillon. Je voudrais voyager plus. Je veux apprendre un peu de Clojure. Ce que je ne veux pas, c’est être expert dans une langue, avoir un doctorat en mathématiques, passer 30 heures par semaine dans une piscine comme Michael Phelps, etc. Les connaissances de Lippert et de Skeet sont dues au fait qu’elles ont beaucoup effort dans une (ou quelques) choses tout en manquant d’autres expériences. Peut-être changer de travail?
Job
10
"Je peux comprendre pourquoi Eric le sait; il est dans l'équipe du compilateur, alors il doit le savoir." - Il sait probablement parce qu'il y a pensé . Je doute qu'il ait dû "découvrir" que cela fonctionne comme ça :)
Alex ten Brink
10
@Alex: En fait, je ne travaille que sur C # depuis que nous avons commencé à construire l'implémentation de C # 3. La spécification "foreach" a été écrite il y a six ans. Je découvre encore tous les jours des histoires folles sur la langue. Par exemple, j'ai appris aujourd'hui que pour les délégués, ((A + B) + C) - (A + C) = A + B + C, mais que ((A + B) + C) - (B + C) = A . Bizarre!
Eric Lippert

Réponses:

167

Tout d'abord, merci pour les mots gentils.

Si vous souhaitez acquérir une connaissance approfondie de C #, il est sans aucun doute un avantage de disposer de la spécification du langage, de dix années de notes de conception, du code source, de la base de données de bogues et de Anders, Mads, Scott et Peter au bout du couloir. Je suis certainement chanceux, pas de question à ce sujet.

Cependant, même sans ces avantages, il est toujours possible d’acquérir une connaissance approfondie du sujet.

À mes débuts chez Microsoft, je travaillais sur l'interpréteur JScript fourni avec Internet Explorer 3. À ce moment-là, mon responsable m'a dit que c'était l'un des meilleurs conseils que j'aie jamais eu. Il a déclaré qu'il souhaitait que je devienne l'expert reconnu de Microsoft en ce qui concerne la syntaxe et la sémantique du langage JScript, et que je devrais y parvenir en cherchant des questions sur ces aspects de JScript et en y répondant. Répondre particulièrement aux questions pour lesquelles je ne connaissais pas les réponses, car ce sont celles-là dont j'apprendrais.

De toute évidence, StackOverflow et d'autres forums publics de questions-réponses sont comme boire de l'alcool à la main pour ce genre de chose. À l'époque, j'ai lu religieusement comp.lang.javascript et nos forums internes «JS User» de Microsoft, et ai suivi les conseils de mon responsable: lorsque j'ai vu une question concernant la sémantique linguistique dont je ne connaissais pas la réponse, je l'ai faite. mon affaire à découvrir.

Si vous voulez faire une "plongée profonde" comme ça, vous devez choisir avec soin. A ce jour, je suis remarquablement ignorant du fonctionnement du modèle d'objet de navigateur. Depuis que je me suis concentré à devenir le spécialiste du langage C # ces dernières années, je suis remarquablement ignorant du fonctionnement des différentes classes des bibliothèques de classes de base. J'ai la chance d'avoir un travail qui valorise des connaissances approfondies spécifiques; Si votre travail ou vos talents sont plus en phase avec le statut de généraliste, aller en profondeur risque de ne pas fonctionner pour vous.

Écrire un blog est également extrêmement utile. en m'obligeant à expliquer des sujets complexes à d'autres personnes, je suis forcé de faire face à ma propre compréhension insuffisante de divers sujets tout le temps.

Eric Lippert
la source
14
Sans vouloir traîner cela hors sujet, mais après avoir lu cette réponse, je suis curieux de savoir pourquoi vous n'avez posé aucune question ici ou sur Stack Overflow. Vos collègues, blog, etc. vous suffisent-ils à ce stade? Existe-t-il de meilleures ressources que SO que nous devrions connaître?
Matthew Read
6
Vous avez peut-être mal compris ce qu'il dit. Contre-intuitivement, il ne posait pas de questions pour apprendre, il répondait à des questions.
Jhocking
65

Ayant été du côté "gourou" de la conversation une ou deux fois, je peux vous dire que très souvent, ce que vous percevez comme une "connaissance approfondie" d'un langage ou d'un système de programmation est souvent le résultat du "gourou" qui lutte depuis peu pour un mois pour résoudre exactement le même problème. Cela est particulièrement vrai sur un forum où les gens peuvent choisir les questions auxquelles ils répondront. Même ceux comme Jon Skeet et Eric Lippert ont dû apprendre bonjour monde à un moment donné. Ils acquièrent leurs connaissances un concept à la fois, comme tout le monde.

Karl Bielefeldt
la source
1
Un très bon point. Lorsque je m'engage dans de longues périodes de recherche, je découvre souvent des questions auxquelles je peux maintenant répondre en raison de choses que j'ai apprises plus tôt dans la journée.
Matthew Lu
47

Paraphrasant Yogi Bhajan:

"Si vous voulez apprendre quelque chose, lisez à ce sujet; si vous voulez comprendre quelque chose, écrivez à ce sujet; si vous voulez maîtriser quelque chose, programmez- le."

La programmation est comme le défi ultime de l’enseignement. Enseigner à l’ordinateur faire quelque chose exige que vous connaissiez très bien votre travail - ou vous apprendrez à le maîtriser.

Par exemple, si vous voulez apprendre la physique, écrivez un moteur de physique. Si vous voulez apprendre les échecs, programmez une partie d'échecs. Si vous souhaitez approfondir vos connaissances en C #, écrivez un compilateur C # (ou un autre outil).

Maglob
la source
2
La programmation est aussi une tentative modeste d'écriture (à lire par les gens, bien entendu) de la manière la plus non équivoque.
vpit3833
4
Cette citation a semblé très profonde jusqu'à ce que je lise l'exemple d'échecs. Malheureusement, programmer une IA d'échecs ne fera pas de vous un meilleur joueur d'échecs (c'est fondamentalement une recherche dans un arbre Min-Max). Toujours +1
mardi
1
@bughi Peut-être maîtriserez-vous les règles: D
Julio Rodrigues
@ bughi, "programme c'est" est un terme très large qui n'est pas toujours lié à l'écriture de code !! Il suffit de penser un peu hors de la boîte.
Nitesh Verma
25

Autant que je sache, les moyens d'apprendre ceci sont:

  • Lisez à ce sujet quelqu'un comme Eric Lippert
  • Expérience et ensuite résoudre les problèmes de première main.

La deuxième façon peut prendre beaucoup plus de temps mais entraînera probablement une compréhension plus profonde (mais pas toujours).

FrustratedWithFormsDesigner
la source
17
Ou les deux. [15 caractères]
Michael K
23

Je dirais faire ce qui suit:

Après avoir appris une pile de langues relativement utile (celle dont vous avez besoin pour un vrai travail) au niveau où vous pouvez effectuer les tâches les plus courantes, arrêtez d'apprendre d'autres langues jusqu'à ce que vous en ayez étudié au moins une en profondeur. À mon avis, une partie du problème qui se pose actuellement dans notre secteur est que les gens n'apprennent que les 5 à 10% premiers de la langue avant de passer à une autre langue. Une fois que vous avez la capacité d'effectuer les tâches les plus courantes d'un travail, commencez par examiner une chose en profondeur. (Vous pouvez revenir à la largeur après avoir obtenu de la profondeur, puis aller et venir entre les deux.)

Bénévole pour les tâches les plus complexes et les plus difficiles, celles qui vous obligent à aller en profondeur pour résoudre les problèmes. S'il n'y en a pas, cherchez des tâches open source à faire ou commencez à travailler sur un projet personnel qui vous obligera à approfondir. Si votre travail ne présente pas de problèmes intéressants, songez à rechercher un travail plus stimulant.

Lisez les livres avancés sur une langue (pour SQl Server, par exemple, cela inclurait des informations sur le réglage des performances et les éléments internes de la base de données) au lieu du type de livre learn X dans 30 jours.

Lisez les questions intéressantes ici et d’autres endroits où elles sont posées et essayez de les résoudre vous-même. Si vous voulez apprendre, essayez de résoudre certaines questions sans lire au préalable les autres réponses. Même si la question a déjà été répondue, vous en apprendrez plus si vous trouvez la réponse vous-même. Vous pourriez même trouver une meilleure réponse que celle contenue dans la question.

Posez quelques-unes des questions les plus difficiles. Évaluez les réponses qui vous sont données, ne vous contentez pas de les utiliser. Assurez-vous de comprendre pourquoi la réponse fonctionnerait ou non. Utilisez ces réponses comme point de départ pour vos recherches.

Trouvez de bons blogs techniques d'experts réputés dans le domaine et lisez-les.

Arrêtez de jeter vos connaissances après en avoir fini. Apprenez à retenir. La plupart des experts n'ont pas à rechercher la syntaxe commune. Ils n'ont pas à réinventer la roue à chaque fois qu'ils rencontrent un problème, car ils se souviennent de la manière dont ils avaient abordé un problème similaire auparavant. Ils peuvent relier les points et voir à quel point le problème X qu’ils ont rencontré il ya deux ans est semblable au problème Y qu’ils ont aujourd’hui (cela me surprend de constater à quel point peu de personnes semblent capables d’établir des relations de ce type). Par conséquent, ils ont plus de temps à consacrer à la recherche de sujets plus intéressants.

HLGEM
la source
Une bonne réponse. Mais je me demande comment puis-je mieux conserver les connaissances et relier les points?
Je vous suggère de prendre des notes de tout ce que vous apprenez. J'ai commencé à le faire dans mon Evernote, et au fil des années, j'ai découvert que je pouvais vivre de mes notes. Lentement, je suis aussi arrivé au point où mes notes peuvent être transformées en présentations, que je suis prêt à présenter à tout moment.
Shivasubramanian Un
9

Vous pouvez commencer par étudier en profondeur les spécifications linguistiques de celles pour lesquelles vous souhaitez être un expert. Par exemple:

Marcelo
la source
3
Bonne réponse - par exemple, la section 15.8.4 de la spécification liée C # couvre la mise en oeuvre de foreach, et décrit le comportement décrit dans le billet de blog cité d'Eric Lippert. Si quelqu'un se trouve à penser quelque chose comme "Je me demande comment foreach fonctionne vraiment ...", ce serait un bon endroit pour commencer à chercher.
Carson63000
6

Procurez-vous Reflector ou tout autre décompilateur (car il paye maintenant) et commencez à ouvrir certaines des bibliothèques .NET les plus utilisées pour apprendre le fonctionnement des éléments internes. Combiné à un livre comme CLR via C #, vous obtiendrez une connaissance approfondie (plus profonde que la plupart d’entre nous dans leur travail habituel).

Bart
la source
5
En fait, je l'ai fait avec les BitConverterclasses et j'ai découvert l' IsLittleEndianindicateur spécifique au système.
Robert Harvey
LOL. +1 pour isLittleEndian
Rudy
4

J'ai développé ce type de connaissances en C ++ en y restant comp.lang.c++.moderatedquelques années, même si je ne travaillais pas vraiment dur à la coder à ce moment-là. Je ne sais pas comment je peux dire que je suis un gourou.

Je pense qu'il y a deux types de connaissances que l'on peut acquérir sur un langage de programmation:

  1. Connaître des anecdotes sur la langue et savoir comment éviter les pièges.
  2. Savoir résoudre efficacement les problèmes.

Le numéro 2 ne peut être obtenu qu'en programmant dans la langue et en regardant le code des autres, mais en prenant beaucoup de temps pour lire la langue sur ses forums de discussion, en voyant quels types de questions les gens posent et ce les réponses sont. StackOverflow est un bon endroit pour cela aussi.

Ken Bloom
la source
4

Une connaissance approfondie et une expertise en programmation signifient être à l'aise à tous les niveaux d'abstraction. C'est à dire

  • bibliothèques et API
  • sémantique linguistique
  • optimisations du compilateur
  • internes du compilateur et génération de code
  • Comportement du runtime et du ramasse-miettes
  • Problèmes d'architecture et de jeux d'instructions

Tout ce que j'ai vu au cours des 15 dernières années a montré que ce n'est que si vous pouvez vraiment entrer dans le compilateur et l'exécution que vous avez une chance de devenir très compétent. Vous devrez peut-être vous forcer à franchir le pas et à commencer à raisonner (et à construire) un logiciel à un niveau d'abstraction plus bas dans la pile , mais c'est le seul moyen d'expertise.

Tout ce que nous avons, c'est un langage pour l'abstraction. Vous devez comprendre comment les langages de programmation sont conçus et construits pour vraiment savoir ce que fait la machine.

Don Stewart
la source
3

Lisez le manuel détaillé Ce n'est pas une connaissance particulièrement approfondie. Il est publié dans la section 8.6.4 de la spécification du langage C # . Vous devriez avoir l’habitude d’écraser au moins les spécifications des langues que vous utilisez, ainsi que d’écrémer la documentation de toutes les bibliothèques intégrées.

Quoi qu'il en soit, ce n'est pas mon idée de la connaissance profonde; c'est juste un détail d'implémentation sans intérêt. Il serait peut-être plus intéressant que le concepteur explique pourquoi cela a été fait de manière plus dynamique, au lieu de simplement vérifier que l'objet implémente Iterable.

Kevin Cline
la source
1
Je ne pense pas qu'il existe une telle chose que "écrémer" la spécification du langage C #.
Robert Harvey
@RobertHarvey: vous pouvez parcourir la plupart des langages formels couvrant des connaissances déjà connues, telles que la préséance des opérateurs et la syntaxe de déclaration, et vous concentrer sur les détails inattendus mais utiles, tels que le comportement exact des constructeurs C # foreach ou Java enum.
kevin cline
Vous pouvez acheter une version annotée de la norme. C'est un peu démodé maintenant mais les commentaires sont toujours très intéressants pour les parties de la langue qui sont couvertes.
Jørgen Fogh