Il y a longtemps, j’ai écrit un article sur le thème «Pourquoi les ordinateurs sont nuls» (qui a finalement obtenu les noms «Ordinateurs» et « Ce qui ne va pas avec les ordinateurs » et le nom d'origine n'est jamais sorti). L'article était assez long, mais l'essence se résumait à l'idée que les ordinateurs sont de la merde du fait que les programmeurs créent des choses complexes les plus folles que personne d'autre ne peut comprendre, et parce que la complexité est basée sur une complexité encore plus grande tant que tout le monde l'aspect du programme ne deviendra pas ingérable.
CPAP d'ici
Ce que je ne savais pas alors, c'était pourquoi les programmeurs faisaient cela. Il était évident qu'ils faisaient cela; mais pourquoi l'industrie du logiciel crée-t-elle autant de code sauvage, complexe et illisible? Pourquoi cela continue- t-il même après, semble-t-il, les développeurs auraient dû apprendre de la première expérience négative? Qu'est-ce qui a poussé les programmeurs non seulement à écrire du mauvais code, mais à le faire encore et encore?
Eh bien, c'était un mystère pour moi, mais d'une manière ou d'une autre je n'étais pas particulièrement inquiet à ce sujet au début. L'idée même que «les mauvais programmes viennent de mauvais programmeurs» est si simple et évidente qu'elle a servi de base à toute une étude dans le domaine de la programmation, qui a finalement eu de bons résultats (qui sont principalement décrits dans ce blog, et fait également l'objet de livres en cours de rédaction). Le problème a été identifié (mauvais programmeurs qui créent de la complexité), et, à première vue, elle avait une solution (créer des règles pour le développement de logiciels qui empêcheraient cela), et cela me suffisait.
Mais je me demandais toujours si des universités, des écoles techniques et des programmes éducatifs de renommée mondiale diplômaient des programmeurs aussi terribles, malgré des décennies d'expérience dans l'enseignement des techniques de développement de logiciels. Bien sûr, de nombreux principes de conception de programmes n'ont jamais été confidentiels, et de nombreux bons conseils sont à portée de main, et beaucoup d'entre eux sont très généraux. Même si les gens n’allaient pas à l’école, n’ont-ils pas lu de tels conseils?
Eh bien, la vérité était au-delà de mon imagination, et il a fallu près de cinq ans pour travailler dans le projet Bugzilla avec la participation d'un grand nombre de développeurs, de sorte qu'un beau jour, j'ai soudainement réalisé un fait terrifiant:
La grande majorité (90% ou plus) des programmeurs n'ont aucune idée de ce qu'ils font.
Non pas qu'ils n'aient rien lu sur le développement de logiciels (bien que probablement pas). Non pas que les langages de programmation étaient trop compliqués (bien que ce soit le cas). Le fait est que la plupart des programmeurs n'ont aucune idée de ce qu'ils font réellement. Ils imitent simplement les erreurs des autres programmeurs - copiant le code et imprimant des sorts plus ou moins significatifs sur l'ordinateur dans l'espoir qu'il se comportera de manière similaire à ce qu'ils attendent, sans avoir une réelle compréhension de la mécanique de l'ordinateur, ni des principes de développement logiciel, ni de valeur chaque mot et symbole individuel qu'ils entrent dans l'ordinateur.
C'est une déclaration audacieuse, choquante et insultante, mais mon expérience le confirme. J'ai personnellement parcouru et évalué le code de dizaines de programmeurs. J'ai lu le code de beaucoup d'autres. J'ai parlé à de nombreux programmeurs du développement de logiciels et lu des articles de centaines de développeurs. Le nombre de ceux qui comprennent vraiment ce qu'ils font n'est que d'environ 10% de tous les programmeurs avec qui j'ai déjà parlé, travaillé avec ou entendu parler.
Les développeurs open source sont les meilleurs des meilleurs; ce sont des gens qui veulent programmer même pendant leur temps libre. Et même alors, je dirais que seulement environ 20% des développeurs open source sont vraiment bons dans ce qu'ils font.
Mais pourquoi? Quel est le problème? Comment se fait-il qu'il y ait tant de personnes travaillant dans cette industrie qui n'aient aucune idée de ce qu'elles font?
Eh bien, il semble qu'ils soient en quelque sorte «stupides». Mais qu'est-ce que la stupidité? Les gens ne deviennent pas stupides simplement parce qu'ils ne savent pas quelque chose . Il y a beaucoup de choses que tout le monde ne sait pas. Mais cela ne les rend pas stupides. Cela les rend ignorants de certaines choses, mais pas stupides. Non, stupidité, vraie stupidité - cela signifie ne pas savoir que vous ne savez pas quelque chose . Les gens stupides pensent qu'ils savent quelque chose, bien qu'ils ne le sachent pas , ou ils ne réalisent pas que le champ de la connaissance est beaucoup plus large qu'ils ne le pensent .
Cette "stupidité" est quelque chose qui peut être trouvée dans presque tous les domaines, et le développement de logiciels ne fait pas exception. De nombreux programmeurs ne réalisent tout simplement pas qu'il peut exister certaines lois ou principes généraux pour le développement de logiciels, ils n'essaient même pas de les trouver. De nombreuses sociétés de logiciels ne tentent pas d'améliorer la compréhension des développeurs des langages de programmation qu'ils utilisent. C'est peut-être parce que la direction estime que les programmeurs devraient «déjà savoir tout cela, car ils ont été embauchés pour le faire».
Malheureusement, cette vue est nuisible lors du développement de logiciels, car si vous voulez être un très bon programmeur, vous devez en savoir beaucoup . Quiconque croit qu'il sait tout (ou qui a un «angle mort», à cause duquel il ne voit pas quoi apprendre de plus) - brouille son code idéal en l'absence de connaissances - la connaissance de l'existence dont ils ne savent pas Ils connaissent et ne réalisent même pas le fait même d'un manque de connaissances .
Peu importe vos connaissances, il y a toujours autre chose dans n'importe quel domaine et la programmation ne fait pas exception. Donc, penser que vous savez que tout va toujours mal.
Parfois, il est difficile de déterminer ce que vous devez étudier. Il y a tellement de données, mais par où commencer? Pour aider à cela, j'ai trouvé quelques questions que je dois me poser ou poser aux autres pour déterminer les domaines qui nécessitent une étude plus approfondie:
- Connaissez-vous tout ce que vous pouvez sur chaque mot et chaque caractère sur chaque page de votre code?
- Avez-vous lu et bien compris la documentation de chaque fonction que vous utilisez?
- Avez-vous une excellente compréhension des principes de base du développement logiciel - si bon que vous pourriez l'expliquer aux programmeurs débutants de votre organisation?
- Comprenez-vous comment fonctionne chaque composant de l'ordinateur et comment ils fonctionnent ensemble?
- Comprenez-vous l'histoire des ordinateurs et comment ils évolueront afin de comprendre comment votre code sera exécuté sur des ordinateurs créés à l'avenir?
- Connaissez-vous l'histoire des langages de programmation pour comprendre comment le langage que vous utilisez a évolué et pourquoi fonctionne-t- il de cette façon?
- Comprenez-vous d'autres langages de programmation, d'autres approches de programmation et types d'ordinateurs différents de ceux que vous utilisez pour comprendre quel outil est le mieux adapté à chaque tâche?
- Top-down répertorie les choses les plus importantes pour un programmeur pour comprendre quel code il écrit. Si vous pouvez honnêtement répondre «oui» à toutes ces questions, alors vous êtes certainement un excellent programmeur.
La longueur de la liste semble peut-être déprimante. «Wow, lisez la documentation de chaque fonction? Oui, cela prendra beaucoup de temps! " D'accord, savez-vous quoi d'autre prendra beaucoup de temps? Devenez un bon programmeur sans lire la documentation. Et tu sais combien? L'éternité , car cela n'arrivera jamais.
Vous ne deviendrez jamais un bon programmeur en copiant simplement le code de quelqu'un d'autre et en priant pour que cela fonctionne pour vous. Mais plus important encore, investir du temps dans la formation signifie devenir un bon [ programmeur - env. traducteur ]. Le temps passé maintenant fera de vous un programmeur beaucoup plus rapide à l'avenir. Si vous passez beaucoup de temps à lire pendant les trois premiers mois d'apprentissage d'une nouvelle technologie, vous serez probablement 10 fois plus rapide au cours des 10 prochaines années que si vous vous précipitiez pour l'utiliser sans lire quoi que ce soit.
Je veux clarifier tout de suite - bien sûr, cela ne fonctionnera pas simplement pour lire trois mois et devenir un bon programmeur. Premièrement, c'est trop ennuyeux - personne ne veut entasser une théorie pendant trois mois sans avoir aucune pratique. Peu de gens peuvent le faire assez longtemps pour même devenir programmeur, sans parler d'être bon à la fois. Donc, je veux immédiatement noter que la compréhension vient de la pratique , et pas seulement de la théorie. Mais sans étudier la théorie, la compréhension peut ne pas apparaître du tout . Il est donc important de trouver un équilibre entre la programmation pratique et la théorie.
Je n'attaque aucun programmeur avec qui j'ai personnellement travaillé, ni aucun programmeur en général. J'admire presque tous les programmeurs que j'ai jamais connus en tant que personne, et je m'attends à en admirer d'autres si je les rencontre. Au lieu de cela, j'exhorte tous les programmeurs à ouvrir leur esprit au nouveau, afin qu'il y ait toujours de nouvelles connaissances, que la théorie et la pratique soient la clé de la maîtrise, et qu'il n'y ait rien de honteux à ne pas savoir quelque chose - si vous vous savez que vous ne savez pas quelque chose. Prenez juste le temps de le découvrir si nécessaire.
D'un traducteur: J'ai essayé de traduire dans un style littéraire, alors peut-être que certaines déclarations ou idées de l'original ont été déformées en raison du désir de rendre la traduction plus lisible. Si c'est le cas, veuillez ne pas conduire avec des chiffons énervés, mais écrivez PM.