Est-il acceptable de ne pas comprendre complètement la fonctionnalité du code?
Comme je suis actuellement aux prises avec l'apprentissage de la WCF pour un projet au travail, depuis plusieurs jours, je regarde des tutoriels en ligne et des exemples sur la meilleure façon de faire un client WCF; et aujourd'hui, quand j'ai dit à mon patron que j'avais du mal à trouver de bons tutoriels parce que certains d'entre eux n'entreraient pas dans les détails avec leurs exemples (par exemple en montrant un morceau de code qui fonctionne mais sans expliquer pourquoi exactement, ou en faisant un exemple avec juste quelques lignes au lieu d'une plus grande échelle), il m'a dit que je ne devrais pas essayer de les comprendre complètement, car il y a des moments où un code fera juste ce qu'il fait et je devrais en rester là (il m'a donné le exemple que lorsque nous faisons du calcul, par exemple, nous utilisons des formules que nous ne savons pas comment elles ont été conçues ou comment elles fonctionnent, nous savons simplement qu'elles le font et nous les utilisons).
Et cela m'a dérangé car on m'a toujours dit qu'il est vraiment important de comprendre votre code, et que le simple copier-coller sans savoir COMMENT ça marche est pratiquement un péché; c'est pourquoi je prends toujours mon temps pour comprendre quelque chose avant d'aller de l'avant. Et ce n'est pas comme si j'essayais de comprendre comment une classe particulière fonctionne au niveau du langage d'assemblage, je veux juste savoir pourquoi un ensemble d'instructions fait l'affaire, et pourquoi une autre ne le fait pas, ou pourquoi les deux le font et en vertu de quoi conditions. Mais mon patron me dit que je vais finir par perdre du temps à être obsédé par ces petits détails, et je devrais simplement le sauter. Donc ma question est, a-t-il raison? Est-il correct de comprendre votre code dans une certaine mesure et de continuer, et n'ai-je été obsédé que par de petites choses qui n'ont pas d'importance?
Le seul but des abstractions logicielles est de masquer les détails fonctionnels. Sans ces abstractions, il ne serait pas possible de progresser au-delà d'un certain point de l'informatique , car les systèmes s'effondreraient simplement sous le poids de leur propre complexité. Le cerveau humain ne peut comprendre que tant d'informations à la fois.
Considérez ce qui se passe lorsque vous écrivez une méthode. Lorsque vous écrivez une méthode, ce que vous faites est de cacher un peu de fonctionnalité logicielle derrière un appel de méthode. Une fois que cette méthode est écrite et éprouvée en écrivant des tests unitaires sur cette méthode, vous n'avez plus à penser à ce qui est à l'intérieur de cette méthode sauf si vous devez changer quelque chose au sujet de son implémentation.
Les grands systèmes logiciels sont construits sur plusieurs couches de ces abstractions. Vous avez une couche de microcode dans le processeur, le code machine, les bus d'adresses et de données, les compilateurs de langage, orientation objet, structures de données, langages spécifiques au domaine, etc. Vous avez des bibliothèques construites sur d'autres bibliothèques, qui à leur tour sont construites sur un système d'exploitation. Vous ne comprenez pas non plus comment ces choses fonctionnent, mais vous pouvez toujours écrire avec succès des programmes informatiques qui font quelque chose d'utile.
Cela dit...
Vous ne pouvez pas simplement copier/coller du code sans comprendre comment cela fonctionne . La personne qui essaie de faire fonctionner son programme en copiant du code qu'il ne comprend pas se prépare à l'échec. Vous devez comprendre le code que vous écrivez. Cela ne signifie pas que vous devez savoir comment fonctionne WCF en interne, mais vous faites devez savoir ce que le Le but de WCF est de savoir comment écrire du code qui l’interface correctement et comment le code que vous écrivez fonctionne de concert avec lui. De nombreux programmeurs de copier/coller n'ont même pas une compréhension décente du langage de programmation qu'ils copient/collent, et encore moins une connaissance approfondie des bibliothèques qu'ils utilisent.
Vous devez donc avoir des compétences décentes, et vous devez comprendre le code que vous écrivez (ou collez) qui appelle WCF. Mais vous n'avez pas besoin d'avoir une connaissance approfondie du fonctionnement interne de WCF.
De même, les programmeurs qui pensent pouvoir assembler un programme en câblant au hasard des modèles de logiciels manquent de raison. Nous appelons ces gens programmeurs Cargo Cult .
Je pense que la réponse est le contexte.
L'une des techniques les plus puissantes pour gérer la complexité du code - qui est le vrai travail d'un ingénieur logiciel, dans mon esprit - est l'abstraction. Un ingénieur électricien n'a pas à reprendre les équations de Maxwell pour développer un nouveau produit, et je n'ai besoin de rien savoir sur une voiture pour utiliser un volant. Les deux sont des abstractions importantes car elles nous permettent d'intuition et d'utilisation des choses sans les comprendre. Cela nous permet à son tour de construire de plus grandes abstractions.
En passant, parce que l'abstraction est si importante, je pense qu'il est parfois bon de l'appliquer même à d'autres développeurs. Par exemple, dans mon bureau, nous avons parfois un développeur qui écrit les tests unitaires pour un bloc de code avant que le bloc de code ne soit écrit par un deuxième développeur. Il renforce l'idée d'interfaces simples et d'abstractions claires.
Cela dit, l'abstraction n'est pas une excuse pour ne pas comprendre comment fonctionne le code quand il est important que vous sachiez comment il fonctionne . Le refactoring de code est un scénario évident dans lequel les détails d'implémentation importent un peu. Je n'ai pas besoin de savoir comment fonctionne une voiture pour la conduire, mais un ingénieur en mécanique et un mécanicien devraient tous deux comprendre comment fonctionne une voiture, sans doute de différentes manières.
En seconde partie, l'une de mes premières leçons sur le tas a été de ne jamais toucher à un code que je ne comprenais pas vraiment. Par exemple, je travaillais une fois sur une nouvelle fonctionnalité et j'ai remarqué une autre ligne de code dans le module qui n'avait pas de sens, alors je l'ai "corrigée" puis j'ai publié un bug. Cela m'a appris une leçon assez importante, qui consiste à admettre que je ne comprends pas facilement un morceau de code et à reconnaître qu'un code bon, complexe et non trivial peut être non évident. Je suis assez nouveau dans le développement de logiciels, mais j'ai trouvé l'idée qu'un "bon code est facile à lire" comme insidieux qu'aucun développeur de logiciels que je connaisse ne mette en pratique. Bien sûr, n'écrivez pas de code obscur ou mauvais, mais les problèmes difficiles nécessitent souvent un code complexe. Ne vous inquiétez pas si cela vous prend du temps pour comprendre les choses. Ma citation préférée de Feynman est: "Mais ce n'est pas compliqué; il y en a juste beaucoup."
Alors, quand faites-vous un résumé et quand démontez-vous l'horloge suisse? Je suppose que cela dépend du moment où vous portez la montre et du moment où vous la construisez. Mon opinion personnelle est que les meilleures personnes dans n'importe quel domaine sont en forme de T , ce qui signifie qu'elles comprennent leur travail dans un contexte plus large - quelque chose qui n'est réalisé que par l'abstraction - mais savent également ce qu'elles doivent savoir profondément. .
La compréhension des logiciels se divise en trois parties:
- Tout d'abord, il faut comprendre pourquoi un logiciel (aussi gros qu'une application ou aussi petit qu'une seule fonction) existe. Vous devez savoir à quoi cela sert, pourquoi il a été écrit.
- Ensuite, je pense que c'est comprendre ce que un morceau de code fait.
- Enfin, savoir comment un morceau de code fonctionne, à quoi ressemblent ses composants et ce qu'il fait.
Lequel de ces éléments vous devez maîtriser pour comprendre un logiciel diffère selon ce que vous devez faire avec ce code.
Par exemple, prenez la méthode String.ToUpper () de .NET. Je sais ce que fait cette méthode et pourquoi vous voudriez l'utiliser, mais je ne sais pas comment elle est écrite (c'est un détail d'implémentation) et je m'en fiche vraiment - tant que je peux l'utiliser correctement. Je n'aurai jamais besoin de modifier cette méthode, donc ma compréhension des internes n'est pas nécessaire.
Si je copiais du code sur Internet, je dois être sûr de ce que fait le code et pourquoi. Si je le copiais et ne le modifiais jamais (peu probable), je ne ressens aucun besoin de comprendre comment cela fonctionne. Mais si j'allais le modifier (probablement), alors je devrai savoir comment cela fonctionne - sinon j'utilise juste des conjectures pour modifier le code, et cela ne se terminera probablement pas bien.
Non pas que je sois en désaccord avec les autres réponses, mais permettez-moi de répondre à ce que j'ai lu entre les lignes. Si votre patron vous informe que vous n'avez pas besoin de comprendre comment quelque chose fonctionne, cela pourrait être une rétroaction que vous prenez trop de temps pour faire quelque chose. Certaines personnes se laissent facilement distraire par des détails sans importance et pour elles, il est conseillé de travailler pour rester sur la bonne voie.
D'un autre côté, si la programmation est la profession que vous avez choisie et que vous avez la curiosité intellectuelle de creuser plus profondément dans une technologie qui est importante pour ce que vous faites, alors je vous encourage à prendre un peu plus de temps pour suivre vos intérêts lorsque cela est possible. Les informations que vous obtenez, bien qu'elles ne soient pas immédiatement gratifiantes, porteront leurs fruits à long terme. Il vous aidera à donner un sens à la technologie, vous mettra en mesure de l'étendre dans de nombreux cas et vous préparera à une compréhension encore plus approfondie à l'avenir. Au fil du temps, c'est ce qui différencie un expert d'un utilisateur occasionnel.
Dans le grand programmeur pragmatique de livres, cela s'appelle "programmer par coïncidence" ( http://pragprog.com/the-pragmatic-programmer/extracts/coincidence )
Le plus gros problème avec cela est, si vous ne savez pas pourquoi un morceau de code fonctionne lorsque ce morceau de code échoue pour une raison quelconque, vous ne savez pas pourquoi échoue et vous ne pouvez pas le réparer.
Je ne suis pas entièrement d'accord avec l'énoncé: "Vous ne pouvez pas simplement copier/coller du code sans comprendre comment cela fonctionne."
Pardonnez ma stupidité, mais d'un point de vue programmatique, n'inclut-il pas une bibliothèque de méthodes/fonctions dont je ne sais pas qu'elles fonctionnent essentiellement de la même manière que copier/coller ce code dans le mien?
C'est-à-dire, si je programme avec jQuery, j'inclus la bibliothèque jQuery et je l'utilise. En utilisant la réponse de Robert Harvey, c'est très bien puisque jQuery a résumé toutes les choses que j'ai besoin d'utiliser sans avoir à écrire le code moi-même ou même à le comprendre complètement. Dois-je vraiment savoir exactement comment jQuery fonctionne en arrière-plan avant de pouvoir l'utiliser?
Cela dit, je suis d'accord avec le principe qui sous-tend la déclaration, mais je voulais souligner que le concept de code "copier/coller" (sans compréhension complète) est en fait plus courant qu'on ne pourrait le penser et pas aussi onéreux que cette déclaration ferait il semble.
Comme la plupart du temps, tout dépend. À l'extrême, il y a l'utilisation d'une bibliothèque. Vous n'êtes pas censé savoir ou vous soucier de son fonctionnement. Vous êtes censé savoir quoi mettre et ce qui sort, ce qu'il peut et ce qu'il ne peut pas faire.
À l'autre extrémité, vous ne savez pas comment effectuer une tâche, car vous ne l'avez pas encore fait. Vous trouvez dix lignes de code sur Internet, ce qui semble plus facile que de trouver les bonnes informations dans votre documentation (et c'est souvent le cas). À ce stade, je suggère fortement que maintenant est le bon moment pour apprendre à faire cette tâche. Alors prenez le code, comprenez-le, faites-le vôtre. Sachez que beaucoup de code sur Internet n'est pas nécessairement écrit par les gens les plus intelligents, donc il peut y avoir des faiblesses et des malentendus, donc en apprenant maintenant, vous pouvez vous assurer que le code fonctionne. Et au moment où vous incluez ces dix lignes dans votre projet, ce sont votre responsabilité. Si le code ne fonctionne pas, c'est votre faute. Vous devez donc le comprendre, comme si vous l'aviez écrit.
Alors, quelle est la différence pour la bibliothèque? N'est-ce pas aussi votre responsabilité? Le code de la bibliothèque ne l'est pas. Le choix de la bibliothèque et l'utilisation de la bibliothèque est. Si la bibliothèque plante votre application dix fois par jour, c'est parce que vous avez choisi une bibliothèque qui n'est pas fiable. Vous n'avez pas à comprendre le code de la bibliothèque, mais vous devez comprendre ses problèmes de fiabilité et agir.
Les conseils de votre patron pourrait fonctionnent bien, mais c'est risqué. Il existe un risque qu'à long terme vous rencontriez des problèmes plus importants, qui pourraient être évités en prenant le temps de comprendre les choses en premier lieu. S'il s'agit d'une chose ponctuelle, le risque est relativement faible. Si vous construisez un système logiciel complet de cette façon, vous avez une bombe à retardement sur les mains. Ce que vous ne comprenez pas, vous n'avez aucun espoir de le corriger ou de le changer sans provoquer de bugs.
D'un autre côté, si vous désobéissez à votre patron, votre propre travail peut être en danger. Si vous aimez votre travail, à l'avenir, essayez de résoudre vous-même les problèmes techniques avant qu'il ne s'implique. J'ai eu un patron une fois qui gâchait les choses chaque fois qu'il était impliqué dans les décisions techniques (même s'il était brillant aux ventes et à la relation client). La plupart du personnel technique a appris à écouter ce qu'il allait dire, puis à se retourner et à faire quelque chose de différent. Tant que le logiciel fonctionnait, il ne suivrait jamais et ne vérifierait pas si ses conseils techniques étaient réellement mis en œuvre. Le travail a bien payé, mais je suis content de ne plus y être.
Si cette attitude est omniprésente sur votre lieu de travail, j'envisagerais au moins d'autres options de travail.