Capstone Week 5: Le savoir-faire est inutile sans savoir-pourquoi ni savoir-faire comme un ingénieur

Apprendre à utiliser un framework n’est pas en soi une ingénierie logicielle. L'apprentissage des problèmes résolus par le framework dans son (ses) domaine (s) de résolution est plus proche de l'ingénierie logicielle. Si le projet sur lequel vous travaillez pose des problèmes qui vont bien au-delà de ce qu’un simple cadre peut résoudre, c’est l’ingénierie logicielle. Facebook utilise React, tout comme l'application de panier d'achat pratique que j'ai construite en un jour ou deux. Facebook est un exploit d'ingénierie incroyable. mon application de panier d'achat n'est pas.

Il y a certains aspects de l'apprentissage d'un nouvel outil ou cadre que j'apprécie et d'autres que je n'aime pas. J'aime découvrir les problèmes résolus par les cadres ou les compromis posés par différentes méthodes de structuration du code. Par exemple, je trouve le modèle de conception Flux tout simplement génial. Construire une application sans Flux devient incroyablement compliqué car vous devez transmettre l'état de l'application à travers une multitude de composants, uniquement lorsque ces composants enfants appellent une longue chaîne de fonctions ancêtres jusqu'à ce que le composant propriétaire de l'état soit averti de l'événement en un. Flux facilite énormément la réflexion sur le fonctionnement d'une application, sur la gestion de son état et sur les composants qui en sont responsables, même lorsque le code grandit.

C’est ce sur quoi se concentrer lors de l’apprentissage d’un nouveau cadre: quels problèmes est-il résolu et comment? Quelle est la philosophie à partir de laquelle la solution est née? Quelle est l'architecture générale et quels points de douleur cette architecture introduit-elle? Quelles croyances normatives sur la manière dont un problème devrait être résolu ont inspiré la création de cette solution particulière, et partagez-vous ces croyances? Si vous ne les partagez pas, le devriez-vous? Un cadre est bien plus qu’un outil: c’est une déclaration sur la manière dont un problème fondamental, ou de nombreux problèmes fondamentaux, devrait être résolu. Lorsque je dois apprendre un nouvel outil ou un nouveau cadre, ce sont les questions que je pose. Je ne me soucie pas de mémoriser les nuances exactes de la configuration de webpack: cela viendra avec le temps, et si ce n’est pas le cas, c’est quelque chose que je pourrai facilement rechercher en quelques minutes. Je peux demander à Google ce qu'un message d'erreur signifie. Je ne peux pas demander à Google si je suis d’accord avec les décisions de conception d’un cadre et les compromis qu’ils introduisent.

Bien apprendre un cadre et l’apprendre rapidement ne sont pas incompatibles si vous êtes familiarisé avec les principes fondamentaux du domaine dans lequel vous travaillez. Vous devez également hiérarchiser vos connaissances en fonction d’un programme prédéfini. Mon ordre du jour est presque toujours: "Comprenez le" pourquoi "autant que le" comment ". La raison est la suivante: vous serez toujours plus compétent avec un outil si vous connaissez sa raison d'être et les raisons qui ont motivé sa décision. "Comment?" Et "Pourquoi?" Ne sont pas des questions sans lien, et en fait, une bonne compréhension du "Pourquoi" renforcera votre capacité à utiliser le "Comment". En effet, si vous comprenez pourquoi l’outil présente les caractéristiques spécifiques dont il dispose, vous n’avez pas seulement une compréhension de l’outil lui-même: vous maîtrisez les processus de raisonnement, dont il est une manifestation. Cela signifie que lorsque vous rencontrez inévitablement un défi technique qui ne se résume pas à un ensemble de commandes mémorisées et à des procédures, vous pouvez appliquer le raisonnement derrière l’outil lui-même et naviguer à votre guise jusqu’à une solution. C'est la différence entre un utilisateur du framework et un ingénieur.

Nous avons donc appris à réagir en équipe cette semaine. Donnez-nous une autre semaine et nous pourrions probablement expédier le code de qualité de la production (et en fait, nous aurons une autre semaine). En effet, nous comprenons suffisamment le domaine du problème pour savoir quelles erreurs rechercher (et nous savons comment tester pour éviter ces erreurs). En d’autres termes, nous ne ferons pas autre chose que de créer un échange cryptographique reposant entièrement sur la validation côté client.