Les bases du génie logiciel : Apprendre le cycle de développement logiciel pour mieux programmer

1. Vidéo d'introduction: Bonjour à tous, tous, et bienvenue au partage de compétences et à ce cours de logiciel. Dans ce cours, nous discuterons principalement du cycle de développement logiciel. Donc, le cycle de développement de logiciels est vraiment juste un ensemble de différentes étapes que vous pouvez prendre pour concevoir de meilleurs logiciels. Si vous concevez, par exemple, une petite calculatrice, vous n'avez pas besoin de beaucoup de pratique préalable et de comprendre les détails. C' est une petite application. Ça pourrait être, vous savez, peut-être 100 lignes de code. Peut-être que c'est plus grand et c'est, vous savez, 1000 lignes de code ou même 10 000 lignes de code. Ces projets ne nécessitent pas beaucoup de planification pour réussir, car une fois que vous avez conçu les 10 000, vous pouvez tout avoir en tête. Vous pouvez revenir en arrière et vous pouvez le retravailler, améliorer les choses, et ce ne sera pas trop difficile. Ce qui commence à devenir problématique, c'est quand vous entrez dans plus grand que cela. Si vous avez 100 000 lignes de code, soudainement il y a beaucoup de choses qui interagissent les unes avec les autres. Les bugs commencent à entrer en jeu que vous ne vous attendiez pas, et ces bugs commencent à être vraiment, vraiment complexes au lieu d'un bug qui contacte simplement un autre endroit. Disons que dans une application plus petite, vous avez un bug qui se propage comme ça, c'est facile à suivre. Tu sais, c' est toi qui commence ici. Vous regardez ce morceau de code. Vous regardez ce morceau de code, vous corrigez le bug quand vous obtenez les plus gros morceaux. grands programmes ont soudainement des bugs qui ressemblent à ceci où tout se parle les uns aux autres. Et si vous n'avez pas de plan ni de diagramme, un bug peut ressembler à 100 endroits différents, et vous devez être capable de trouver des trucs comme ça. Vous devez également comprendre comment le concevoir afin que vous puissiez l'étendre plus tard. Si vous voulez agrandir votre projet, vous avez besoin d'une banque pour qu'il soit dans un état où vous pouvez l'ajouter facilement. Et c'est ce que tout cela va détailler. Nous allons donc commencer, ce qui est en train de passer par le cycle de développement logiciel. Nous allons ensuite parler des exigences et des spécifications. Cette étape est vraiment juste de comprendre ce que nous essayons de construire, et ensuite comment nous allons le construire. Nous allons ensuite dans l'architecture, ce qui est en quelque sorte vraiment, vraiment grande vue vers le bas. Quels sont les modèles qui allaient utiliser ? Quelles sont les différentes façons de connecter réellement les différentes parties ? Comment pourrions-nous le briser pour qu'un tas de gens puissent y travailler ? Ils allaient regarder la conception du logiciel. Une fois que nous avons rompu en une partie, nous devons comprendre comment chacune de ces pièces va être construite. C' est là que vous commencez à concevoir des choses. Vous commencez à regarder quelles boucles ? Quelles bibliothèques. Quelles sont les différentes façons de stocker les données dont vous avez besoin pour chacune de ces parties ? Ensuite, nous allons entrer dans la mise en œuvre. C' est à ce moment que tu as vraiment transmis les orteils. Les développeurs et les développeurs commencent à le coder. Donc nous regardons quelque chose comme ça où nous avons un gros problème et qu'ils le décomposent en, disons, un tas de boîtes de ce genre. Ensuite, nous décomposons ces boîtes encore plus loin. Et puis maintenant, nous commençons à mettre des développeurs sur chacune de ces boîtes pour commencer à le construire . Ensuite, nous examinons le déploiement. Une fois que nous avons tout cela ensemble, comment pouvons-nous en faire une grande unité cohésive et ensuite comment prendre cette unité cohésive et l'amener dans le monde réel pour construire une application iPhone ? Comment on l'emmène dans le magasin ? Si nous construisons un ordinateur de bureau, comment pouvons-nous l'obtenir pour que les gens puissent l'acheter ? Donc le déploiement est important et enfin, les tests et ces deux types de choses vont et viennent ? Les tests sont généralement effectués avant le déploiement, mais beaucoup de fois que nous déployons dans le monde d'aujourd'hui déploiera un produit minimum viable ou quelque chose qui est rapide recevra des commentaires, détectera des bugs et des erreurs, puis nous allons les corriger par la suite et garder ce genre de boucle de , de déploiement, test, de déploiement,de test ou en fait être une sorte de test, puis revenir au sommet jusqu' au sommet. Et vous allez en quelque sorte dans ce cycle de refonte et de mise à jour continue et maintenance de votre logiciel. Donc, dans ce cours, c'est ce que nous allons apprendre. Nous apprenons toutes ces étapes sur la façon de construire de meilleurs logiciels, comment organiser votre logiciel et, dans l'ensemble, comment nous assurer que lorsque vous construisez quelque chose de volumineux, cela finit par fonctionner. En fin de compte 2. 1-1 Pourquoi utiliser des modèles: parlons de l'importance du cours en général. Pourquoi utilisons-nous des modèles logiciels et de l'ingénierie logicielle ? Pourquoi ne pas simplement coder le truc ? Pourquoi ne pas entrer et faire le projet ? Eh bien, cela devient plus évident quand on pense à un autre projet, quelque chose qui est dans le monde physique. Parlons de construire un pont. Imaginez si vous construisez un pont et que vous commencez de chaque côté. Donc vous avez, genre, cette rivière et vous commencez à construire du côté gauche et du côté droit et vous rejoignez au milieu. Beaucoup de ponts sont créés comme ça parce que vous pouvez le créer deux fois plus vite au lieu d'avoir à construire à partir de la droite et à traverser tout le chemin. Vous pouvez réellement commencer des deux côtés avec deux équipes de construction et juste se rencontrer au milieu. Au Japon, la balle forme les grands vieux chemins de fer. En fait, il a commencé dans huit ou neuf endroits différents, et ils se contentent de connecter la fin. Imaginez, cependant, si ce pont ici, si elle se connectait au milieu et il était comme 10 pieds les uns des autres, Donc, au lieu de ce pont droit parfait, nous avons maintenant une partie des voies sur le droite et une partie des voies sur la gauche qui en fait juste aller tout droit dans l'océan. Ce serait une catastrophe. Ce pont serait rendu inutile. Nous ne serions pas en mesure de travailler avec elle. Et l'ingénierie logicielle, on pourrait considérer ces deux côtés. Ah, Bug. Ah, assez gros insecte. Mais juste un insecte. Et de gauche et de droite, peut-être en haut. Peut-être qu'à l' arrière, il pourrait sembler que le pont fonctionne. Cependant, la structure n'est pas saine. Pas sur Lee. Pourrait-il tomber à cause de ça ? Mais aussi, il pourrait y avoir ce problème où les gens conduisent juste dans l'océan. C' est une catastrophe pour l'entreprise de construction, car maintenant, non seulement ils doivent payer pour construire le pont la première fois, mais ils doivent aussi payer pour le déconstruire et reconstruire le pont correctement. Et ça a coûté beaucoup d'argent. Et peut-être que la société de construction est en panne. Il doit être abandonné. Et maintenant, nous avons juste ce pont qui va pourrir. Et nous n'avons pas vraiment de solution pour le problème. On essaie de réparer. Voilà donc quel est l'importance de toute cette planification. Ils ont raté un seul plan. Accepté. Ça coûte des millions. Beaucoup de gens ne pensent pas que cela puisse arriver. Et l'ingénierie logicielle je vais juste le réparer plus tard. C' est tout du code. Affaiblir, supprimer et réécrire. Cependant, chaque fois que vous entrez dans des millions de lignes de code, cela devient un problème. Amazon, par exemple, je pense, a plus de 10 millions de lignes de code ou même plus de même avec Facebook et toutes ces grandes entités. Ils ont tout ce code. Imaginez si vous avez créé un bug là-dedans qui se représente sur, par exemple, sur Facebook sur la page des amis. Mais c'est en fait quelque chose à voir avec le flux de chronologie. Imaginez à quel point ce serait difficile à déboguer. C' est quelque chose qu'on appelle la dette technique. C' est ma définition. Ah, pauvre difficile à comprendre la mise en œuvre hacky, qui devra re remboursé avec intérêt plus tard. Donc, cela se résume vraiment à couper des coins au début, ne pas vraiment planifier quelque chose et juste sauter dedans. On dirait que ça marche maintenant que tu as fait un petit test rapide. n'y a pas d'insectes, donc, vous savez, économisez une heure ou deux de planification, et maintenant vous pouvez passer à la prochaine chose. Cependant, cela pourrait vous coûter 20 heures plus tard. Imaginez que c'est juste une petite ligne dans un fichier et que vous le mettez là et que vous ne documentez pas et il n'y a pas de plans d'orteils. Pourquoi tu l'as mis là-dedans ? Aussi pas de commentaires pour expliquer pourquoi vous l'avez mis là maintenant, 68 mois plus tard. 68 mois. Peut-être que c'est trois ans plus tard, en fait, cette ligne que vous mettez là crée un bug. Un autre programmeur vient essayer de le réparer. Il doit non seulement trouver la ligne originale que vous mettez là, mais peut-être qu'il ne met pas de bug dans ce fichier. Peut-être qu'il crée réellement un bogue sur une partie complètement différente du serveur. Il doit donc passer par tout le processus de traçage pour revenir à cette ligne de code. Et puis une fois qu'il le voit, oui, pour comprendre ce qu'il était censé dio chercher la bonne façon de le faire, documenter la bonne façon de le faire, puis fixer la ligne. C' est beaucoup plus de travail que vous le faites au tout début, où vous comprenez déjà comment cette chose est construite et vous venez de mettre la bonne ligne de code là-dedans. Donc, avec cet exemple, vous pouvez voir rapidement comment les coûts pourraient aller et monter en flèche plus longtemps qu'ils attendent, car il n'y a peut-être que 10 fichiers ici. Et dans quatre mois, il y a peut-être jusqu'à 400 fichiers. Et quand nous entrons dans le développement, peut-être que nous avons quelque chose comme 1000 fichiers différents à vérifier. Et cette petite ligne un manteau devient de plus en plus difficile, de plus en plus difficile à trouver, surtout s'il y a de mauvaises pratiques de programmation ailleurs dans la production. Et ce genre de chose peut réellement mener à ça. Ce nombre 80 des 20% des projets échoués. C' est une statistique réelle. J' oublie de quelle étude provenait, mais elle était semi récente et imaginez toutes ces entreprises qui créent des logiciels qui peuvent coûter des millions de dollars. Cela signifie que 20% de ces logiciels de 1 000 000$ sont juste qu'ils échouent. La société vient de gaspiller leur argent et ne doit rien récupérer. n'y a pas de r a y, pas de retour sur investissement du tout. C' est vraiment, vraiment mauvais pour l'entreprise. Selon une étude récente, ce coût est de 85 milliards de dollars par année. Et cela se résume généralement à cela. C' est un développeur typique, Spence. 13,5 heures sur cette dette technique, puis 3,8 heures sur la correction ou le débogage de code incorrect supplémentaire ou même l'ajout de code plus mauvais. Donc, vous savez que vous êtes assis ici et que vous dépensez tout ce temps et cet argent pour corriger vieilles erreurs, et vous pourriez même mettre en œuvre des erreurs MAWR plus tard. Et c'est un gros coût. C' est pour un développeur qui paie 50$ de l'heure. Ça pourrait être, tu sais, c'est environ 700$ par semaine pour chaque développeur que tu gaspilles parce que les gens coupent des virages au tout début. Donc, l'ingénierie logicielle dans son ensemble nous permet de nous réunir, créer un plan central et d'empêcher un grand nombre de ces bugs regardant ce code, c'est juste un exemple très rapide. Donc vous pouvez voir juste quelque chose de physique à regarder est imaginer. Vous êtes tombé sur cette ligne de code et vous vouliez savoir ce qu'elle fait maintenant. Typiquement, ce n'est pas vous savez, ce n'est pas trop dur, mais ça pourrait être vraiment, vraiment, vraiment difficile si quelqu'un venait de sortir du fond dans, tu sais, revêtement de cette chose. Mais en ce moment, nous devons regarder ça. Nous devons comprendre ce que cela fait. Et donc on pourrait même devoir, comme, tu sais, prendre un petit bout de papier et être comme, OK, vrai. D' accord. Faux données. Oh, ok. Cette ligne de code est complètement équivalente à ce bloc entier, et cela peut être nous jeter hors. Peut-être que ça perdra 10 minutes de notre temps à réparer, même si ce n'est que 10 minutes. Si nous payons 50$ de l'heure, c'est quelques dollars de temps d'entreprise. Et pas seulement cela, mais disons que tout le fichier ou chaque fois que le programmeur voulait le faire ici, il y a juste une vérification pour savoir si a et B sont les deux notes Knoll. En même temps, il a ajouté ceci chaque fois qu'un programmeur rencontre va perdre ce temps, et cela augmente la dette technique encore et encore et encore. Donc, en fin de compte, ce que j'essaie de dire, c'est que la partie importante de ce cours est d'apprendre que le design est important. Si vous voulez créer quelque chose qui est, vous savez, plus grand qu'un petit ajout ou un petit jeu ou quelque chose comme ça, puis le concevoir pour qu'il puisse être étendu, il pourrait être collaboré sur, et il ne crée pas ces situations vraiment mauvaises plus tard est important. Et c'est que nous allons aller sur ce cours est comment faire. Tout cela, c'est comment élaborer un plan et comment se joindre à une équipe et comprendre de quoi ils parlent. 3. Cycle de développement logiciel: Nous allons donc entrer dans le genre de cycle de développement de logiciels, la façon dont nous concevons des logiciels avec des logiciels. Il y a un tas de différentes façons que vous pouvez le faire et ces modèles généralement appelés, et c'est ainsi que vous implémentez réellement ce genre de cinq étapes. Cependant, ces cinq étapes sont généralement cruciales pour mettre un logiciel en conformité avec des normes qui sont, vous savez, très fiables. Avec cela, vous remarquerez également que ceux-ci peuvent être appliqués à vraiment toutes les pratiques d'ingénierie de ce genre lors la dernière conférence. Quand je parle de construire un pont, ça pourrait être utilisé pour ça aussi. Nous passerions en revue les exigences et la conception, la mise en œuvre et la vérification et entretien avec un pont. Donc, si nous voulons y penser comme ça pendant que nous traversons ça, ça pourrait le faire coller un peu mieux. La première chose dont nous voulons parler est que nous voulons parler de quelque chose appelé exigences, sorte que les exigences sont assez simples. Les exigences sont ce que nous construisons ? Donc, les exigences sont le quoi ? Qu' est-ce qu'on va construire ? Nous voulons être en mesure de faire en sorte que personne ne puisse faire face à ce que nous construisons . Ce que je veux dire par là, c'est que nous ne voulons pas qu'un groupe de huit personnes construise tout cela avec une idée différente de ce que sera le produit final. On ne veut pas qu'ils pensent que, vous savez, peut-être qu'une personne pense qu'elle va utiliser huit serveurs. On pense que ça va être un serveur local. On pense que là où ça va être un business run, comme ça va être utilisé principalement par des gens d'affaires. Alors que quelqu'un d'autre pense que ça va être utilisé principalement par les consommateurs. Ce serait un gros problème si vous essayez d'obtenir comme un tas de personnes pour travailler ensemble sur un projet que tout le monde construirait dans une direction différente et qu'il s'effondrerait . Donc, avec les exigences, ce que nous essayons d'obtenir, c'est ce que nous construisons ? Et il y a un tas de différents petits pas dans chacun d'entre eux, et c'est le genre de ce cours qui va faire sauter dans le Donc c'est juste une vue de haut en bas et je vais faire une plongée profonde, un peu plus tard. Donc, de toute façon, les exigences sont 1er 2ème est la conception. design est le Comment alors comment allons-nous le construire ? Qu' est-ce qu'on va utiliser ? Quel genre de technologies qu'on va mettre en place ? Comment avec le serveur va être installé ? Comment le front va-t-il être mis en place ? Le front end faire ceci ou cela ? C' est là que le design entre en jeu et que le design est très important. Beaucoup de gens ignorent cette étape. Ah, beaucoup de gens vont faire les exigences, mais ils vont faire les exigences, mais alors ils ne vont pas vraiment aller au design. Ils sont juste en quelque sorte sauter directement dans la mise en œuvre. Donc tu sais, ils seront comme, OK, on a une bonne idée de ce qu'on va construire. Sautons dans la mise en œuvre. Et cela pourrait être dangereux parce que encore une fois, il y a encore quelques variables ici, et il y a encore des choses que nous voulons nous assurer de travailler avant de les implémenter. Parce que, par exemple, disons que vous avez construit un chef-d'œuvre géant à huit serveurs ou au moins vous pensez que c'est un chef-d'œuvre. Et puis quand vous cliquez, vous connaissez le bouton de lecture, vous le faites enfin fonctionner. Tu réalises, Oh, ça ne marche pas avec huit serveurs. Il ne fonctionne qu'avec le service. Cela ne fonctionne qu'avec ce genre de technologie. Je vais devoir redémarrer et commencer dès le début. C' est le genre de choses que vous voulez travailler dans la partie design. La partie comment Après que vous allez concevoir, nous sauterons dans la mise en œuvre et tout le monde sait ce qu'est la mise en œuvre. La mise en œuvre est que vous construisez la chose. Donc tu as fait toute la planification. Tout le monde est sur la même page. Maintenant tu vas le diviser en peut-être que tu as des équipes. Peut-être que c'est juste un groupe de trois personnes. Peut-être que c'est juste toi-même, et tu vas juste entrer dans certaines et tu vas juste entrer dans certaines tâches et jalons. Mais la partie d'implémentation est la partie de construction que vous allez construire le produit, vous allez créer ce que vous avez prévu de créer, puis l'étape suivante est la vérification. Donc, avec la vérification, ce que nous faisons est quelque chose qui s'appelle le test. Nous essayons donc de trouver ici une question cruciale. Ce que nous avons construit, c'est ce que nous voulions construire ? C' est souvent des fois ah, couple des choses différentes. Ainsi, par exemple, ce que nous avons construit ce que nous voulions construire est ce que nous avons construit. Ce que notre client voulait que nous construisions, c'est ce que nous avons construit pour fonctionner correctement. Est-ce que c'est l'entrée en jeu ? Et c'est, vous savez, créer la bonne sortie. Et c'est pourquoi le test vient dans un jeu, et généralement avec les tests, vous devez connaître les exigences. Vous devez savoir ce qu'il était censé faire et ensuite avec le test Utkan contre cela ne fait pas ce qu'il était censé dio. C' est donc une étape très importante. Et c'est un autre qui est souvent une sorte de fois pour obtenir. Si le temps crunch les gens comme, Oh, non, ne vous inquiétez pas des tests fera juste quelques tests majeurs rapides et ensuite on passera à autre chose. Et ça pourrait être un gros problème parce que vous avez ces bugs géants dans votre programme. Peut-être qu'ils ne se manifestent pas avant quelques années, et ensuite cela mène à une violation géante de la sécurité des données. Ou peut-être que c'est juste quelque chose de très petit au fil du temps. Peut-être que toutes les données qui entrent dans la base de données sont désactivées d'une seule, et cela va en quelque sorte fausser vos données, et alors cela coûtera beaucoup plus tard dans la phase de maintenance, qui est cette phase juste ici pour finir par les réparer. La vérification et les tests sont donc importants. Nous aborderons certaines techniques à ce sujet et certaines des façons dont vous devriez tester. Et enfin, ce que nous avons, c'est que nous avons de l'entretien. Et c'est ce genre de cycle de fin où vous allez réparer des bugs. Vous allez aussi être en quelque sorte peut-être même faire plus de tests peut être implémenter d'autres choses , peut-être reconcevoir des choses. trucs de maintenance sont en quelque sorte la façon dont cela remonte beaucoup de fois. Si, par exemple, vous développez une fonctionnalité supplémentaire, vous retournerez en fait jusqu'aux exigences, puis recommencerez ce processus . Mais le cycle de maintenance est généralement juste de corriger des bogues, en s'assurant que, comme de petits ajustements pour le rendre plus conforme aux exigences et le garder en cours d'exécution pour me faire ne pas faire de mises à jour de serveur et mettre à jour cette technologie dans ce technologie. La maintenance est donc importante et la maintenance peut être très, très difficile si vous ne faites pas toutes ces étapes. Donc, il pourrait y avoir une tonne de bogues si vous n'avez pas tous ces bogues, et surtout s'il n'y a pas de documentation là-dedans. Donc tu n'as rien écrit ? Tu n'avais pas tout ce plan écrit. Ensuite, cela pourrait être très difficile parce que vous ne pouvez pas vraiment amener d'autres programmeurs. Il leur faudra six mois pour apprendre le code basé, etcetera, etc. Mais de toute façon, c'est la vue de haut en bas du cycle de développement logiciel typique. Maintenant, tout au long du reste , bien sûr, nous allons commencer à les décomposer un peu à peu, puis plonger en profondeur dans chacun d'eux et ensuite regarder des choses soignées comme des modèles qui sont tous, Comme, comment vous combinez ces différentes étapes la meilleure façon de le faire, vous savez ? Tu le fais comme un V où tu mets un peu de ça de chaque côté ? Est-ce que tu le fais ? Il y a ces choses appelées Scrum dans la chute d'eau signifiaient que ça va aller sur tout ça. Mais le cycle de développement logiciel, euh, vraiment bon à savoir. Et tu vas le voir beaucoup 4. Exemple de cycle logiciel: Passons un petit exemple pour aider à soumettre ceci juste un peu plus avant de commencer la plongée profonde dans chacun de ces domaines. Examinons un exemple ici. L' exemple va être simple. Ce sera juste comment construire un formulaire. Ou surtout ce que nous faisons, c'est que nous avons cet objectif. On veut construire un formulaire, il va avoir une adresse e-mail, et il va y avoir un lieu de commentaires et c'est tout. On veut juste voir ce qui s'est passé. On le fait. La conception des exigences, la mise en œuvre, etc. Sur. C' est un exemple très basique. Vous pourriez vraiment obtenir vraiment en profondeur et en fait venir avec un gros documents pour quelque chose d'aussi petit. Mais je veux juste passer en revue les bases. Alors, tu comprends quoi ? Comment chacun de ces domaines fonctionne un peu plus. Donc, le premier domaine que nous voulons examiner est les exigences. Alors, qu'est-ce qu'on veut que ce formulaire soit dio ? Nous voulions collecter des courriels, des adresses et des messages. C' est ce que nous voulons que le formulaire original fasse. Il va collecter une adresse e-mail et un message, puis a péché, aussi, aussi, et stocker dans une base de données. Il envoie donc ces informations sur Internet dans notre base de données. Et puis nous voulons empêcher l'utilisateur de mauvaise entrée dans ce moyen dans l'adresse e-mail, mettre tous ces symboles aléatoires et ne pas réellement créer une adresse e-mail dans la section commentaire . Vous savez, essayer d'insérer du code ou de faire une attaque par injection SQL ou quelque chose comme ça empêcherait ce genre de choses. Donc trois exigences de base ici, alors nous allons entrer dans notre conception. Que faire Comment pouvons-nous concevoir cela maintenant, avec la conception, vous pouvez venir avec un document ou vous pouvez réellement en quelque sorte le dessiner. Beaucoup de fois, vous avez besoin d'une extrémité frontale et arrière dans la conception. Donc, tu sais, peut-être qu'on a juste une boîte rapide. Ici, nous avons le lieu de courriel, puis le plus grand lieu de commentaire, et puis quand nous le dessinons, nous irons, Oh, en fait besoin d'un bouton pour soumettre cela. Alors peut-être voulons-nous mettre cela dans nos exigences. Nécessite un bouton. Exactement. Donc tu sais, juste quelque chose d'orteil. Tu pourrais toujours aller et retours entre les exigences du design, en fonction de l'utilisation du modèle et on en parlera plus tard. Tu pourrais toujours aller et retours entre les exigences du design, Mais avec notre conception, nous voulons utiliser HTML et CSS pour construire les cadres du formulaire. Donc, nous voulons construire le genre de ce que nous considérons en fait comme HTML et CSS. Ensuite, nous voulons utiliser JavaScript pour la vérification de l'entrée. Et puis nous voulons utiliser Jake fatigué dans mon SQL pour contacter le backend et Jake étaient vous n'avez pas entendu parler. C' est juste JavaScript, mais en quelque sorte ajusté. Ainsi, vous pouvez envoyer une sorte de requêtes de publication à une base de données, puis mon SQL est juste une base de données. La partie suivante est la mise en œuvre, et c'est vraiment, vraiment facile. C' est juste du code et du document. Le travail sera facile. En ce sens, ce sera en fait l'endroit où la plupart du temps est passé. Après avoir fait ces deux choses, c'est juste une sorte de travailler tout, mettre en place un serveur, mettre en place le front end et le JavaScript etcetera. Maintenant dans la vérification Beaucoup de fois la vérification, le test est juste une sorte d'extension des exigences. Nous posons des questions sur les exigences, alors collectez des adresses e-mail et des messages. Est-ce qu'un formulaire recueille des informations ? Nous créons donc un test pour tester les informations collectées, vous envoyer et stocker dans une base de données. Est-ce que le formulaire envoie ces informations à une base de données ? On pourrait faire des tests là-dessus. On peut voir, tu sais, dans, mettre à l'avant et ensuite aller vérifier notre base de données et s'assurer qu'il est dans le back-end. Faites peut-être des cas de coin en essayant d'insérer 100 navigateurs différents en même temps, ou en essayant de les insérer tous dans l'ordre, peut-être une demi-seconde l'un après l'autre. Peut-être qu'il y a une file d'attente qui est surchargée ou quelque chose, donc ce genre de tests aidera à s'assurer que vous ne perdez pas d'informations et ensuite empêcher l'utilisateur de frapper. Mais essayez de faire une attaque par injection SQL sur vous-même. Essayez de mettre des caractères vraiment aléatoires tout au long. Ce ne serait pas vraiment un message, peut-être même la prévention du spam. Peut-être que nous voulons construire une chose de prévention du spam ici, et nous devons mettre cela dans une exigence de conception. Mais nous testons cela aussi, et enfin nous avons la maintenance, qui est juste de créer un plan de cycle de vie et de corriger les bugs. jeu du cycle de vie pourrait être simple comme vérifier tous les six mois pour s'assurer que toute la technologie utilise le plus à jour et même avec la base de données mise à jour tous les six mois. Vérifiez tous les bogues, peut-être le mettre à jour tous les six mois. Ou peut-être que vous avez un horaire hebdomadaire de la façon dont les bugs entrent dans votre entreprise ou autre chose. Mais une maintenance est juste une sorte de trouver un plan pour s'assurer que nous pouvons l'ajuster exigences afin de répondre à ce que nous voulions faire et aussi pour s'assurer qu'elle n'est pas vulnérable. Et là, nous avons juste un exemple très, très simple de la façon dont vous pourriez passer par ces étapes, comment vous pourriez en quelque sorte catégoriser simplement la construction d'un formulaire simple. Maintenant, dans ces prochaines conférences, nous allons commencer à sauter dans la partie vraiment en profondeur où vous pouvez réellement utiliser certains des outils que nous parlons de construire pour faire ça. Mais pour quelque chose de bien, beaucoup plus grand à l'échelle 5. Définition des exigences en 2-1: commençons notre plongée profonde dans les exigences. Le premier que je vais examiner est la définition des exigences, quelque chose avec lequel nous sommes tous sur la même page. Donc, nous comprenons tous ce que je veux dire par exigences. Les exigences sont donc un moyen de déterminer les spécifications exactes de ce que le logiciel devrait faire. Vous pouvez penser à des exigences comme une définition. Vous définissez ce que le logiciel devrait faire. C' est comme si vous étiez à la recherche dans un livre et vous êtes capable de lire exactement ce que le logiciel devrait dio. C' est important. Nous n'essayons pas de comprendre comment il devrait être créé. Nous essayons juste de comprendre ce qu'il devrait faire à la fin. Si l'utilisateur interagit avec lui ici ou pour, vous savez, et que l'utilisateur interagit avec lui, que va-t-il se passer ? Qu' est-ce qu'on veut que les orteils arrivent ? Quel est le but de ce système ? C' est pourquoi il s'agit d'un processus pour déterminer les objectifs d'un système. Donc, à la fin, les exigences essaient juste de trouver les objectifs du système. Ce que nous voulions accomplir cela reflète le quoi et non la façon dont c'est important, c'est que nous essayons juste de comprendre ce qui n'est pas comment nous essayons de le créer. Le comment est pour le design. Beaucoup de gens pourraient venir avec une exigence de va utiliser C, S S et HTML pour construire le front end. Et ce n'est pas une exigence. C' est trois. Comment c'est ce que nous allons utiliser pour construire le front end. conséquent, Parconséquent, cela fait partie de l'exigence de conception. Peut-être. Utilise un champ d'adresse e-mail pour capturer l'adresse e-mail. Ou nous voulons capturer l'adresse e-mail et un commentaire. Donc on ne dit pas comment on va faire ça. Nous n'essayons pas de définir la technologie sur la façon dont nous essayons de le faire. Nous disons juste, Que voulons-nous que l'utilisateur puisse faire ? Qu' est-ce qu'on veut ? L' objectif final à être ? Et dans l'ensemble, les exigences créent généralement un document qui expose tous ces détails. D' habitude, il y a des listes de puces ou il y a, vous savez, s'il est vraiment officiel, vous avez s'il est vraiment officiel, vous avez besoin de deux A ou quelque chose comme ça. Mais souvent, si vous travaillez juste pour des entreprises comme, moyennes ou petites, ce sera juste une sorte de liste des choses que vous voulez accomplir et des cas d'utilisation que vous voulez faire avec les utilisateurs. Alors parlons de l'importance des exigences. Pourquoi avons-nous utilisé les exigences ? Quoi ? Qu' est-ce qui nous sauve en fin de compte ? On dirait que, tu sais, on passe juste plus de temps. On pourrait bien recouvrir avec toute l'ingénierie. Et c'est important. C' est de l'ingénierie ? Vous dio n'importe quelle ingénierie vous dio vous avez ce genre de règle d'or et la règle d'or est que passer du temps stratégiquement à l'avance réduit le coût et le temps plus tard. Maintenant, ce sont des données d'une étude qui ont montré que si vous avez passé du temps stratégique à partir de la raison pour laquelle je dis stratégique, c'est pas seulement parler, vous savez, avant qu'on ne conçoive la chose juste pour parler, Vous savez, 40 heures nous voulons être, vous savez, vous savez, travail ciblé ici, le concevoir, trouver des problèmes potentiels, trouver tous les cas d'utilisation possibles, vous savez, créer fondamentalement le code avant même de toucher le code. C' est de ça que je parle. Donc, passer du temps stratégiquement à l'avance réduit les coûts et le temps plus tard, et c'est une sorte de tendance ici. Non, Lotus, que la tendance est un peu comme cette tendance de perte de temps. Donc, il y a un moment où cela ne vous aide pas à utiliser plus de temps d'avance. Donc, vous savez, si nous allons à moins de 50 % de tous les temps, ça ne changera pas beaucoup ici. Cela ne va pas vraiment réduire le coût de dépassement. Vous remarquez que cela ne descend pas à zéro. C' est parce que la plupart des projets dépassent toujours plus de 40%. Le budget est en quelque sorte la norme, et souvent il se lève en grand nombre parce que les gens ne planifient pas en conséquence. Mais cela ne fait que dire du temps total ici. Donc, c'est le temps total. Ce dont nous parlons, c'est si nous passons 0% de notre temps, donc nous ne passons absolument pas de temps à l'avance. Le coût standard est de 200 %. Si nous dépensons environ 3 % et 5 %, nous avions 100 % et 50 % alors nous avons été 5 % de tout notre temps très, très peu de temps, vous savez, s'il a passé 100 heures, nous parlons de 5 heures à l'avance, Je passe juste sur ce truc. Nous pouvons nous épargner 150% de dépassement supplémentaire. Et cela coûte plus cher en dollars et dans le temps. C' est donc aussi ce sont les deux habituels parce que les deux vont de pair l'un avec l'autre. Si ça prend plus de temps, ça va coûter plus cher. Vous payez à vos ingénieurs votre paiement pour les soins de santé, votre peine pour les impôts. Tu paies tout ça. Et plus il te faudra de temps pour commencer à te faire de l'argent, plus ça va coûter. Et puis si on va de 10 à 20 %, on obtient cette zone dorée où on obtient juste les 40 % de dépassement. Et donc tu sais, quelle est la différence entre ça ? Disons que nous dépensons 0% à l'avance et que le produit aurait dû prendre 200 heures. Eh bien, c'est juste un simple calcul ici va avoir un dépassement de 200%, ce qui signifie qu'on cherche 100 au total sera 400 donc 200 % de plus sur ce sera environ 600 heures pour terminer ce projet alors qu'il n'aurait fallu que 200 C'est géant saut géant juste là du temps qu'il aurait dû prendre où si on mettait juste 5%. Donc, dans ce 200 notre projet, si nous venons de désigner 5 % ou 10 heures, alors nous serions sur Lee à un dépassement de 50 %, ce qui signifie que notre total serait de 300 heures. Donc, avec 10 heures d'efforts ici, nous nous sommes réellement épargnés 300 heures de problèmes back-end. Et c'est juste un peu comme le pouvoir de tout cela, c'est que passer du temps à l' avance aide à répondre aux besoins. Document est l'une de ces choses à passer le temps à l'avance et même avec le document de conception . Mais ces deux éléments sont très importants. Ils nous mettent sur la même page et ils nous font travailler efficacement. 6. Les exigences en 2-2 et les spécifications: Il y a quelques catégories différentes chaque fois que nous parlons de toute l'étape d'arche des exigences. Et ces catégories ont défini différents aspects du système que nous essayons de construire dans cette conférence. Ce dont nous parlons, ce sont les exigences et les spécifications, donc il y a une différence majeure entre les deux et vous verrez au début qu'elles ressemblent assez . Mais chaque fois que vous commencez à plonger dans ce genre de choses, vous comprenez qu'il y a une importance entre les deux. Le verset dont on va parler sera les exigences. Donc, avec les exigences, quelles seront nos exigences. Une exigence est une définition non technique de quelque chose que l'utilisateur exige du système . Ce que cela signifie, c'est qu'il est mis en termes profanes. Il devrait être compris par n'importe qui. Donc pas de jargon. Ce genre de jargon ne parle pas d'informatique, pas de jargon de programmation. Si vous faites comme un formulaire médical, vous connaissez notre quête de forme de traitement. Vous pouvez mettre en jargon dans le domaine médical ou dans le domaine de la construction dans l' exigence de l'utilisateur , parce que notre public sera, vous savez, le domaine médical du domaine de la construction ou l'application Domaine de développement. C' est parfaitement OK. Cependant, nous ne voulons pas mettre dans est jargon comme mon SQL ou Jason quelque chose que cela devrait pouvoir être lu par le directeur de la construction ou par, vous savez, le directeur de l'usine automobile. Il devrait pouvoir lire cela et comprendre. Oui, c' est ce qu'on veut dans notre système. Donc, avec les exigences, nous ne voulons pas de jargon informatique. Ainsi, par exemple, une exigence pourrait être la capacité de soumettre une demande de formulaire médical de traitement. Savez-vous ce qu'est un formulaire de demande de traitement ? Pas vraiment ? Ça n'a pas d'importance pour nous. Ce que nous savons, c'est que nous avons parlé au client et ils disent qu'ils veulent la possibilité de soumettre une demande de traitement, formulaire médical et avec cette affaiblir Demander à ce sujet plus tard. Mais nous savons que ce serait un formulaire médical, donc il devrait y avoir une certaine sécurité là-dedans. Ça va être une sorte de formulaire de contact de la demande de traitement, et ça va être notre exigence pour cette étape. Et puis, comme je l'ai dit plus tard, nous pourrons clarifier avec eux exactement ce qu'ils signifient. Ensuite, nous avons ces spécifications, donc les spécifications sont essentiellement des notes techniques, notes sur ce qui doit être fait pour répondre à l'exigence. Donc, dans cette situation, c'est une définition technique de ce qui est exigé du système. On va rester simple. Nous n'essayons pas de le concevoir ici. C' est très important. C' est la plus grosse erreur que vous n'avez pas essayé de concevoir. Ce que nous essayons de faire est juste, fondamentalement, bien que quelques mots-clés de haut niveau ici. Nous comprenons donc l'importance de certains aspects de l'exigence. Donc, dans cette situation qui sort de cette exigence, une spécification pourrait être d'envoyer A s à 56 données de formulaire cryptées de l'interface frontale au serveur principal. Vous remarquerez qu'on a un peu de jargon là-dedans. On est arrivés à l'avant et on est rentrés. Nous avons un S C 2 56 crypté, mais rien de tout cela ne définit la technologie. On n'utilisera rien de tout ça en disant qu'on va le prendre et le passer comme ça à travers ce médium, comme, tu sais, une sorte d'explication très profonde. Vous remarquerez que c'est l'erreur. C' est ce que nous avions mis dans le document de conception que nous allons utiliser encryption, qui est une technologie pour crypter les données dans JavaScript pour envoyer A S à 56 crypté. Jason s'est formé à nouveau. C' est une façon de se former. Nous n'avons pas besoin de connaître exactement la technologie que nous utilisons formée à partir de JavaScript. C' est une technologie pour mon serveur SQL, etcetera, etc. Il y a trop de jargon là-dedans. Il y a trop de choses qui définissent la façon dont le projet va être construit. Ce n'est pas le but de cette phase. Tout ce que nous essayons de dire, c'est qu'il nous faut des données cryptées. Nous préférerions que ce soit le Secure A es 2 56 Et vous savez, aujourd'hui c'est probablement nous voudrions utiliser une technologie différente, mais c'est juste pour l'exemple. Mais de toute façon, nous voulons utiliser A S à 56 nous voulons le prendre de l'extrémité frontale, où l'utilisateur peut se connecter au back-end. Plus besoin d'informations après cela. Lorsque nous arrivons à l'ensemble de conception, nous pouvons commencer à introduire les technologies que nous allons utiliser. Alors passons en revue quelques exemples ici. premier exemple est de retourner dans le monde réel. Parlons de la création d'un pneu VUS. Et avec ce pneu VUS, ce dont nous allons parler est fondamentalement juste une exigence simple et dans certaines spécifications qui pourraient aller avec cette exigence afin que nous puissions à nouveau voir la différence entre les deux. Typiquement, chaque fois que nous parlons de ce truc, nous allons dire les exigences de l'utilisateur et le système Sessa vacances. Ce que cela signifie, c'est que c'est en quelque sorte le définir. Donc, tout le monde est sur la même page chaque fois que nous parlons des exigences était de parler ce que l'utilisateur veut être en mesure de dio. Jamais. Nous parlons des spécifications du système. Nous parlons de la façon dont le système devrait fonctionner fondamentalement, de sorte que certaines contraintes certaines des exigences avec le système lui-même. Donc, l'exigence de l'utilisateur disait que le pneu doit fonctionner sur une automobile de type SUV. Ou peut-être que l'utilisateur doit être capable de mettre le pneu sur une automobile de type SUV. Tout avertissement de cela capture le point. Nous avons un utilisateur. Il veut pouvoir prendre ce pneu et le mettre sur une automobile. C' est ça. Maintenant, les spécifications. Qu' est-ce que ce pneu a à faire ? Qu' est-ce que ça veut dire ? pour prendre un pneu et le mettre sur une automobile de type SUV. Et encore une fois, vous voyez, c'est un tout petit peu de jargon, mais c'est bon parce que nous sommes dans l'industrie automobile. Par conséquent, nous pouvons utiliser le jargon de l'industrie automobile ici. On ne parle rien de spécifique tant qu'on n'arrive pas à cette partie. Donc ce que nous allons juste dire, c'est que le pneu doit pouvoir supporter jusqu'à 7500£ de pression à la baisse. Le pneu doit s'adapter à tous les points standards pour le montage du pneu doit s'adapter à toute la sécurité de la poussière. Euh point normes de sécurité et le pneu doit avoir du thé ou une meilleure qualité de vitesse. Vous n'avez pas besoin de savoir ce que l'un d'entre vous sait que cela signifie, mais ce que vous pouvez voir, c'est que nous avons ici l'exigence très fondamentale. Et ici, nous spécifions juste certaines des choses que le pneu devrait dio. On ne parle pas de la chimie exacte du caoutchouc qui devrait être utilisé. Nous ne parlons pas de la pression d'air à l'intérieur du pneu pour acquérir les 7500£ de pression d'air . On ne parle pas de design. Il ne s'agit que de certaines contraintes, de certaines choses que nous devons mettre en œuvre dans ce pneu. Enfin, revenons un peu trop dans le monde de la technologie. Nous avons donc maintenant cette autre exigence. Les utilisateurs devraient être en mesure de télécharger une vidéo sur le site Web. Nous avons ce grand site web. Il y a 100 de ces exigences et ce n'est qu'une des exigences. Ceux-ci devraient être en mesure de télécharger une vidéo sur le site Web. Donc maintenant, nous avons juste quelques spécifications ici. Que devrait accepter l'utilisateur ? H 0.264 déplacer et fichiers mpg pour le téléchargement Ces catégories seulement. On ne dit pas comment ils vont être, sauf qu'on ne dit pas la technologie qu'on doit utiliser pour les accepter. Comment vont-ils ? Que devrions-nous être en mesure d'accepter ? Ce que nous entendons par vidéo. Et donc nous sommes en quelque sorte de spécifier qu'avec cela juste un peu, puis le chargement du chargeur haut devrait compresser la vidéo et enregistrer trois copies différentes le serveur à nouveau. Ce n'est pas quelque chose que le nouvel utilisateur a vraiment besoin de savoir. C' est juste quelque chose que nous, concepteurs de ce site, regardons et disons tard, que nous allons vouloir prendre cette vidéo et l'utiliser de certaines façons. Nous devrions le compresser et le sauvegarder à nouveau sur le serveur. Nous ne mentionnons pas le type de serveur. Nous ne mentionnons pas les dimensions des trois vidéos. Juste il devrait avoir la capacité de le faire. Et puis, enfin, un lien vers la vidéo compressée dépend de la façon dont nous voulons qu'elle soit. Doit être envoyé par e-mail à l'utilisateur après l'achèvement. Encore une fois, nous ne parlons pas des serveurs de messagerie ou de la façon dont nous allons formater l'e-mail ou vous savez à quoi le lien devrait ressembler. Comment le lecteur vidéo, n'importe quoi de ces trucs. On ne parle pas de ça. Nous parlons juste d'un cahier des charges ici. Le lien, fois qu'il est fait, doit être envoyé à l'utilisateur. Et bien sûr, ce n'est peut-être pas tout à fait inclusif. Il pourrait y avoir d'autres choses que nous devons nous asseoir et commencer à marquer un peu plus. Ceci et peut-être que nous avons une autre exigence. Par conséquent, nous avons besoin d'encore plus de spécifications, etcetera, etcetera. Mais j'espère que dans l'ensemble, vous aurez l'idée de ce que la différence entre une exigence et les spécifications est exigence traite avec l'utilisateur. C' est très basique. C' est en termes de profane, quelque chose qu'un client peut regarder et aller. Oui, le programme devrait certainement être capable de le faire ou non, Peut-être que cela ne définit pas exactement ce que nous voulons. Et puis les spécifications du système sont comme nos notes. C' est comme les notes du développeur disaient, Ok, donc l'utilisateur veut que Bill le fasse, et ce qu'il veut vraiment, c'est qu'il puisse télécharger ces types de fichiers. Il doit être en mesure de le faire avec les besoins des pneus pour répondre à ces normes, et c'est à cela que les spécifications du système se réfèrent. 7. 2-3 fonctionnel et non fonctionnel: les deux autres catégories dont nous devons vraiment discuter lorsqu'on parle d'exigences sont les vers non fonctionnels, les exigences fonctionnelles. Alors, quelle est la différence entre ces deux-là ? Les exigences fonctionnelles sont-elles des exigences et des spécifications relatives à la fonction du programme ? C' est le mot clé ici. C' est la fonction du programme ici. Donc, ce dont nous parlons, c'est de quoi le système devrait être dû ? En fin de compte, ce que le système devrait pouvoir accomplir était de construire un formulaire. Nous descendons la liste des choses que le formulaire devrait être capable de dio Il devrait recueillir des données. Il devrait envoyer des données qu'il devrait protéger contre l'entrée. Il devrait le faire. Il devrait le faire maintenant. Non fonctionnel sont les exigences et les spécifications relatives aux objectifs à atteindre. Par exemple, la sécurité. Quel devrait être le formulaire maintenant chiffré ou coûter ? Comment le temps est-il limité ? Peut-être combien de temps le formulaire devrait-il prendre pour le soumettre ? Donc peut-être que le formulaire devrait soumettre des données au serveur et ici dans l' exigence non fonctionnelle . En plus de cela, il devrait soumettre des données dans un délai de 500 millisecondes. Disons que ce n'est pas quelque chose que ce que le système dans son ensemble fait donc, ce n'est pas fonctionnel. C' est quelque chose qui est une contrainte. C' est quelque chose qui a besoin orteil arriver avec la fonctionnalité ici, nous pouvons jeter un oeil à non examiné qui a passé plus tôt. Alors rappelez-vous le Send A à 56 crypté formé à partir de yada yada. On peut décomposer ça pour en faire un peu fonctionnel et non fonctionnel. Ainsi, le 1er 1 est péché, formé à partir de l'avant et d'un serveur back-end. Qu' est-ce que ça fait ? Eh bien, c'est une fonction. Ça prend des données, et ça lui envoie sa définition. Que sont exactement les produits devraient faire ? Et donc pour celui-ci, nous parlons d'une exigence fonctionnelle. Maintenant, le bas est un non fonctionnel. Vous pouvez voir que j'ai pris toute la partie de cryptage de ceci pour en quelque sorte les briser et vous verrez que chaque fois que vous avez raison les exigences, les choses ont un peu de désordre peuvent réellement se combiner à, et ce n'est pas une science exacte. Cependant, passant par elle, vous pourriez être en mesure d'assommer certaines de ces choses et la figure Attendre, Nous devrions les mettre dans deux catégories distinctes. Une sorte de choses. N' importe quel espoir. La partie inférieure. La partie de chiffrement est non fonctionnelle, non fonctionnelle. Beaucoup de fois est référé à son gouvernement non fonctionnel NFR, et c'est le fr. Beaucoup ont dû décoller les sont si non fonctionnels, euh, euh mais de toute façon, ce n'est pas quelque chose que le programme devrait faire. Ce n'est pas une opération. Ce n'est pas quelque chose que l'utilisateur fait que vous connaissez. S' il ne peut pas le faire, il y a quelque chose qui ne va pas avec le produit. C' est une exigence. C' est quelque chose qui devrait se produire avec les exigences fonctionnelles. Donc, l'exigence fonctionnelle est l'envoi des données du formulaire. Et puis l'exigence non fonctionnelle est qu'il devrait être chiffré qu'il ne prenne que 500 millisecondes, qu'il devrait l'envoyer à trois serveurs différents avant qu'il n'arrive à notre serveur. Pour une raison quelconque, c'est le non-fonctionnel derrière ça maintenant. Non fonctionnel a également quelques petites catégories différentes, et ce que ces catégories sont fondamentalement quelques-unes des différentes sortes de larmes de non-fonctionnel, et vous commencerez à les comprendre juste un peu ici. Plus le 1er 1 est les exigences du produit, quelque chose que le produit doit faire à nouveau. Ce n'est pas quelque chose que ce produit agit, vous savez, avec l'environnement sans changer quelque chose. C' est juste une façon de concevoir le produit, une façon de l'intégrer au monde. Et disons que vous avez un client qui est, peut-être qu'il loue la capacité de créer ce logiciel, mais à la fin, il veut le maintenir lui-même. Par conséquent, il en a besoin revêtu dans un langage spécifique. Java. On ne parle pas de design ici. n'y a pas d'aller-retour. C' est une exigence. C' est quelque chose qu'il dit. Le programme doit être codé en Java. C' est ça. n'y a pas de discussion sur ce point. Par conséquent, cela devient une exigence maintenant. Est-ce la façon dont le problème fonctionne ? Par exemple, nous pourrions créer une page Web qui a un formulaire que nous pourrions créer en Java ou CSS et HTML et JavaScript, ou peut-être même python ou ruby. Nous pouvons créer dans tous ces différents, donc peu importe le langage de codage. Cela ne fait pas partie de la fonction du programme qui n'est pas une exigence fonctionnelle, quelque chose que nous devons faire. Mais le programme ne réagit pas à cause de cela. Par conséquent, nous avons ce non fonctionnel et c'est une exigence du produit. Ensuite, nous abordons les exigences organisationnelles, et cela se résume généralement aux politiques et aux normes, aux styles et aux règles de l' organisation dans laquelle vous travaillez et avec laquelle vous travaillez. Ainsi, par exemple, l'organisation avec laquelle vous travaillez est peut-être une organisation militaire. Et ils disent que chaque fois que les données changent de mains, doivent être cryptées. Peu importe si son interne ou externe, il doit être crypté. Par conséquent, l'un de nos crimes organisationnels. Ce serait les données du produit doivent être cryptées par ES 2 56 Et encore une fois, je l'utilise tout le temps. C' juste parce que c'est un algorithme de cryptage facile, bien sûr, norme militaire. Il y aura probablement quelque chose bien plus fort, mais peu importe. C' est la technologie ici. Ce dont je parle, c'est qu'ils nous disent qu'on doit utiliser ça. Ou peut-être que c'est notre propre politique d'entreprise. Quoi qu'il en soit, il ne s'agit pas de la fonction du programme et de la façon dont il interagit avec le monde qui l' entoure. Il s'agit de la façon dont il devrait être élaboré et de ce qui devrait se passer dans le cadre du programme. Et enfin, pour l'organisation que nous avons, le projet sera développé à l'aide de la méthodologie mêlée. Nous sommes dans une entreprise qui utilise de la mêlée et il n'y a aucune dispute à ce sujet. On ne parle pas de ça, donc quand on arrive à la phase de conception, ce n'est pas une question qui n'est pas quelque chose que des ingénieurs se réunissent pour trouver . Par conséquent, c'est une exigence. On est dans une entreprise. Il utilise de la mêlée. donc C' estdoncune exigence. Et il ne parle pas de la façon dont le programme interagit avec le monde, ce que je dis sans cesse, mais j'essaie de forer cette maison. Par conséquent, il s'agit d'une exigence non fonctionnelle. Ensuite, nous entrons enfin dans les exigences externes et c'est juste quelque chose. Chaque fois que nous parlons de choses externes qui poussent en quelque sorte notre produit et cela pourrait être des lois ou des règlements externes ou même des tendances que nous devons suivre et donc ce que nous avons c'est que nous avons ces lois qui se réunissent pour répondre à ces exigences. Par exemple, disons que l'U l'Union européenne a une loi, vous savez, la loi sur la liberté, article 1, section 2, qui stipule que toutes les données doivent utiliser ce genre de cryptage SSL cryptage entre les points de données ou autre. Ça doit être une exigence, parce que si on veut concevoir, c'est un logiciel qu'on vend au U, ça doit correspondre à ça. Sinon, personne ne l'achètera. Et s'ils le font, nous serons poursuivis par le gouvernement, et notre produit sera essentiellement une responsabilité envers nous au lieu d'un actif. Et on ne veut pas ça. C' est donc une exigence externe. Il pourrait y avoir aussi certaines tendances. Peut-être y a-t-il une certaine tendance en matière de sécurité ou une certaine tendance, comme la page Web doit pouvoir se charger en deux secondes. Beaucoup de gens quitteront les pages Web s'ils ne se chargent pas dans les deux secondes. Cela ne montre pas quelque chose qui n'est pas exactement, ah, la loi ou la réglementation, mais c'est une tendance. C' est quelque chose que nous devrions avoir de la faute. C' est quelque chose qui devrait être mis en œuvre dans notre programme si nous voulons être concurrentiels sur le marché afin que nous puissions établir ici et aussi des exigences externes. Mais c'est la dernière classification des exigences ici. On a ces non fonctionnels. On a ces exigences fonctionnelles. Rappelez-vous juste une exigences fonctionnelles comment le programme interagit avec le monde qui l'entoure . Ça change quelque chose. Ça bouge quelque chose. L' utilisateur est capable de faire quelque chose en raison de cette exigence. Alors que les exigences non fonctionnelles sont les choses que le programme devrait être en mesure de faire leurs choses qui n'ont pas nécessairement interagi avec le monde. Mais ils nous contraignent. Ils nous obligent à faire quelque chose. Par conséquent, ils doivent être inclus dans leurs documents d'exigences. 8. Introduction à ce modèle WRSPM: Alors passons dans le premier modèle du cours, et ce sera un modèle qui encapsule en quelque sorte l'ensemble de la production de logiciels . C' est quelque chose qu'on appelle le modèle W. R S P M ou, en bref, le modèle mondial de la machine. Et ce que ce modèle, les photos, c'est l'interaction entre l'environnement et le système. Et c'est important parce que vous devez comprendre qu'il y a beaucoup d'aspects différents qui entrent dans un logiciel que beaucoup de choses différentes que vous pourriez ne pas penser à qui vous devez penser lors de la conception d'un logiciel. Par exemple, chaque fois que vous avez une application sur votre ordinateur, vous devez disposer d'un périphérique d'entrée et de sortie pour communiquer avec cette application. Donc, par exemple, si nous utilisons quelque chose comme un logiciel de retouche photo pour modifier réellement les photos, nous devons non seulement faire le programme lui-même, mais nous avons également surmonté le matériel sur lequel il fonctionne, qui va être votre ordinateur personnel, et vous devez avoir des périphériques d'entrée. Donc, par exemple, un clavier et une souris, et puis en plus de cela, vous devez avoir l'être humain qui interagit réellement avec tout cela et comprend comment tout utiliser. C' est donc une façon de catégoriser cela afin que nous puissions examiner les exigences d'un système et voir si nous manquons quelque chose pour le regarder. Et est-ce qu'on manque une hypothèse qui était censée faire ? Y a-t-il un élément particulier que nous ne prenons pas dûment en compte ? Cela nous permet juste de mettre ceux qui finissent au bon endroit. Donc, le côté gauche de ce diagramme de Venn est quelque chose appelé l'environnement, et c'est là que le système va fonctionner à l'esprit. Par exemple, une équipe est quelque chose qui est utilisé assez souvent pour catégoriser cela. Donc, par exemple, nous avons une machine A T. M ici, et si vous vivez dans un autre pays, c'est un distributeur d'argent. Je connais différents pays appelés des choses différentes en Amérique. Ça s'appelle un guichet automatique T M. Fondamentalement, vous y allez et vous obtenez de l'argent. Assez simple, mais vous devez penser que c'est une équipe. Il fonctionne dans le monde, la sphère du monde, et puis il y a un programme à l'intérieur. Il y a un petit programme en cours d'exécution, puis il se connecte à quelque chose à l'extérieur. Peut-être qu'il va à un grand serveur ou à des banques ou quelque chose comme ça. Mais il y a tous ces différents éléments qui entrent dedans. Le côté gauche de l'environnement. Dans quoi fonctionne notre système ? Et ici, nous avons deux sortes de zones différentes ou deux choses différentes que nous regardons et le 1er 1 est W. Et le W est que nous allons voir que nous allons passer par toutes ces lettres. Voici le monde. C' est le W juste ici. Donc, le monde, cela se résume généralement à des hypothèses que nous devons faire chaque fois que nous fabriquons un logiciel. Et cela pourrait être vraiment, vraiment une sorte de simple et presque citer des hypothèses stupides sans citer. Mais ils doivent être faits,par exemple, par exemple, au sein d'une équipe que nous devons faire. Une des hypothèses mondiales est qu'il ya une banque de l'autre côté qui a de l'argent que cela il ya un but à cela une équipe qu'il ya une entité qui est en fait garder trace de ces transactions, et donc l'équipe a but. L' une des hypothèses pourrait donc être qu'il y a des banques, que l'argent existe, que leur argent est une sorte d'entité. Maintenant, bien sûr, vous pourriez ne pas être en mesure de terminer, vous savez, une meilleure façon de concevoir votre programme avec cette hypothèse. Mais en mettant l'hypothèse là-dedans, vous commencez à comprendre le programme un peu mieux. Et puis vous arrivez à des choses importantes, comme l'équipe A. Doit-on avoir l'hypothèse que l'équipe A où cette machine sera toujours connectée à l'électricité Maintenant, c'est une chose importante, parce que vous pourriez penser que vous voulez la mettre dans ah city qui a peut-être pas le meilleur réseau électrique. Peut-être qu'il s'allume et s'éteint toutes les 30 secondes sont 30 minutes. Peut-être, tu sais, un ou deux jours par semaine. Il a une coupure de courant d'une heure ou plus. C' est une hypothèse à laquelle tu dois penser. On veut que l'équipe A s'arrête ? Voulons-nous avoir une batterie de secours ? Voulons-nous que le programme soit réinitialisé ? Qu' est-ce qu'on veut faire de tout ça ? Et c'est donc très important. Chaque fois que vous passez en quelque sorte ce truc est de comprendre ces hypothèses, sorte que vous ne manquez aucune exigence, et c'est la partie suivante est les exigences. Donc le système est une sorte de ce côté des choses. Et avant de construire le système, nous devons comprendre dans une idée conceptuelle, Qu'est-ce que nous construisons ? Que fait ce système ? Quel est le but ? Qu' est-ce qu'il essaie d'accomplir ? Quel problème résolve-t-il ? Et c'est là que les exigences entrent en jeu. Cela fait partie de l'environnement, parce que l'environnement a créé un problème. L' environnement a généré un problème, ce soit juste un problème passif, quelque chose que nous pensons, Hey, cela pourrait être corrigé ou si c'est un problème réel, quelque chose où étaient quelque chose que les humains ont peut-être créé ou que la société a créé des heures supplémentaires et donc nous travaillons. Nous créons nos exigences. Ensuite, l'étape suivante est que nous entrons dans ce genre de mélange entre l'environnement et le système, et c'est là que nous entrons dans les spécifications. On a mis le S ici. Les spécifications vont sur le genre de, euh, les détails du système. Donc on est toujours dans ce truc d'environnement. Nous sommes encore dans la résolution du problème, cependant, étaient également la construction du système étaient également de déterminer ce que la meilleure chose pour le système est. Nous obtenons des détails techniques, donc c'est là que nous construisons le mélange. Cette partie est beaucoup de fois appelée l'interface étaient la construction de la branche entre l'environnement et le système, le terminal pour connecter le monde à ce programme. Et cela, bien sûr, nous amène au prochain ici, qui est le programme. Et maintenant, nous sommes dans le système. Donc, le programme est le code lui-même. Le programme est ce qui est en cours d'exécution. C' est les déclarations if else. Il contrôle le matériel. Il saisit les données. Il envoie les données. C' est ce que le programme est. Il n'y a rien à avancer là-dessus, mais c'est en quelque sorte la plus grande partie du développement logiciel est en fait de créer le programme , et c'est pourquoi nous allons en parler essentiellement pour le reste du cours, et enfin, nous avons la machine, et c'est important parce que nous devons comprendre sur quel matériel fonctionne-t-il ? La machine est l'équipe A elle-même. Il voit l'entité réelle Ah, le ram, le CPU les câbles réseau, les serveurs du fournisseur de services Internet. C' est tout ça. C' est l'entité physique sur laquelle le programme va s'exécuter. Et c'est important de savoir, parce que peut-être nous dissoudre le programme qui a besoin d'utiliser un Internet. C' est, je ne sais pas, peut-être 100 mégaoctets par seconde. Et nous nous rendons compte que nulle part ne transporte cet Internet pour un t. M. Donc nous devons retravailler nos exigences. Peut-être que nous devons ajouter une exigence où elle doit être inférieure à 10 mégaoctets par seconde, des choses comme ça. Donc c'est juste important à considérer tout au long de ce maintenant est aussi une autre petite catégorie ici, et nous pouvons créer ces autres petits cercles comme ça. Et ce qu'on a avec ça c'est qu'on a quelque chose appelé E h E V. Et puis on a, euh SV S H Et alors quoi ? Ce sont ils signifient juste environnement, environnement caché, logiciel visible visible et logiciel caché. Donc environnement, environnement caché, logiciel visible ou système visible caché. Et ce qu'ils sont, c'est juste qu'ils ont déterminé un peu plus en sorte de classer l'environnement. Donc, avec l'environnement caché, nous avons des choses comme des idées et des morceaux de données que ah, humain sait par exemple, e h serait un numéro de pin. C' est une donnée. C' est un concept. C' est quelque chose que nous devons incorporer. Quoi qu'il soit caché, il ne sera pas vraiment disponible pour. L' utilisateur n'est pas posté sur le côté de l'A T. M. C'est quelque chose sur Lee. Un être humain sait dans son esprit. Par conséquent, il s'agit d'une variable d'environnement, qui est cachée. Ensuite, nous avons l'environnement visible. Un environnement visible est les choses qui sont réellement exposées au monde réel. Chaque fois que vous entrez réellement ce numéro de broche dans le système, il devient désormais visible. Il devient citation sans citation d'acier à base de plantes. Quelqu' un pourrait regarder par-dessus ton épaule et prendre ça. Donc, beaucoup de fois l'environnement visible est les données qui sont réellement entrés dans ce genre de concepts dans votre esprit quand ils sont réellement entrés dans le système. Et puis vous avez quelque chose connu un système visible, et c'est assez simple. Ce sont les parties visibles du système. Ce sont les choses avec lesquelles nous interagissons sur un ordinateur qui seraient le clavier et la souris sur une machine A T M. C' est l'endroit où vous insérez la carte. C' est le stylo. C' est la façon de le traverser. Donc, c'est le genre de l'extérieur de l'interface, la façon dont nous nous connectons avec les choses. Et c'est pourquoi vous pouvez voir que tout cela fait partie de cette interface. Ici, nous avons des données qui sortent de l'abstrait, ce qui signifie, comme pas concrètes. C' est juste des informations stockées dans nos esprits ou peut-être sur un autre appareil entrant dans l'interface. Et avec cela, nous entrons dans la partie visible de la machine. Donc c'est, vous savez, la partie visible, la partie visible de la machine. Donc, par exemple, ce serait dans cette petite zone où il a entré les choses. Et puis nous avons des logiciels cachés et des logiciels cachés ou continuons à dire des logiciels. Mais le système caché est le backend. C' est ce bélier à l'intérieur. Nous n'avons pas besoin de connaître le fonctionnement interne d'un A t. M. Nous appuyons sur un bouton. Les travaux internes de l'équipe A font ce qu'ils sont conçus pour dio. Même avec beaucoup de logiciels. Nous, vous savez, si nous prenons deux côtés d'une image qu'ils lisaient dans une image et nous le voulons. L' image ressemble à ceci, et nous voulons faire pivoter l'image vers la droite. Nous cliquons sur n'importe quel bouton dans notre logiciel qui, vous savez , a peut-être, comme ce bouton fléché dessus, et il tourne. Nous n'avons pas besoin de connaître le code qui va dans ça. On n'a pas besoin de le savoir. Prendre tous les zéros et appliquer une formule et faire tout ça. C' est la partie cachée. Le système visible est ce bouton que nous pouvons appuyer. Et donc ces choses air à nouveau que vous voulez considérer chaque fois que vous créez ces variables ou juste, ah, ces exigences ou le genre de portée de problème est juste vouloir comprendre Quel est l' environnement Caché ? Quel est l'environnement visible ? Quel est le système visible ? Quel est le système caché ? Tu fais un gros logiciel. Ces choses sont vitales pour comprendre le nôtre complet du problème. Ensuite, les conférences étaient en train de se dérouler. On va continuer à plonger là-dedans, alors continuons. 9. 2-5 Plonger en profondeur avec WRSPM: Maintenant, nous avons une meilleure compréhension du modèle de PM WRS peut être une sorte de compréhension approximative de celui-ci. Jumentons dans quelques exemples et expliquons plus en détail chacun de ces domaines. Donc, ils étaient tous sur la même page ici, et nous pourrions peut-être implémenter cela si jamais nous devions faire un document d'exigences . Donc, nous allons sauter dans chacune des catégories et voulons juste les définir un peu . Nous avons le monde, et comme je l'ai dit, le monde est fondamentalement les hypothèses, les hypothèses sur ce que nous développons. Ils pourraient être quelque chose de très, très basique , comme l'électricité est fournie. Ou ils pourraient être quelque chose d'assez pas basique. Par exemple, avec une voiture, il se peut que les humains sachent conduire des voitures ou que les humains sachent utiliser une pédale et un système de freinage. Ce serait une hypothèse que nous devons savoir, parce que si nous gonflons un nouveau système, peut-être devrions-nous y ajouter un tutoriel. Peut-être que nous supposons trop de la part de l'utilisateur, et cela va faire échouer notre produit parce que nous ne passons pas vraiment du temps développer un système ou un tutoriel. Peut-être que cela doit être une exigence. Un didacticiel approprié qui est testé est présenté à l'utilisateur. C' est très important pour de nouveaux logiciels qui sont assez complexes. Si vous n'avez pas un bon ensemble de tutoriels, même si cela peut faire des choses étonnantes, personne ne l'utilise. Alors le 1er 1 est le monde. Les hypothèses sur ce que nous développons la prochaine. D' autres exigences définissant notre problème en termes génériques et faciles à comprendre. Nous devons savoir quel est notre problème. On pourrait dire qu'il nous faut un guichet automatique. On pourrait dire qu'il fallait obtenir de l'argent en ne allant pas à la banque. C' est un grand problème de vue d'ensemble. Mais maintenant, nous devons définir. Ce que cela veut dire ne veut pas dire que nous avons besoin d'installer des gens autour de la ville où nous pourrions aller parler. Obtenir de l'argent ne veut pas dire qu'on veut le faire. Automatisé ne veut pas dire que nous voulons l'avoir, vous savez, extrêmement sécurisé. Peut-être que nous voulons utiliser l'accès. Plus important encore, nous devons définir le problème. Quel est le problème ? Quelle solution pensons-nous est la meilleure pour résoudre les spécifications du problème est la prochaine étape de celui-ci. Nous définissons les détails plus techniques de l'interface où le bâtiment. Donc, nous sommes en train de définir cette interface, où avec les spécifications, nous avons ce genre de problème défini. Nous savons quel est le problème. Nous savons quelles sont les hypothèses, et maintenant nous examinons comment connecter l'utilisateur au programme ? Quelle est la façon dont on fait ça ? Quelles technologies devrions-nous utiliser ? Quelles technologies devons-nous utiliser ? Quels sont les détails les plus techniques sur la façon dont tout cela fonctionne ? Ensuite, nous arrivons au programme, quel est le cadre de code et le processus de développement ? Le programme que vous pourriez définir comme le reste de ce cours en passant par les documents de conception , passant par les aspects de codage réels, la maintenance de celui-ci, les façons que vous pouvez développer, que c'est en quelque sorte l'aspect du programme. Et puis la machine est le matériel physique de voleur fonctionnant sur. À un moment donné, si nous construisons une nouvelle technologie comme dans une TM, nous pourrions en fait devoir l'envoyer à un fabricant et à un ingénieur électrique pour mettre en place les rouages internes de cette chose. Sinon, nous avons juste ce programme qui serait plutôt cool. Mais il n'y a rien pour l'exécuter, donc nous devons comprendre la machine aussi. Est-ce que leur technologie actuelle existe, ou devons-nous développer nous-mêmes cette technologie ? Alors passons un peu d'exemple ici. Donc, ce que nous avons est une station d'impression photo smartphone. On a vu ça à Walmart. Peut-être que si vous ne les avez pas vus, je vais le décrire un peu. C' est comme un A T M, sauf que c'est un peu différent. Vous avez ce genre de , machine ici, et vous pouvez monter, et vous pouvez soit insérer une clé USB dans un petit port, soit vous pouvez vous connecter via Bluetooth avec votre smartphone. Et fondamentalement, ce que vous faites, c'est que vous transférez des photos sur la machine. Il y a une grande interface qui, avec , tu sais, peut-être comme un clavier ou des boutons ici, et quand les photos vont là-bas, tu les édites, et à la fin, c' est imprime réellement les photos en bas presque en temps réel. Donc, cela vous permet de Si jamais vous êtes allé en vacances, vous avez pris un tas de photos sur votre téléphone. Tu peux y aller. Vous pouvez payer. Il y a généralement un créneau de paiement ici, comme avec de l'argent ou avec une carte de crédit. Vous payez, vous obtenez les photos et vous êtes prêt à y aller. C' est la machine dont on parle ici. Maintenant, je vous recommande fortement de mettre la vidéo en pause ici et de passer par là. Je ne parle pas. Tu dois définir tout ça. Je veux dire, ça prendrait une équipe, peut-être quatre ou cinq jours pour être capable de comprendre chaque petite idée de ce que ça a besoin de dio. Je parle. Passez en revue chacun de ceux-ci et posez quelques choses où certaines des hypothèses que nous devons faire. Quel est le problème que nous essayons d'évaluer ? Que doit faire l'utilisateur ? Qu' est-ce que la machine devrait être capable de dio ? Quelles sont certaines des spécifications ? Comment la machine devrait-elle contacter les choses ? Le programme et la machine. Je vais vous donner un indice. Il y a la machine est juste ceci et le programme est le logiciel que nous développons pour nous. Vous n'avez pas vraiment besoin de vous concentrer sur ce que nous sommes vraiment concentrés est le premier dépôt de 3 ans va au-dessus de ça ? Et comme je l'ai dit, je le recommande fortement et ensuite je vais passer en revue mes réponses à. J' ai espéré que vous l'arrêtiez et que vous avez revu vos réponses. Je ne peux pas m'habiller. C' est assez. Plus vous mettrez dans le cours, plus vous sortirez. Alors s'il vous plaît, juste si vous voulez apprendre autant que possible, faites juste un peu et cela vous aidera beaucoup parce que vous pouvez réellement commencer à implémenter cette chose. Tu te souviendras mieux. Quoi qu'il soit, jetons là-dedans. Alors, le monde, quelles hypothèses avons-nous besoin de faire ? Eh bien, ce que j'étais Certaines des hypothèses que j'ai formulées sont très basiques et certaines choses que nous pourrions considérer comme acquises. Donc, les gens ont un formats de photos standardisés, l'impression qui est très important. Imaginez s'il n'y avait pas de normes ou si les gens viennent avec vraiment, vraiment aléatoire. Peut-être que chaque iPhone ou chaque téléphone avait une façon différente de stocker des photos. Ce serait qu'il n'y aurait aucun moyen de créer cela. Nous ne pouvions pas avoir, Ah, système qui vous décode pas 800 types de photos. Ça ne marcherait pas. Donc, je fais l'hypothèse qu'il existe des formats de photos très standard à partir desquels imprimer. Les gens pourront lire les invites et le tutoriel. Euh, ont les humains sont fondamentalement alphabétisés. C' est en quelque sorte ce à quoi cela arrive, c'est qu'il y aura dans une langue que les gens peuvent lire et comprendre. Si vous êtes allé dans une partie plus analphabète du monde, peut-être quelque part où il n'y a pas beaucoup d'éducation ou de connaissances en lecture. Peut-être que c'est un problème pour toi. Peut-être qu'il y a un autre moyen que vous pouvez implémenter cela avec des images ou quelque chose qui les aiderait mieux. Maintenant, volontiers. Tu sais, sévèrement un peu, des parties du monde disparaissent avec l'éducation, mais c'est quelque chose que tu voudras garder dans la tête. Hum, la prochaine est que les histoires vont re d'autres matériaux. Nous supposons que quelqu'un va aller dans ça et remplir les encres, le papier et des trucs comme ça. Nous supposons que nous allons les mettre dans des magasins où les gens le font réellement, sinon il faudrait trouver une solution et un réseau de distribution pour s'assurer que cet air est toujours rempli. Donc c'est une bonne hypothèse. C' est quelque chose que nous aurions vraiment besoin de nous assurer. Est-ce une hypothèse appropriée ou, eh bien, nous devons développer quelque chose comme ça. Les gens ont des cartes de débit qui fonctionnent avec la technologie de carte de débit standard ou dans cette carte de crédit ou toute technologie de carte ou de l'argent. Dans ce cas, il y aura une monnaie commune que nous pouvons utiliser sur cette machine qui fonctionnera. Il y aura de l'électricité facilement disponible, ce qui est important. Sans électricité, cette machine ne fonctionnerait pas et ils seront disponibles. INTERNET. Peut-être que cette machine doit contacter les serveurs. Peut-être qu'il n'a pas le matériel sur lui pour effectuer les modifications de photo et envoie réellement à un serveur serveur. Est-ce que la photo modifie et puis il renvoie les données. C' est en fait assez commun de nos jours, donc dans cette situation peut-être nous avons besoin d'Internet. Et si nous gérons un pays comme l'arrière pays qui pourrait ne pas fonctionner, nous pourrions ne pas avoir d'Internet disponible là-bas, et nous pourrions soit avoir à mettre un peu de puissance de traitement secondaire, un peu de puissance de traitement secondaire, et cela juste au cas où il n'a pas Internet, il peut essayer de le faire ici. Ça prendra juste un peu de temps. Ou peut-être qu'il y a d'autres solutions que nous pouvons trouver. C' est une hypothèse importante pour reconnaître la prochaine partie des exigences. Quelle est la chose supposée dio ? Donc, c'est un utilisateur peut connecter un smartphone au système. Et si vous remarquez que vous voulez passer en revue les exigences avant de sauter dans le monde, peut-être que vous voulez en quelque sorte définir le problème et ensuite comprendre une sorte de travail à partir de cela et voir, genre, quelles sont certaines des hypothèses que j'ai faites en établissant les exigences qui pourraient être un bon ensemble à ces choses pourraient être faites de bien façons différentes. Juste quelques idées ici, toute façon, les exigences de l'utilisateur peut connecter un smartphone au système. Le smartphone dans les images de transfert sur l'utilisateur peut éditer des photos. Les photos peuvent être imprimées à la machine, et l'utilisation peut payer pour le service. En général, si vous avez un jour des doutes sur les exigences, passez simplement sur un cas d'utilisation, essentiellement une façon d'utiliser la machine. Si vous marchez jusqu'à cette machine, comment voudriez-vous l'utiliser. Et comment voudriez-vous que les choses interagissent ? C' est une excellente façon de commencer avec les exigences à chaque étape. Il suffit de l'écrire et ensuite vous pourriez en quelque sorte construire à partir de là les spécifications de la pièce suivante . Donc, maintenant, nous avons ce genre d'idée ici de certaines des exigences. Maintenant, nous allons dans un peu plus de la nitty gritty. Comment pouvons-nous nous y connecter ? Will bleu à la technologie ? Donc un smartphone se connecte. C' est le moyen le plus populaire de se connecter. Donc Bluetooth serait une bonne idée. Et nous avons besoin d'un bon protocole de transfert Bluetooth pour être installé et pour sécuriser la transaction afin que personne d'autre ne puisse sauter là-dedans. Nous avons besoin d'un bon ou le système aura une suite d'édition de l'émulation des données photo. C' est important. Nous devons définir notre suite d'édition. Voulons-nous l'acheter à quelqu'un d'autre qui veut le concevoir nous-mêmes ? Ce système utilisera la technologie de chiffrement et de puce pour contacter les serveurs financiers. C' est une bonne chose à savoir. Comment ça va contacter les banques ? Comment ça va l'utiliser ? Nous utilisons ce cryptage et cette technologie de puce. Nous spécifions donc la manière exacte de procéder aux transactions financières. Et puis le système aura un dispositif d'impression standard pour l'impression de photos. Il va y avoir un moyen d'imprimer les photos. Nous serons peut-être en mesure de définir cela encore plus en profondeur une fois que nous commencerons à le développer. Et puis enfin, nous avons le programme, que je l'ai dit juste code système et machine, ce qui est juste les spécifications du système , le ram , le processeur, etc. Dans l'ensemble, cependant, c'est une sorte de ce que vous faites avec World Model en juste ce que je veux dire, cela m'a pris peut-être 10 minutes. Nous avons en fait une sorte de plan pour ce que nous voulons faire de cette chose que nous avons dans une idée générale. Personne ne va partout avec la façon dont il devrait être construit. Tout le monde pourrait se mettre sur la même page, et nous pourrions le présenter et travailler encore plus loin. Nous pourrions vraiment commencer à parcourir ces choses et réellement développé, comme un peu de documentation, peut-être comme une chose de 20 pages définissant le problème pour trouver comment nous voulons résoudre le problème définissant les spécifications la technologie qui a besoin et peut-être même les spécifications du système de ce qu'il serait à partir de ce que nous pourrions élaborer un budget. Nous pourrions développer ce que les équipes doivent être sur elle. C' est un excellent point de départ, et tout cela est très important pour les exigences pour trouver notre problème. mettre en place, puis se préparer à passer à la phase suivante, c'est comme la conception et le revêtement de la chose. 10. Exemple de 2 ou 6 exigences: Donc, terminons cette section avec un autre exemple d'exemples sont vraiment importants parce qu'ils nous permettent de se salir les mains et de faire la chose pour réellement passer par certaines exigences. C' est très utile, car beaucoup de ces informations peuvent en quelque sorte aller dans une oreille et dans l'autre. Mais si vous faites un exemple, alors vous pouvez vraiment cimenter cela dans votre esprit. Et chaque fois que quelque chose se produira, vous vous souviendrez peut-être pas tous les éléments des exigences et des définitions entre les deux Mais vous vous souvenez assez que vous laissez la caution pour faire une recherche Google intelligente pour elle, . ou vous serez en mesure de faire un plan et ensuite rechercher peut-être d'autres choses que vous devriez inclure dans la documentation de vos exigences. Donc avec cet exemple, ce que nous allons dio, c'est que nous allons juste prendre, genre, un scénario du monde réel et juste travailler avec ces exemples. Rappelez-vous, nous n'essayons pas d'y aller à 100%. On n'essaye pas. Pensez à toutes les possibilités imaginables dans le monde réel que vous pourriez, mais cela prend généralement des semaines pour le faire dans ces choses étaient juste essayer de sortir. Les 80 % ont essayé d'assommer, vous savez, les 80 % des exigences qui pourraient entrer dans ce domaine et ensuite, vous savez, si vous le voulez vraiment, vous pouvez vous asseoir plus tard et faire le reste. Ou nous pourrions simplement aller de l'avant et en quelque sorte construire dessus au fur et à mesure que nous avançons. Donc, ce que nous avons est que nous n'avons pas déjà construit application d'échecs. Donc, disons que nous avons un téléphone et où nous avons été chargés d'une application, essentiellement la poitrine. Donc tu sais, échecs, le jeu d'échecs. Si vous ne savez pas ce qu'est les échecs, venez avec n'importe quel jeu que vous connaissez. Et donc nous avons une application de jeu, et nous voulons monétiser cette application pour commencer à gagner de l'argent. Donc, c'est notre objectif est de prendre cette application quoi que ce soit, mais cela fonctionne, Peut-être qu'il y a. Peut-être que c'est un en ligne à. Peut-être que c'est vraiment n'importe quoi. Nous allons prendre ce jeu et nous allons commencer à monétiser, donc nous devons réfléchir aux autres mesures que nous devrions prendre. Comment devrions-nous définir le problème et ce qui profitera à la fois au client et aux utilisateurs et avec tout cela, nous pouvons utiliser à nouveau ce modèle mondial. Souviens-toi, on va chercher le monde. Donc, les hypothèses que nous allons chercher pour les exigences. Donc ce qui est exactement nécessaire de cette application, et ensuite nous allons chercher ces spécifications. Alors, quels sont les détails techniques de la façon dont nous voulons mettre en œuvre cela à quelles sont certaines des limites que nous devons respecter ? Disons que l'application précédente est construite en Java et que le client veut le garder de cette façon. Donc c'est là que les contraintes que je peux vous donner aussi, toute façon, il serait très bénéfique pour vous de mettre la vidéo en pause et de passer en quelque sorte ces trois ici. Et si vous remarquez que nous n'avons pas parlé de la façon de monétiser la sortie. Alors, venez avec quelque chose venir avec une idée sur la façon dont vous pourriez le monétiser. Peut-être qu'il n'y a pas de publicités dedans et que vous voulez ajouter des annonces Peut être votre idée de cette application. Est-ce déjà des annonces Hades Et vous voulez ajouter un modèle d'abonnement ? Ou peut-être que vous voulez créer une version payante. Qu' est-ce qui irait dans la version payante venir avec une idée sur une application et ensuite comment vous pourriez faire avancer cette application et ensuite sorte de venir avec les hypothèses, les exigences et les spécifications à ce sujet. Et encore une fois, c'est un exercice. Juste être créatif, amusez-vous un peu avec elle, peut-être passer cinq minutes dessus et ensuite revenir et vous pouvez voir comment je suis allé avec. On peut comparer, euh, voir les différences sur la façon dont ça et vous voyez aussi qu'il y a un tas de façons différentes de faire tout ça, déposer des vidéos, faire ça et d'être de retour. D' accord, donc j'espère que tu l'as fait parce que je pense que le faire tout seul et la revoir ce sera un excellent moyen de cimenter cette information dans ta tête. Donc, la première chose que je suis allé sur les hypothèses du monde, Les choses que nous supposons à propos de cette application, les hypothèses sont importantes car il nous permet de définir les exigences avec les hypothèses ont alors été en mesure de comprendre que nous ne Nous n'avons pas à définir, vous savez, exigences stupides comme les téléphones existent ou quelque chose comme ça. Nous allons avoir besoin de créer un téléphone qui peut supporter l'abside avec des hypothèses. Nous supposons que le monde est une certaine façon et qu'il nous permet de mettre ces choses dans une boîte ailleurs et de travailler sur les choses qui nous aideront. Donc, dans cette situation, nous avons qu'il y a un moyen de payer sur les smartphones. Il doit y avoir un service financier sur les smartphones. Pour que nous puissions effectuer ces transactions, il y a des moyens de gagner de l'argent à partir d'une APP. Il doit y avoir une technique de marketing viable pour gagner de l'argent à partir d'une APP. Si ces deux-là n'existent pas, alors on va devoir inventer tout ça nous-mêmes. Et cette tâche devient soudainement vraiment, vraiment énorme parce que maintenant les exigences vont devoir détailler comment vous savez ce qu' est le marché , quels sont les risques potentiels, choses comme ça. Mais si on peut supposer que ces deux choses existent, alors on doit penser à Ok, quelles sont les meilleures façons de le faire, alors ? L' application est extensible. Peut-être que la base de code est si mauvaise qu'il n'y a aucun moyen que nous puissions étendre l'application à autre chose, donc nous allons supposer que c'est extensible. Sinon, ce projet va juste, tu sais, arrêter dans l'eau. Ça n'ira nulle part. Il y aura une possibilité de contacter Internet et l'institution financière. Donc, le téléphone a à nouveau des capacités Internet. Nous n'avons pas besoin de définir une nouvelle façon pour les téléphones de se connecter à Internet. On va supposer qu'il a des capacités Internet. L' effacement de la transaction pourrait être rendu assez sûr. On va supposer qu'il y a un moyen de sécuriser les transactions. Les gens le font partout avec différentes transactions, donc il y a probablement un moyen de les sécuriser. Le téléphone aura la puissance de traitement pour traiter la demande. Nous espérons que ces demandes seront bas de gamme et que la puissance de traitement sera là. Si ce n'est pas le cas, nous devons attendre la nouvelle technologie. Différentes devises pourront être acceptées. Nous avons une application mondiale. Alors peut-être que nous espérons qu'il y aura des devises du monde entier qui pourront être transférées d'une manière ou d'une autre. Peut-être, par exemple, il Disons que le marché ne nous a accepté que des dollars. Cela changerait notre approche d'une tonne. Mais si nous supposons qu'il existe un moyen d'accepter des devises du monde entier, alors nous n'avons même pas à y penser. Espérons que le marché le fera lui-même, et alors il est légal d'accepter le paiement par téléphone. C' est important parce qu'il y a peut-être un pays où il n'est pas légal d'accepter le paiement sans qu'ils soient en personne ou quelque chose comme ça. Donc nous devons comprendre les lois pour ne pas avoir de problèmes juridiques. Nous devons comprendre que tout ce que nous faisons est un processus juridique que nous n'avons pas besoin d'impliquer les abaissés. Nous n'avons pas besoin de changer les lois ou de remplir certains formulaires pour la rendre légale. Donc, c'est un important à supposer et quelque chose que vous devriez penser avec les exigences juste au cas où. Par exemple, si vous envisagez de collecter des données, vous devez peut-être vous assurer qu'il existe une politique de confidentialité. Peut-être que cela doit entrer dans vos exigences est qu'il est légal avec une politique de confidentialité, Donc maintenant vous devez mettre dans cette exigence. Donc nous le savons alors nous avons nos hypothèses mondiales. Ensuite sont les exigences. Alors je suis allé faire des choses que je pensais marcherais. Je viens de penser à une application qui avait déjà des publicités. Et puis un modèle d'abonnement supprimerait les annonces Quelque chose de très, très simple. Donc, la fonctionnalité pro a supprimé les annonces pour l'utilisateur que je suis en train de définir. Quelles sont exactement les fonctionnalités pro ? Je vais faire quelque chose de simple. Il va juste supprimer, ajouter Donc ça va être notre fonctionnalité pro juste là. Donc, l'étape suivante est que la fonctionnalité doit accepter le paiement d'un utilisateur. C' est assez important s'il n'accepte pas le paiement d'un utilisateur qu'il n'y a aucun moyen que nous puissions les facturer là où il n'y a nulle part où nous sommes amis. Par conséquent, nous ne devrions pas donner à l'utilisateur quoi que ce soit. La fonctionnalité doit fournir des fonctionnalités pro en cas de transaction réussie. Nous pourrions accepter l'argent de la personne et ne rien faire dans l'APP. Ensuite, notre application va probablement être fermée dans l'APP Store, donc nous devons être en mesure de fournir les fonctionnalités pro sur un succès et c'est important une transaction réussie. Nous devons vérifier si c'est réussi ou non. L' enseignant doit à nouveau effectuer les transactions de manière sécurisée. Nous ne voulons pas de violations de données. C' est mauvais pour tout le monde. C' est mauvais parce que ça permet aux autres d'être exploités et c'est mauvais parce que ça nous fait paraître mauvais. La fonctionnalité ou vote pro fonctionnalités une fois qu'un abonnement devient invalide. Donc, si quelqu'un arrête de payer, nous devrions supprimer les fonctionnalités. Sinon, quelqu'un va juste le faire la première fois et puis juste ne jamais payer à nouveau et toujours obtenir toutes les fonctionnalités pro. La fonctionnalité fournira un bouton d'annulation dans l'APP. Ce n'est pas quelque chose que tu dois faire. Peut-être de nos jours, dans le genre d'application qui commence à devenir quelque chose que vous avez à dio. Mais peut-être avec notre application, nous apprécions la confiance dans notre entreprise. Donc nous allons avoir ce bouton d'annulation dans l'application qui enverra un signal qui annule l'abonnement pour tous les mois à venir. L' habitude s'étend sur la base de code existante. Nous ne voulons pas reconcevoir cette application, donc nous allons essayer de l'étendre à partir de la base de code actuelle. La fonctionnalité ne doit pas ajouter plus de cinq mégaoctets à la taille globale du téléchargement. Peut-être que c'est quelque chose que le patron général a dit. Ou peut-être que c'est quelque chose que le client a dit que notre application est déjà très grande et les gens se plaignent à ce sujet, donc cela ne peut pas dépasser cinq mégaoctets, quelque chose qui pourrait arriver. Donc, je l'ai jeté là, et la fonctionnalité doit terminer la transaction en temps opportun. Nous ne voulons pas que ce soit une fonction très, très lente. Donc, nous avons cette idée qu'il devrait être complété en temps opportun et ensuite avec leurs spécifications, nous pouvons en quelque sorte aller là-dedans un peu plus en profondeur. Maintenant, nous avons les hypothèses du monde. Nous avons les exigences, et maintenant nous avons les spécifications. La fonctionnalité sera codée en Java avec le langage APS existant. Rappelez-vous, ce dont nous avons parlé est que l'APP a été codée en Java, donc c'est une spécification à la technologie. Lorsque vous visualisez est le langage APS existant, nous n'aurions peut-être pas besoin de spécifier le travail dans cette spécification. Nous pourrions simplement dire le langage APS existant, mais j'aime être un peu contondant et vraiment, vraiment transparent et ce genre de documents, la fonctionnalité utilisera le magasin de jeu Android pour ses transactions. C' est quelque chose que vous savez, il y a un tas de façons différentes que vous pouvez accepter le paiement. Vous pourriez, par exemple, implémenter quelque chose appelé stripe, qui est une technologie qui accepte les paiements. C' est un logiciel de transaction. Mais pour cette situation, ce que nous allons faire est que nous voulons utiliser le Android Play Store pour faire toutes les transactions sur. Si nous voulions faire cela est arrivé, peut-être IOS aussi bien. On utilise le magasin de pommes là-bas. La vérification Futural pour l'abonnement actif quotidien en utilisant Google fourni un P I. C'est très technique, mais quelque chose qui est important quelque chose que les développeurs ont besoin de savoir est à quelle fréquence voulons-nous vérifier pour voir si un l'abonnement est toujours valide ? disais qu'on va utiliser le Googles AP I pour vérifier tous les jours. Si la description est valide, ne faites rien de ce qui est invalide. Retirez les privilèges. Ou peut-être mettre une période de grâce. Quelque chose comme ça. La fonction s'éteint. Ajouter la foule. Une fois que la clé d'abonnement devient valide, ajouter mob est un moyen de publicité à l'intérieur de votre APS. Il pourrait passer à une nouvelle technologie au moment où vous regarderez ça. Peut-être que c'est une technologie qui sorte de défunte que personne n'utilise plus, mais c'est OK, Tout ce que je dis c'est que nous avons cette technologie dans notre application, et nous disons qu'une fois que la clé d'abonnement devient valide, nous supprimer ce genre de. Nous supprimons cette technologie de l'application afin que l'utilisateur dispose de ces fonctionnalités pro. Et puis c'est le dernier, celui ici en temps opportun. Disons que nous, pour une raison quelconque, nous avons un minuteur qu'il doit pouvoir terminer en 500 millisecondes. Une fois que vous cliquez à nouveau sur le bouton OK, peut-être que cela est transmis par le client. Ou peut-être que c'est juste quelque chose que votre entreprise aime faire. Ils ont ce genre d'idée de la solidité et ils veulent la définir. Donc, dans cette situation, nous avons l'exigence qu'il devrait être en temps opportun dans les spécifications. Nous donnons en quelque sorte l'exactitude de cela et de ceci. Comme je l'ai dit, ce n'est pas un exemple à 100% ici, mais imaginez si vous aviez juste ce document pour sortir, et que quelqu'un vous a remis ce document et a dit, je veux que vous codiez ceci. Vous avez soudainement une direction très forte de ce que vous voulez faire. Et vous avez aussi maintenant la possibilité de poser des questions. Ils ont défini 85 %. Et peut-être que vous venez dans une situation où, comme, il n'y a rien ici et maintenant vous pouvez réellement poser les questions appropriées à votre client ou à votre entreprise de Hey, quelle couleur les boutons devraient être, ou quelque chose comme ça qui n'a pas été défini nulle part ici ? Est-ce quelque chose que je devrais choisir ? C' est quelque chose que vous voulez choisir, etcetera. Donc, à venir avec ce document de configuration requise, c'est un excellent moyen de construire un logiciel. Ensuite, nous allons entrer dans le visage du design. Donc, une fois que nous aurons tout cela, il est temps de vraiment descendre un peu dans le minutieux et de commencer à revoir comment , exactement nous voulons construire n'importe quel logiciel que nous essayons de construire. 11. Introduction en architecture 3-1: Commençons par le plus haut niveau de conception et par le plus haut niveau, je veux dire le moins spécifique. Ainsi, par exemple, si vous concevez une ville, vous pouvez commencer par zoner les différentes zones. On veut un quartier résidentiel par ici. On veut de la pub ici. Nous voulons de l'industrie ici, rien d'autre. C' est juste un plan très, très basique sur le fonctionnement de la ville. Et c'est comme ça que se passe l'architecture. Nous le prenons à partir des exigences et maintenant en fait sorte de venir avec une idée sur la façon dont l'application devrait fonctionner. C' est pourquoi l'architecture est le plus haut niveau, ou le plus haut niveau de design. Les architectes sont le lien entre l'idée et la réalité, sorte que les architectes sont des personnes qui mettent en œuvre l'architecture. Disons que vous avez un bâtiment que vous allez construire avant de commencer. Avant même d'avoir une idée ou des personnes sur place pour construire ce bâtiment, vous allez trouver des plans. Il y aura essentiellement des ingénieurs qui testent les différentes parties, comme dire qu'on a besoin d'au moins un ibeam de 15 pieds ici ou nous avons besoin de ce type de construction ici et vous allez utiliser fondamentalement ce plan pour construire le bâtiment. Rien n'est en train d'être mis en œuvre. C' est juste un design, et c'est ce que fait l'architecte. Quelqu' un avait une idée pour un immeuble. L' architecte prend cette idée, et ils élaborent un plan pour la mettre en réalité. C' est pour ça qu'ils sont le lien entre ça. Ce ne sont pas en fait ceux qui l'ont créé, et ce ne sont pas ceux que vous avez habituellement inventés. L' idée. Ce sont eux qui construisent ce lien entre les deux afin qu'une équipe de construction puisse le construire, et la personne qui a eu l'idée peut le voir construire. C' est donc l'importance des architectes et de l'ingénierie logicielle. Beaucoup de fois, nous devons devenir les architectes, donc nous devons prendre notre document sur les exigences, et nous devons le transférer dans un plan sur la façon de le construire réellement afin que nous puissions encore fois avec un programmeur logiciel aussi. Nous pouvons mettre en œuvre l'idée. C' est l'importance de l'architecture qui fournit ce lien. Maintenant, l'architecture est importante. C' est quelque chose qui ne peut pas être corrigé, une fois mis en œuvre ou dans le rôle de logiciel dans le monde qui ne peut pas être réparé et l' ingénierie logicielle Il pourrait juste être vraiment, vraiment, vraiment, vraiment difficile à corriger, mais une sorte de l'afficher comme quelque chose qui ne peut pas être corrigé. Une fois implémenté dans un logiciel, mauvaise architecture est quelque chose qui ne peut pas être corrigé avec une bonne programmation. Si vous concevez mal l'architecture d'une application, peu importe la qualité de vos programmeurs, cela va toujours apparaître comme un produit pauvre qui prend beaucoup trop de temps à maintenir, et c'est très difficile à étendre et à améliorer au fil du temps. Imaginez essayer de réparer les fondations d'un gratte-ciel après qu'il ait atteint 20 étages de haut. Disons qu'ils ont commencé la construction de ce gratte-ciel et qu'ils sont à peu près aussi haut. Tu sais, ils sont toujours des grues en train de construire le truc, mais ils réalisent qu'il y a un problème fondamental. La chose sur laquelle le gratte-ciel est construit a un problème. Qu' est-ce que tu fais pour réparer ça ? C' est tellement plus difficile de le réparer quand tu as 20 étages, alors quand tu as juste le fond de teint, regarde-le aller. En fait, cette fondation ne va pas marcher. Détruisons et reconstruisons très rapidement. Ce sera un temps d'exécution très rapide ici, bien que vous devez concevoir un moyen de réparer les fondations tout en ne détruisant pas le gratte-ciel. Ou peut-être que la seule façon de le réparer est que vous devez tout arracher avant de pouvoir le construire à nouveau. C' est beaucoup de fois ce qui se passe et l'ingénierie logicielle aussi. Nous devons abandonner un projet et recommencer à zéro. L' architecture est donc très importante. Allons en quelque sorte décomposer cela et simplement sauter dans peut-être un peu plus d'un exemple orienté logiciel . Disons que nous avons ce serveur ici qui prend dans notre application. Disons que nous avons un composant ici, quelque chose que notre application fait, et qu'il contacte ce taux de serveur comme ça. Et disons que nous avons un autre composant ici, et qu'il contacte l'administrateur. Il reçoit des commentaires, et puis on en a un autre ici contacte celui-ci. Il contacte ça, et puis ça sort et entre ici, et celui-ci monte là-haut et vous savez, donc on obtient ce genre d'application très complexe qui n'a pas beaucoup de et puis ça sort et entre ici, et celui-ci monte là-haut et vous savez, donc on obtient ce genre d'application très complexe qui n'a pas beaucoup dechoses. Il y en a beaucoup, comme des barres transversales qui peuvent aller et autour. Et donc vous pouvez voir que l'architecture, cette application pourrait ne pas être le meilleur. Et pourquoi ne serait-ce pas le meilleur ? Eh bien, disons que nous avons un problème avec notre interface principale, notre serveur principal, que la façon dont nous l'avons conçu, c' est peut-être non sécurisé. Peut-être qu'il y a un moyen facile pour les hackers de pirater cela, et la seule façon de le réparer sera de remplacer le serveur et de changer tous les protocoles. Eh bien, avec une architecture comme celle-ci, imaginez enlever ce composant et en mettre un nouveau à cause de la façon dont il est lié à tout ici, nous allons devoir re-programmer chacun de ces composants petits pas chaque sorte de Lupin ici qui contacte ce serveur central. Nous ne pouvons pas échanger à chaud le serveur. Nous devons re-programmer notre application entière. Chaque composant unique a plusieurs domaines que nous devrions essentiellement re programme pour fonctionner correctement à nouveau. Donc, dans ce seul, nous devrions peut-être programme routier trois ou quatre paramètres différents, et puis quand ils viennent ici et sortent, l'autre côté devrait re-programmer que la façon dont ces données reçoivent, comment ces données reçoivent, elles pourraient devenir très, très complexe. Et vous arrivez à un point où vous regardez le logiciel et vous partez, il n'y a aucun moyen de changer cela non plus. On va devoir rester avec un logiciel non sécurisé ou juste le détruire et recommencer complètement ou abandonner le logiciel et ne le supporte plus. Cela arrive un montant décent aussi. Donc l'architecture, très, très important. On va passer en revue certaines façons de trouver l'idée de l' architecture et de l'affiner. Donc vous avez au moins une bonne compréhension de ce genre de choses. 12. Présentation d'architecture 3-2 et exemple: Commençons notre discussion sur l'architecture avec la raison que nous voulons la couvrir. Et c'est l'architecture logicielle. Comment l'architecture s'applique-t-elle au processus de développement logiciel ? L' architecture logicielle consiste à diviser les systèmes de plus grande taille en systèmes plus petits et ciblés. Cela nous donne beaucoup d'avantages différents, non seulement pour réduire les coûts, mais vous contribuez à le rendre facile à développer pour aider à le faire. Nos ingénieurs ne sont pas prêts à attendre les autres, les gens et tant d'autres choses différentes. Donc, les quelques aspects clés ici sont que la bonne architecture est difficile. Ce n'est pas quelque chose de facile que nous pouvons tous faire. Et c'est pourquoi beaucoup de gens évitent de faire cette partie parce qu'il faut de la réflexion, de la créativité pour trouver une bonne architecture. Et beaucoup de gens veulent juste y entrer et commencer à coder pour ne même pas penser à l'architecture. Et quand vous faites cela, vous construisez quelque chose qui est connu un code spaghetti où vous commencez à construire un fichier puis vous construisez un autre fichier et vous êtes comme, Attendez, qui a besoin d'un lien là-bas. Alors nous avons un autre fichier et, comme, oh, ça doit être lié là aussi. Mais il doit également se connecter à ce fichier. Et lentement, vous commencez à obtenir ce web, ce web spaghetti de code va ensemble et au lieu d'avoir cette belle architecture, vous savez, vous savez, peut-être organisée où peut-être tout contacte un serveur central ou il y a ah , page de constantes qui a tout. Donc, si nous voulons changer quelque chose, nous n'avons qu'à le changer. Un seul endroit. Vous commencez à obtenir ce web vraiment étrange d'appels et de choses comme ça et devient très difficile à retracer les problèmes parce que peut-être le problème commence ici, et il appelle la mauvaise fonction ici, ce qui le fait briser un aspect ici ce qui le fait revenir dans l'ici et appeler une autre mauvaise fonction, aller à ici et puis par ici. Donc c'est là que l'insecte est. Et maintenant, nous devons le retracer à travers tous ces appels pour comprendre que Oh, non, c'était en fait une ligne de code ici. On est par ici. Nous avons moins de liens, et peut-être que la rupture est là. Ou peut-être que le frein est là et qu'il se manifeste ici, on peut faire un regard rapide en arrière et on voit qu'il est juste là. Maintenant, bien sûr, ces airs comme des choses très hypothétiques. Mais cela arrive. Beaucoup, c'est que si nous avons une architecture très propre, les pauses sont faciles à trouver. Une bonne architecture permet également un développement plus rapide et une allocation plus intelligente des tâches. C' est important parce qu'il et puis dire que c'est le point que cela va nous faire économiser de l'argent au fil du temps. Si nous pouvons diviser notre architecture en quelque chose comme ça, alors nous pouvons dire que nous aurons un ingénieur sur une tâche ici, un ingénieur pour un ingénieur. 34 et cinq. Nous obtenons cinq tâches différentes se développant à la fois où si nous avons juste un fichier géant, ou peut-être même, comme seulement deux fichiers géants qui communiquent entre eux, comment nous allions faire travailler cinq ingénieurs différentes tâches. Eh bien, nous pourrions les avoir, vous savez, peut-être tous travailler sur le même fichier en même temps, mais cela provoquerait généralement des conflits de fusion, ce qui signifie, comme j'ai travaillé sur le code ici, il a travaillé sur le code ici, mais pour obtenir son code orteil ici. Il ou elle a dû aller de l'avant et changer quelque chose ici. Alors maintenant je pousse mon code, il pousse son code, et soudain il y a ce grand conflit. Je change de code. Il change de code, et on doit se réunir et aller ligne par ligne pour le réparer. C' est un processus très douloureux. Donc, dans cette situation, ce qui se passe beaucoup de fois, c'est que si nous avons tous les deux besoin de travailler sur le même code, vous devez juste attendre. Donc, vous savez, l' ingénieur 1 termine sa tâche, conçu pour terminer sa tâche. Et maintenant l'ingénieur 3 peut enfin sauter là-dedans et commencer à terminer sa tâche. Donc, c'est quelque chose qui réduit le temps d'inactivité global. Si nous obtenons une bonne architecture et permet à l'entreprise également décider où acheter et où construire . Si nous avons quelque chose comme ça et que nous étions comme, nous n'avons peut-être que quatre ingénieurs, eh bien, peut-être qu'il y a une bonne solution là-bas, et nous n'avons pas besoin de passer tout le temps à le développer peut-être qu'il y a une bonne solution là-bas, et nous n'avons pas besoin de passer tout le temps à le développer. Il suffit de dire OK, nous allons travailler dessus et nous allons juste aller de l'avant et acheter quelque chose qui correspond à ça. Peut-être que c'est comme un formulaire ou quelque chose comme ça. Il y a beaucoup, beaucoup de grandes choses de forme en ligne forme de petits projets que nous pourrions acheter et intégrer dans notre logiciel qui nous permet de construire des chaussures d'orteil l'acheteur. Et puis dans l'ensemble, nous devons toujours nous rappeler que les erreurs d'architecture sont presque impossibles à corriger une fois le codage commencé. Une fois que nous commençons, il est impossible de prendre cela et de le rendre impossible. Je ne veux pas dire que ce n'est pas possible. n'y a aucun moyen que tu puisses le faire. Ce que je veux dire, c'est que cela coûterait du temps et de l'argent à Maurin, que ce serait de construire un nouveau produit comme celui-ci. Donc, par exemple, si nous avions un produit existant juste ici pour le faire comme ça, nous devrions dépenser plus d'argent qu'il ne faudrait pour tout recommencer à supprimer et commencer à partir de nouveau. Et c'est ce que je veux dire quand je dis impossibles affixes qui coûtent désespoir Insee entre les deux. Alors passons comme un petit exemple ici, quelque chose dont on peut juste avoir une idée. Disons que nous créons un site Web, et donc nous commençons par cette mauvaise architecture au début. Donc, nous avons une seule page Web qui contient peut-être 1000 lignes de code. Ou pour cet exemple, c'est lui. Il y a 10 000 lignes de code dedans. Si je vous avais chargé de trouver un élément ici, à quel point pensez-vous que ce serait facile ? Combien d'appels différents pensez-vous ? Où tu devrais aller d'ici, en bas, à ici. Pensez-vous qu'il se produirait chaque fois que vous allez à un document de 10 000 lignes ? Et c'est un petit site web ? Je veux dire, sont leurs sites Web qui ont 100 000 lignes de code. Imaginez qu'ils sont tous sur un seul. Comment diviser ça pour que je ne sache pas, peut-être que 15 ingénieurs puissent travailler là-dessus. Pensez à ça. Disons que la prochaine étape est correcte. On ne veut pas tout notre site Web sur une seule page, alors au lieu de ça, on va être comme quoi ? On a besoin de A, disons, d'un front. Donc nous avons le front end, et ensuite nous avons besoin d'un retour. Alors maintenant, nous créons des fichiers folkloriques. Nous avons l'avant et l'arrière, et ils communiquent les uns avec les autres pour un peu mieux. Maintenant, on peut remettre un ingénieur ici, un avant et un ingénieur. Et si nous avons, par exemple, un bouton apparaît comme la mauvaise couleur, nous savons peut-être que nous allons regarder ce dossier au lieu de ce dossier. Tu sais, celui-ci a peut-être 5000 lignes ou dans cette situation, 50 000 lignes. Et celui-ci a 50 000 lignes. Cela rend juste un peu plus facile à découvrir. Nous n'avons pas à passer par 50 000 lignes de choses qui n'ont pas d'importance. Nous n'avons que de l'avant et des trucs. Et maintenant, nous pouvons commencer à le briser et le faire au lieu de juste front end. Peut-être que nous avons les pages Web brisées, donc nous avons une page Web principale ici. Nous avons peut-être la page de connexion ici, et ensuite nous avons le formulaire ici. Et peut-être que le formulaire est sur Lee Ah, 100 lignes. Et puis la page principale est, vous savez, peut-être 49 000 lignes et ensuite la page de connexion est quelque chose comme, vous savez, peut-être, 900 lignes. Donc c'est toujours ces 50 000 lignes, mais on l'a fait et on va juste garder la fin. Voici le backend. Ouais, ça aurait dû être de retour et pas juste fin eso front end backend. Donc nous avons le back-end ici qui communique toujours. Mais maintenant, nous avons un peu mieux une idée de la façon dont il communique avec les choses. Maintenant, nous avons ceci rompu juste un peu plus. Donc, nous avons la possibilité que si nous disons que la couleur du bouton est fausse, nous pouvons aller dans le fichier plus comme, Eh bien, c'est sur la page du formulaire. Allons voir la page du formulaire. On a lu les 100 lignes juste là, on fait le changement. Donc vous voyez, à mesure que nous brisons mawr et de plus en plus, nous commençons à être en mesure de maintenir ce projet un peu plus, et nous commençons à être en mesure de créer fondamentalement un meilleur produit que nous pouvons développer dans le avenir. Donc maintenant, nous avons juste une idée très, très générale de ce que nous faisons avec l'architecture. En brisant les choses, commençons à passer en revue quelques modèles qu'ils appelaient des modèles ou des modèles de différentes façons que vous pouvez prendre votre projet et le briser et certaines des méthodes éprouvées et vraies faire. 13. Motif de 3 tuyaux et de filtre: Regardons notre premier modèle architectural. Donc, les modèles architecturaux il n'y a jamais vraiment une approche de taille unique, ce qui signifie que nous ne pouvons pas regarder un modèle et développer chaque morceau de logiciel avec ce modèle. Donc, avec ces modèles, ce que nous créons ici, c'est que nous créons une boîte à outils dont nous pouvons tirer parti. Donc, si nous comprenons, peut-être cinq ou six modèles populaires chaque fois que nous arrivons à un problème comprendront exactement comment nous devrions y arriver, ou du moins une direction générale de ce que nous devrions faire. Et puis pour ce problème spécifique. Nous pouvons en fait développer une architecture pour cela. Donc, ne pensez pas que vous pourriez simplement appliquer ces modèles, vous savez complètement et totalement orteil un projet. Ils le sont encore. Ce sont des idées, leur façon de faire les choses. Et vous pourriez penser à un problème. Sois comme, oh , ouais, je vais utiliser un tuyau et un filtre, puis un serveur client et ensuite, vous savez, le lier avec ma propre architecture. Donc juste avec cette petite clause de non-responsabilité, commençons là-dessus. Le 1er 1 comme je l'ai dit, est le modèle de tuyau et de filtre les tuyaux sont les connexions de données. Et les filtres sont des choses comme ça. Comme divisible par 10. Même bizarre. Donc, par exemple, si nous avions un petit ensemble de données ici, si nous avons, genre, un petit ensemble de données de 357, nous pourrions l'envoyer à notre premier filtre, notre deuxième filtre. Et puis peut-être que c'est la sortie. Donc voici les tuyaux. Donc ici, c'est le tuyau, et voici les filtres. Maintenant, il y a un aspect important que nous devons examiner. Il y a quelque chose de très important avec ces tuyaux et filtres. L' entrée doit correspondre à la sortie. Et ce que je veux dire par là, c'est que je ne veux pas dire que, tu sais, 357 doit aller dans tous les filtres, et ensuite 357 doit sortir. Ce que je veux dire, c'est que le même type d'entrée doit sortir de chacun d'entre eux afin que nous puissions rendre l'affaiblir complètement et totalement sorte d'intermix à base de plantes. Prends ça et mets celui-là. On peut prendre ça et mettre celui-là. On peut en ajouter cinq autres. On ne pouvait en faire qu'une. C' est la partie importante. Donc, par exemple, si nous avons 357 et qu'il entre dans un, c'est par exemple, Times 10, ça va sortir avec un exemple de 30 50 70. Et puis ça va aller dans le filtre suivant. Tu as remarqué que c'est exactement la même chose ? C' est juste un autre ensemble de chiffres, peut-être pour celui-ci au lieu de fois. Ted, on dit qu'Onley veut peut-être mettre un autre numéro ici pour que ça marche. On ne veut que bizarre. Donc ça sort et maintenant ça va être 357 et ça va aller dans le prochain. La taille change. C' est parfaitement bien. Mais le type est resté le même. Ils sont toujours juste sens numérique, et encore une fois, je vais continuer à conduire cette maison. C' est le tuyau et le filtre est tout au sujet. Vous prenez un certain type, vous le mettez à travers un filtre et vous obtenez un certain type de retour à l'autre extrémité. Et puis avec le tuyau et le filtre, nous pouvons également appliquer des actions. Et ce qu'ils sont, c'est qu'ils prennent les données et ils font quelque chose avec eux, puis ils retournent exactement les mêmes données. Donc, par exemple, a dit le patron, peut-être que nous avons le 357 Nous l'avons mis dans. Judy, envoie le patron, alors il l'a mis dans le patron. Ça va prendre que ça va lui envoyer. Mais quoi ? Qu' est-ce que c'est ? La sortie affiche à nouveau la séquence de numéros. 357 pour que nous puissions l'envoyer au patron, multiplier par 10 et ensuite l'envoyer aux clients ou quelque chose comme ça. Donc, l'inaction est parfaitement bien comme un filtre, car il fera quelque chose. Ça prendra les données. Peut-être qu'il l'enverra à un serveur. Peut-être qu'il fera un calcul et définira une autre variable. Mais la partie importante est que la sortie doit être l'exacte de l'entrée si elle est dans. Si c'est une action, je veux dire que vous pourriez changer dans l'action et la faire sortir différemment, mais il doit y avoir une sortie avec laquelle nous pouvons travailler. Alors passons en revue quelques petits exemples ici et comment vous pourriez l'utiliser. Disons que vous avez une société d'investissement et que vous travaillez avec, vous savez, des actions qui ont augmenté et diminué. Donc vous avez cette liste de profits et de pertes sur vos actions alors peut-être le 1er 1 Peut-être qu'ils sont tous en dollars. Vous avez le 1er 1 est un 10 positif, puis peut-être un négatif 30 et puis peut-être un 11 positif puis négatif 15. Disons que ce ne sont que les chiffres avec lesquels vous travaillez. Donc maintenant, ce que nous pouvons faire, c'est en quelque sorte de construire un modèle pour nous aider avec cela. Nous voulons donc prendre tout ce qui est supérieur à zéro. Donc on va prendre le plus grand que 01 ici. Et puis on veut envoyer ça aux clients. Nous voulons montrer aux clients que nous faisons du bien, que nous faisons de très bonnes choses ici. Donc quelque chose de plus grand que zéro que nous allons envoyer aux clients et ensuite quelque chose de moins que zéro nous allons envoyer au patron comme So ? Donc on va attraper ça, on va l'envoyer au patron. Et maintenant ce qu'on va dio, c'est qu'on prend ces données et on les met dans. Donc si on met ces données ici, ça va aller plus loin que zéro. Et ce qui va sortir, c'est seulement les 10 et les 11 qui seront adoptés dans les clients du Sénat . Ils vont être envoyés aux clients, et ensuite ça va passer une sortie. Il ne reste plus rien, ce qui s'arrête juste là, et ensuite nous le passons aussi en moins de zéro. Et puis on envoie ça au patron, comme ça, et ensuite c'est tout ce qui va être. Voici négatif 30, puis négatif 15. Donc les clients ont ce qui se passe bien, et notre patron a ce qui va mal. Peut-être qu'il peut aider à corriger la situation. Et beaucoup de fois, le tuyau et les filtres le feront. Nous aurons cette architecture où vous sortirez et vous aurez une sorte de briser dans ces choses distinctes et peut-être même les données reviennent ensemble, et ça continue de fonctionner. Peut-être que tout ça commence leurs propres petites chaînes ou quelque chose comme ça. Mais le tuyau et le filtre nous permettent juste de prendre les mêmes données et de les jeter de la manière que nous voulons. Par exemple, encore une fois, juste pour l'amour de la clarté. Cela fera un peu moins depuis, mais disons, au lieu d'envoyer les clients pour une raison quelconque, nous voulons seulement envoyer des numéros impairs. Donc on prend les clients du centre et on le déplace ici, puis on monte ici et on dit qu'on veut seulement utiliser des nombres impairs. Et encore une fois, c'est un exemple bizarre, mais cela fonctionne parfaitement bien. Le code fonctionne parce qu'il y a des petites boîtes noires. Tant que ses chiffres arrivent, peu importe comment tu as arrangé ça. Donc maintenant, il va attraper tous les nombres supérieurs à zéro va alors seulement prendre les chances. Donc ça veut dire qu'on ne restera qu'avec 10 ici, et ensuite ça va les envoyer aux clients. Et encore une fois, vous pouvez les mélanger de n'importe quelle façon, forme ou forme. Mais c'est sur toute l'approche des tuyaux et des filtres. Un membre des points clés ici sont que l'entrée doit correspondre à la sortie. Donc, si vous avez un ensemble de nombres et que vous devez sortir comme un ensemble de nombres, si vous avez un ensemble de chaînes qui devaient sortir comme un ensemble de chaînes ou de quelque façon que cela fonctionnerait avec le même type de types ici et puis aussi, euh, même si vous utilisez une action, vous devez également afficher cette action. Tout doit être personnalisable où vous pouvez les glisser et les déposer dans l'ordre que vous voulez, et ils fonctionneront parfaitement avec cet ordre. 14. Motif client-serveur 3-4: Parlons maintenant du modèle de serveur client. Ceci est également parfois appelé modèle de serveur client. Mais le modèle de serveur client est un modèle que nous avons tous utilisé auparavant, et beaucoup d'entre vous pourraient regarder cela et être comme, Attends, c'est un modèle. C' est quelque chose que nous pouvons apprendre à propos de ça qui ressemblait à des connaissances communes. Mais oui, c'est un modèle. C' est une façon de mettre les choses en place. Donc, avec le modèle de serveur client, ce que nous avons, c'est que nous avons un serveur central. Donc, par exemple, aura nous allons garder avec un schéma de couleurs de cette petite image sur la droite ici. Donc, nous avons un serveur ici, et ensuite nous avons des clients qui contactent le serveur pour obtenir des informations, donc nous avons de petits clients ici et là. Encore une fois, allons-y avec le schéma de couleurs ici. Nous avons donc des clients client client, et ils ont tous demandé au serveur pour des informations. Le serveur distribue ensuite ces informations à ce point affaiblir aux clients, sorte que les requêtes entrent et le serveur distribue les requêtes de retour, et c'est ainsi que fonctionne essentiellement l'ensemble de l'Internet. Si vous allez sur facebook dot com. Vous contactez le serveur Facebook. Donc, cela, par exemple, pourrait être Facebook. Vous contactez le serveur Facebook, vous lui demandez tout un tas d'informations, et il vous donne toutes les informations qu'il vous donne. Par exemple, les dernières mises à jour de votre chronologie. Il vous donne le code HTML afin que vous puissiez charger la page Web. Il vous donne toutes les images, vous indique où se trouve tout, et il vous envoie réellement ces données. Et chaque fois que vous mettez à jour une page chaque fois que vous accédez à une nouvelle page, une nouvelle demande est envoyée au serveur et une nouvelle réponse revient du serveur. Et alors quoi ? C' est pourquoi c'est un modèle, c'est parce que c'est un moyen que nous pouvons tous nous connecter à un élément central de données ou à un hub central d'informations. Disons que Ah, loin une bonne façon d'expliquer que c'est sur un serveur de jeu. Si, par exemple, vous jouez à un jeu en ligne comme Call of duty ou joueurs terrains de bataille inconnus ou quinzaine, tous ces jeux que vous jouez tous sur exactement la même heure sur le même serveur, et c'est là que beaucoup de gens comprennent. Ils ont déjà entendu le serveur de mots. Donc vous avez tous ces gens et ils jouent tous le jeu exactement en même temps. Maintenant, ce que le serveur fait, c'est qu'il calcule tout. Il prend une information, donc ça prend chaque seconde peut-être, ou peut-être même toutes les 10 fois par seconde. Je ne sais pas combien de fois il met à jour le serveur. Votre client. Votre ordinateur envoie au serveur votre emplacement, vitesse de déplacement, les éléments que vous avez. Et le serveur met à jour son petit journal de données avec tous ces trucs. Il n'a pas pris ces données, et il les envoie à chacun des clients tous les X nombre de millisecondes ou de secondes. De cette façon, lorsque vous jouez à votre jeu, si quelqu'un entre dans. Donc, par exemple, disons que c'est la carte dans le jeu. Tu es juste là. Si quelqu'un entre dans votre vision, vous obtenez un message qui indique à votre ordinateur où ses emplacements à cette aide, car cela permet maintenant à votre ordinateur de rendre ou de montrer cette autre personne en temps réel afin que vous demandiez qu'il vous envoie demande qu'il envoie et il y a 100 ou 200 personnes qui le font exactement en même temps. Et c'est ce qui construit la carte et permet à tout le monde de courir. Maintenant, si vous avez un retard de serveur, s'il y a un retard dans le jeu, c'est parce que cela prend trop de temps. Vous avez demandé des données, puis au moment où les données vous reviennent, cette personne a déjà beaucoup avancé. Maintenant, votre ordinateur essaie de les afficher ici. Et puis il reçoit un autre message que non, la personne est en fait là, donc ils sont en retard sur l'écran, et c'est une panne courante de vos serveurs. Pour ralentir, c'est que les clients ne peuvent pas obtenir l'information. Mais le modèle de serveur client est un modèle assez simple que nous utilisons encore une fois tous. Il a juste un serveur central, et vous avez tout un tas de clients qui ont peut-être un logiciel client qui contacte le serveur, qui a généralement un logiciel serveur. Donc, il y a généralement deux types. Vous avez le logiciel serveur, puis ici vous avez le logiciel client sur chacun de ces, données de requête de Clement et dans les données sont renvoyées 15. Motivateur d'esclave Master-Slave: Notre prochain modèle dont nous voulons parler est quelque chose connu sous le nom de modèle maître esclave . Donc, comme la description va en quelque sorte, il y a deux éléments à cela. Tant le maître, qui est généralement représenté au sommet d'une sorte de hiérarchie, puis en dessous, tout un tas d'esclaves. Donc, nous avons dans cette situation va juste créer trois esclaves différents ici, Donc il pourrait y avoir trois. Il pourrait y en avoir six. Il pourrait y avoir 1000 esclaves différents. Peu importe ce que tout cela compte, c'est que ce genre de contrôle est unidirectionnel, qui signifie que disons que cette couleur ici sont les commandes. Les commandes de Lee descendent. Donc le maître dit toujours aux esclaves quoi dio Les esclaves ne sont jamais, en fait, en quelque sorte. Ils ne contrôlent pas le maître. Ils ne le disent pas comme ça. Ça devrait faire quelque chose. Un exemple de ceci est pour, um avec la réplication de base de données. Disons que c'est notre base de données principale sur nos principaux contacts de base de données. Disons que notre serveur, ainsi que nos contacts serveur. Une base de données inversement, puis notre serveur livre les données sur le web. Donc avec le maître, c'est toujours celui qui sera le plus à jour. Il va apporter des données à jour, envoyer des données maintenant avec les esclaves. Les esclaves doivent dupliquer les données du maître . Donc, le capitaine dit qu'il peut être à minuit ou 3 heures du matin pour se mettre à jour. Donc, il enverra une commande à l'esclave un ici qui dit esclave un. Commencez à copier mes données dans vos données. Et ça va le prendre. Il saisira tous les nouveaux changements, et il se mettra à jour. Et puis l'esclave se calmera. Il ne fera rien tant qu'il n'aura pas été commandé à nouveau par le maître. Uh, les clés USB ou les périphériques utilisent aussi. Donc, disons que nous avons un ordinateur ici et que nous avons, vous savez, vous savez, le CPU central et puis le ram et etcetera, etcetera, etcetera, etcetera. Mais ce que nous avons, c'est qu'on branche une clé USB ici. La clé USB agit comme un esclave. Il ne dit pas le processus ou quoi dio le processeur. Dans cette situation, nous avons le taux de processeur ici, n'écoute jamais cette clé USB. Il n'écoute pas, vous savez, vous savez, ce sont des commandes ou quoi que ce soit. Le processeur contacte la clé USB et lui dit, OK, OK, faites n'importe quelle tâche nous de la science. Disons que nous copions des données. Il dit, Ok, prenez vos données et déchargez-le, aussi, sont disque dur. Donc, le lecteur USB hors chargé sur le disque dur, puis le processeur continue à faire ses autres tâches. Et chaque fois que nous devons réellement contacter la clé USB, il le fait exactement. Il le contacte, puis l'U. S. B. Drive fait tout ce qu'il lui dit. USB Drive n'essaie jamais de contrôler quoi que ce soit d'autre à moins qu'il ne devienne un virus. Dans ce cas, le maître esclave tombe en panne. Mais dans cette situation avec un lecteur USB normal, le lecteur USB est un esclave dans cette situation. Et donc ça. Tu sais, on parlait de matériel, mais avec le logiciel, on peut le faire aussi. Typiquement, nous faisons cela avec quelque chose appelé un contrôleur. Donc, le contrôleur est toujours celui qui va contacter toutes les petites pièces et leur dire quoi dio. Donc, avec ce genre d'architecture, nous n'avons pas de communication entre nos petits morceaux comme ça qui n'arrive jamais. Donc, avec un contrôleur et un patron esclave maître, ce que nous avons est ce contrôleur qui donne des ordres. Donc le contrôleur donne les ordres. Ensuite, nous avons des messages qui reviennent pour que les messages reviennent. Et ensuite, si des données doivent être ajoutées à ces données, c'est le contrôleur qui le fait lui-même. Donc, fondamentalement, c'est une sorte d'isoler chaque unité ici, chaque module, isolant complètement l'un de l'autre pour que nous puissions soit affaiblir, les échanger. Nous pourrions les étiqueter ou les échanger et, si cela le permet, nous n'avons pas cette communication croisée ici, où il est très difficile de retracer le flux d'informations. Nous savons que s'il y a de mauvaises informations qui viennent ici, ça doit venir du contrôleur. Le contrôleur doit avoir une erreur, ou il doit y avoir une chaîne, et cela nous permet de sorte de backtrack. Ça change un peu mieux au lieu d'avoir comme ça semble un peu compliqué, mais imaginez s'il est communiqué. Tu sais, comme ça où il y a juste des communications ici et ici que celle-ci vient ici . C' est impossible à suivre. Donc ce que nous aimons beaucoup de fois c'est que les orteils ont cette manette. Donc, le maître esclave est un modèle très important. Il est utilisé beaucoup, et l'une des personnes ne se rend même pas compte qu'ils utilisent ce modèle. Mais c'est très bon de s'attaquer à Ah, tout un tas de problèmes différents. 16. Motif en 3-6 calques: Notre modèle suivant est le motif en couches. Donc, le motif en couches est fondamentalement juste que c'est un tas de couches différentes et ce doux pour Rome. Cela signifie que nous avons ces couches de technologie, de sorte que les couches de technologie ne communiquent qu'au sein de leurs propres couches. Ainsi, par exemple, il s'agit d'une couche, et c'est une couche, et c'est une couche. Ce qu'on n'a pas, c'est qu'on n'a pas de communication croisée. On n'a pas ça qui essaye d'appeler des informations de là comme ça. Ce que nous avons, c'est que nous avons la capacité de communiquer d'avant en arrière sur la capacité de communiquer d'avant en arrière. Et puis ces Onley appellent dans leurs couches respectives afin que vous puissiez voir que peut-être un léger inconvénient est que si vous avez quelque chose ici, il pourrait devoir filer vers une autre couche. Vous devrez peut-être passer par quelques dossiers supplémentaires, non ? Un peu de code supplémentaire. Ce qu'il fait, c'est classer les données de sorte que si on cherche, disons que, euh, vous savez, nous avons ceci est notre front end. C' est notre backend, et c'est le lien entre les deux. Si nous avons un problème de retour, nous savons que nous examinons, vous savez, le programme dans cette couche. Et donc c'est toujours assez abstrait, donc c'est en fait passer par un petit exemple ici. exemple que je veux parcourir est unmodèle en couches très populaire, modèle en couches très populaire, et vous pourriez appeler celui-ci un modèle parce que c'est une chose réelle que vous pouvez implémenter. Donc, il s'appelle le contrôleur de vue du modèle. Donc, par exemple, nous allons mettre le contrôleur juste ici et sur le côté droit nous allons mettre la vue et le côté gauche. Nous allons mettre le modèle de sorte que le contrôleur de vue modèle brise les trois aspects différents ici sur le côté droit. Comme je l'ai dit, nous avons le point de vue. La vue est ce qui est montré à l'utilisateur. La vue est ce que nous pouvons cliquer sur, ce que nous pouvons interagir avec. Donc, dans cette situation, disons que nous avons une page de profil, donc vous savez qu'il y a l'image de profil, et ensuite nous avons un petit formulaire ici pour mettre à jour le profil. Donc nous avons ah, boîte une boîte et ensuite la possibilité de soumettre cette boîte. Et peut-être qu'on change le nom ici. Donc, c'est ce que nous allons essayer de changer le nom et l'e-mail maintenant avec le contrôleur de vue du modèle. Ce que nous avons sur le côté gauche, c'est le modèle. Donc c'est la base de données. C' est notre base de données qui a l'utilisateur ici. Donc il va avoir la ligne pour l'utilisateur, puis son nom et son adresse e-mail. Donc, nous avons le nom d'utilisateur et puis l'adresse e-mail juste là. Et, tu sais, il y en a tout un tas. Un tas de noms d'utilisateur email, nom d'utilisateur , email , etcetera , etc. C' est le modèle. Il s'agit de l'entité elle-même. Donc, sur le côté gauche, nous avons le modèle, l'entité. Souvent, c'est la base de données où le type de données est réellement stocké. Maintenant, nous ne voulons pas avoir cette communication croisée est cette capacité pour la vue de parler au modèle ? Donc, ce que nous faisons est de créer quelque chose au milieu appelé le contrôleur. Donc, au milieu, ce que nous avons, c'est que nous avons le contrôleur et le contrôleur gère toute la communication . Ainsi, le modèle contactera le contrôleur et le Cullen Trollen contactera la vue, puis vice versa. La vue contacte un contrôleur et le contrôleur contacte le modèle. Ainsi, par exemple, nous avons cliqué sur le bouton Soumettre ici. Les données que nous avons mises à jour vont aller au contrôleur. Le contrôleur ne va pas avoir une fonction comme peut-être que ce sera une fonction appelée utilisateur de mise à jour. Et puis avec cette fonction, il va ensuite appeler au modèle. Le modèle va récupérer toutes les informations qui ont été mises ici et il va mettre à jour l'utilisateur. Qu' est-ce que ça fait ? Qu' est-ce que cela nous aide à accomplir ? Ça nous aide à comprendre où sont les problèmes. Nous avons cette couche de base de données sur la gauche, et nous avons cette couche de contrôleur au milieu. Et puis nous avons cette couche de vue sur la droite. Maintenant, nous sommes en mesure de comprendre les problèmes. Nous avons le front end. Il s'agit du script Java dans le HTML. Donc, euh, le genre de vue des choses. Et si quelque chose est foiré ici, nous regardons juste le HTML. Nous regardons le site lui-même. Si nous avons un problème avec les données qui sont entrées ici, et qu'elles ne parviennent pas au modèle. Ce qu'on sait, il y a un problème avec le contrôleur. Donc, nous regardons dans la classe contrôleur. Nous regardons la chose principale qui est en fait de contrôler ces deux côtés, puis si la base de données est foirée, si nous avons cela arrive, nous savons que le contrôleur fait bien. Mais certains, pour une raison quelconque, le modèle ne se met pas à jour correctement. Ce que nous savons pour aller regarder les bases de données pour regarder le my SQL, les différents types de façons des bases de données stockant des choses. Il nous permet cette couche. Il nous permet de classer et de construire des éléments différents. Nous pouvons avoir avant et les développeurs ici, nous pourrions avoir des développeurs intermédiaires. Ici. Nous revenons dans les développeurs ici. Habituellement, ces deux classes sont couvertes par retour dans les développeurs, mais vous pouvez aussi avoir un peu de chevauchement où les développeurs frontaux savent un peu ici aussi. ensemble, cependant, le modèle en couches est utilisé beaucoup pour classer nos programmes, pour les séparer afin qu'ils puissent être facilement maintenus afin qu'il n'y ait pas tout un tas de code spaghetti et qu'il est logique pour toutes les personnes impliquées 17. Motif en génie logiciel: alors faites tout cela. Nous essayons de créer le processus d'architecture logicielle, le processus par lequel nous pouvons trouver une architecture pour un problème pour un programme que nous essayons de concevoir. Maintenant, c'est une tâche assez difficile et qui était très loin dans le monde de la création ici. Ce que je veux dire par là, c'est qu'il ne va pas y avoir un exposé x y Z première étape deuxième étape. Troisième étape de ce processus, nous allons devoir faire preuve de créativité. On va penser à notre problème. Nous allons penser à d'autres problèmes qui ont été réglés, et ils ont en quelque sorte tiré de cela et ont conçu une solution unique pour ce que nous essayons de faire . Donc en ce sens, au lieu d'avoir un processus 123, nous avons en quelque sorte une liste d'objectifs que nous essayons atteindre avec notre architecture, et cela pourrait obtenir aussi en profondeur ou aussi haut que nous le voulons afin que nous puissions faire cela très un dans profondeur. Et par là, je veux dire, c'est juste un plan général. Nous pouvons obtenir des informations très détaillées sur la façon dont exactement chaque élément de données va être communiqué. Habituellement avec des projets de plus grande envergure et des grandes entreprises. Vous allez obtenir la profondeur de Maurin et avec une sorte de sociétés en mouvement plus rapide ou des startups plus rapides de la Navy. Nous ne passons pas autant de temps ici, ce qui est d'essayer de faire sortir le produit. Et puis nous décidons de ces choses plus tard, ce qui pourrait être très coûteux. Ou cela pourrait fonctionner pour votre projet, selon la façon dont tout est configuré. Mais de toute façon, ce que nous essayons de faire, c'est de contrôler comment un programme est décomposé et comment il interagit avec lui-même et avec le monde extérieur. C' est important pour le monde extérieur aussi. Nous essayons donc de comprendre comment le programme va se passer. Ce sont des petites connexions. Et aussi comment communique-t-il avec les utilisateurs ? Comment communique-t-il avec d'autres systèmes logiciels ? Comment fait-il cela aussi ? Et nous essayons de comprendre comment il s'intègre fondamentalement dans le monde ? Et puis comment construire cela aussi ? Comment structurer cela de manière à ce qu'il fonctionne correctement et nous essayons également de modéliser comment le contrôle ou nous essayons de modéliser la structure de contrôle du système et comment il se comportera . La structure de contrôle est une sorte de tous ces modèles que nous avons fait. On va avoir une structure de contrôle, ce qui est un peu comme, tu sais, peut-être que ça ou on aura peut-être cet esclave maître esclave où on quelque chose comme ça, on va avoir le tuyau dans le filtre structure de contrôle où nous allons continuer à mettre des données et ensuite les filtrer sur une ligne ? Ou peut-être que nous allons avoir quelque chose comme ça où nous avons en quelque sorte ces sous-systèmes tous assemblés. On va avoir un tuyau dans le filtre. Ça va aller chez un maître esclave. Les maîtres esclaves ne vont pas devenir un peu comme un contrôleur de vue de modèle, etcetera, etcetera. Donc, nous prenons tout cela en quelque sorte et nous essayons de le combiner en une manière qui fonctionne pour notre solution. Et comme je l'ai dit, il n'y a pas de coupure claire. Les problèmes sont une solution. On pourrait avoir une équipe d'ingénieurs. Une autre équipe d'ingénieurs et une autre équipe d'ingénieurs essaient tous de trouver la meilleure architecture pour notre projet. Et ils vont tous être complètement différents. Certains d'entre eux peuvent être complètement, complètement différents. Peut-être que ces gars pensent ce qu'on devrait utiliser un tuyau et un filtre. Ces gars sont comme, non, non, non, le maître esclave. Plus ceci et ce modèle comment nous le faisons. Ces gars ont une façon complètement différente de le faire, et c' est l'importance de l'architecture fondamentalement. C' est ça ? Une sorte de quelque chose que nous devons concevoir par nous-mêmes. faut qu'on le découvre. C' est un processus créatif , c'est pourquoi beaucoup de gens l'ignorent. C' est dur. C' est très difficile à concevoir. Eh bien, la prochaine étape que nous devons faire est de briser le projet dans les sous-systèmes et les modules. Si vous pouvez simplement faire cette étape, vous êtes dans une bonne situation pour votre architecture. Donc, ce que je veux dire par ceci, c'est que nous avons les deux choses qui subsistent, euh, et le module et le sous-système est un système indépendant qui détient une valeur indépendante. Et ce que je veux dire par ceci, c'est que vous pourriez prendre ce système et vous pourriez le brancher dans un autre programme et cela fonctionnerait correctement. Ou vous pourriez même vendre ce système. Quelqu' un pourrait vouloir acheter le système parce qu'il a une sorte de valeur indépendante Ah, . module, cependant, est un composant d'un sous-système qui ne peut pas fonctionner comme un autonome ou s'il fonctionne comme un autonome. C' est très insignifiant. Il n'y a rien de révolutionnaire. Donc, disons que nous avons, par exemple, un petit module qui divise par 10 puis ajoute 30 puis multiplie par 62 un petit module bizarre ici. Et la raison pour laquelle j'utilise le module est la cause. Pensez à ça. C' est un élément d'information. Nous pouvons maintenant nous évanouir dans cela et le distribuer et il obtient un nouveau numéro. Il a une certaine importance pour nous, et nous pouvons le combiner et peut-être un moyen important. Mais pensez-vous que quelqu'un achèterait ça ? C' est très spécifique, et il n'accomplit pas vraiment une tâche en soi. n'y a pas de tâche que nous avons. Peut-être qu'il accomplit une très petite tâche dans un grand système de tâches, mais en soi, il n'a pas de valeur indépendante. Maintenant, disons que nous avons tout un tas de ces petits modules d'équation mathématique, donc nous en avons un ici, un ici, un. Ici, nous avons tous ces petits modules qui fonctionnent, et maintenant ils sont tous des communications croisées, quelle que soit la structure de ce sous-système. Et nous avons maintenant ce sous-système construit et disons que ce sous-système calcule peut-être nos impôts. Donc ce sous-système est maintenant assez bon qu'avec toutes ces petites équations mathématiques Donc sont tout ce que vous savez, comme les fois 10, vous savez, moins 62. Et peut-être que ça calcule notre assurance hypothécaire, etcetera. Vous savez, toutes ces petites équations folles qui vont ensemble ici, et ensuite ça donne enfin combien vous devez en impôts. Donc, il y a peut-être votre revenu, peut-être votre revenu ou quelque chose de quelque chose, et ensuite ce que vous devez en impôt. C' est un module important. C' est quelque chose que nous pourrions utiliser. C' est quelque chose qu'on pourrait vendre à quelqu'un qu'il ne veut peut-être pas passer le temps développer. Cela a une valeur commerciale. Il a une valeur indépendante. Il est composé d'un tas de composants qui n'ont aucune valeur par eux-mêmes. Je veux dire, nous le calcul, vous savez, votre hypothèque hypothécaire pourrait peut-être avoir un peu de valeur, mais quand vous le mettez dans ce contexte géant, nous arrivons à la capacité que nous pouvons en fait, vous savez, arrivez au point de le vendre. Et disons que ce ne sont que nos impôts personnels. Ici, nous avons exactement la même chose. Nous avons tout un tas de petits modules ici et vous l'importez. Et maintenant, vous avez peut-être l'impôt sur les affaires. Et donc vous importez des affaires, faites du taxi sur les affaires portuaires et maintenant, ça va devenir un peu bâclé ici, mais je veux juste ramener ce point à la maison maintenant. Ce que nous avons, c'est que nous avons en fait ce sous-système de sous-systèmes. Donc, dans ce cas, nous avons presque tout notre logiciel. Ou peut-être que notre logiciel est comme tout un truc de finance personnelle, donc il pourrait y en avoir d'autres aussi. Mais nous avons un autre système que nous pourrions vendre aux gens aussi. Donc, cela pourrait être un sous-système entier, et chacun d'entre eux pourrait être plus de sous-systèmes à nouveau. Vous pouvez concevoir cela de toute façon que vous voulez, mais juste une sorte d'essayer de piloter le composant de modules d'accueil de points d'un sous-système qui ne peut pas fonctionner seul. Donc, s'il y a ces petites équations ou des offs qui ne peuvent pas vraiment être vendus, alors ce sera probablement un module. Et puis aussi ce que nous avons, c'est que nous avons le sous-système, qui est à ce module quand ils sont tous assemblés et vendus. Et même avec ce petit peu de réflexion et de planification, nous avons maintenant un moyen de diventer peut-être même. équipes Howard travaillent. On va travailler en équipe du côté des affaires. On va travailler en équipe sur le côté fiscal des particuliers. On va avoir un travail d'équipe ici, un travail d'équipe sur celui-ci, un travail d'équipe sur celui-ci. Peut-être qu'une équipe travaillera sur cette section et qu'une équipe travaillera sur cette section et vous pouvez voir nous avons déjà la capacité de diviser la tâche et de devenir plus efficaces. Et enfin, avec le processus d'architecture logicielle, nous devons garder tout un tas de choses à l'esprit. Et vous pourriez voir que cette liste est vraiment, vraiment, vraiment difficile. C' est en fait de Wikipédia, ce site, si vous ne le mettez pas pour jeter un oeil à ce à quoi ces liens vont, mais ce sont tous ces termes que nous voulons penser. Peut-être voulons-nous seulement penser à cinq ou six de ces termes vraiment, vraiment en profondeur. Mais nous voulons nous assurer que nous réfléchissons à des choses comme, vous savez, est-ce fiable ? La fiabilité de cette architecture ? Quelle est l'efficacité de la résolution de notre projet ? Quelle est la durabilité ? Peut-être qu'on résistera à l'épreuve du temps. Sera-t-il cassé avec plus de données ? Euh, peut-être qu'on veut examiner la capacité de reproduction. Est-ce que ce sera facile de copier à nouveau à un autre problème ? Peut-être que nous avons abordé le même problème encore et encore. Alors peut-être que nous voulons concevoir une solution qui peut être reproduite plusieurs fois dans différentes parties. La vulnérabilité. À quel point est-il sécurisé ? Est-ce que ça va être hackable ? Est-ce que ce sera quelque chose qui comporte déjà un risque connu ? Chacun de ces consort pose de nouvelles questions qui nous permettent peut-être de revenir en arrière et d'affiner un peu notre architecture. La section suivante, nous allons en quelque sorte sauter dans la couche suivante d'architectures. Alors peut-être que nous avons conçu juste un peu de la façon dont notre projet fonctionne et a un contrôle . Full flow fonctionne et le prochain Maintenant, nous allons commencer à sauter dans juste un peu de la conception, aller un peu plus en profondeur pour sorte de hacher ces modules et les différentes parties et comment ils devraient interagir sauf 18. Processus de conception logicielle: notre prochaine étape dans le cheminement de l'ingénierie logicielle sera la conception de logiciels . Donc, nous avons traversé les exigences. Nous avons fait les exigences, les exigences naturellement dans les spécifications, qui sont encore une fois en quelque sorte plus des exigences techniques des spécifications . Nous passons ensuite à l'architecture. Nous avons une sorte d'idée avec les spécifications des exigences. Nous essayons donc de trouver un grand plan de jeu. Comment sont ces modules géants ? Comment vont-ils interagir les uns avec les autres ? Comment les sous-systèmes vont être divisés. Mais à travers cela, nous n'avons pas vraiment parlé de choses comme, quel code allons-nous utiliser ? Quel logiciel nous allons utiliser, quel logiciel de base de données nous allons utiliser. Et c'est là que la prochaine étape intervient, et ça va être le design. Le design est donc une étape où nous commençons à appliquer notre plan et notre idée aux solutions du monde réel. Donc, ce que je veux dire par Riel Rose Solutions, c'est que nous commençons à trouver comment prendre notre architecture, architecture,notre plan global et comment la concevoir ? Comment trouver différentes solutions pour créer cette architecture ? Donc, si notre architecture par exemple, appelait un retour et un serveur. Donc, nous allons faire comme un symbole de serveur là. Et puis nous avons en face de cela, nous avons peut-être une sorte de classe de contrôleur et ensuite peut-être une page Web. Peut-être que c'est comme ça que notre truc est. On fait comme, une sorte de contrôleur de vue modèle. Alors, quelles technologies allons-nous utiliser ? Qu' est-ce qu'il va être de retour en cours d'exécution sur un système d'exploitation basé sur Peut-être Lennox  ? Et à partir de là, notre serveur va faire fonctionner une base de données ? Peut-être que quelque chose comme mon SQL est Quel sera notre milieu ? Est-ce que ça va être Ah, est-ce que ça va être le JavaScript ? Est-ce que ce sera peut-être sur le serveur lui-même, peut-être quelque chose comme PHP ou qui est en quelque sorte sur ces deux, est pourquoi c'est généralement une chose du milieu. Il peut être sur la page Web, mais il exécute effectivement la commande serveur. Donc peut-être que c'est une classe de contrôleur PHP sur notre page Web va être HTML. Ça va être un cadre ? Peut-être que nous utilisons quelque chose comme, si vous en avez entendu parler, WordPress, qui est ce genre de cadre ? C' est comme un dragon dans le créateur ou même, ah, ah, compagnie comme Wicks. W I. X est une entreprise où vous pouvez en quelque sorte glisser et déposer et concevoir vos solutions, mais elle couvre tout cela aussi bien. Alors peut-être que c'est une idée. Donc vous pouvez voir que nous avons un peu mis au point ce plan général de la façon dont nous voulions mettre place les choses, même si c'est plus compliqué avec, vous savez , tout un tas de boîtes bougent de différentes manières et et maintenant il est temps de regarder dans chacune de ces boîtes et de déterminer quelle est la solution du monde réel qui va résoudre cela maintenant à nouveau, tout comme dans les exigences où nous ne voulions pas dépasser nos limites et accidentellement entrer dans la conception de la conception a une limitation à. Nous ne voulons pas entrer accidentellement dans la mise en œuvre, ce qui est la prochaine étape ici. Le design n'est pas codage et le codage n'est pas conçu, ce qui signifie que nous ne commençons pas par construire le framework ou quoi que ce soit du genre. Tout ce que nous essayons de faire, c'est de trouver les solutions du monde réel qui existent. Qu' avons-nous besoin de créer, quelle technologie nous allons utiliser pour créer cela. Et quel genre de plan de jeu pour faire ça ? C' est le design. Maintenant, bien sûr, vous faites un peu de codage exploratoire ici et là. Voyez si une idée fonctionne, c'est comme , oui , vous savez, ces trois lignes de code ici, ils font ce que je pense. Donc on va mettre ça un design. Il n'y a pas delimite stricte ici, mais ce qu'on dit, c'estde ne pas sauter directement dans le revêtement de cette étape. limite stricte ici, mais ce qu'on dit, c'est Ce n'est pas ce qu'est le design. Um, le design est purement à venir avec un plan plus détaillé de l'architecture. Et aussi, chaque fois que nous parlons de design, nous devons aussi comprendre qu'il a une sorte de double signification ici. Le design est à la fois l'activité et le produit. Donc, l'activité travaille à concevoir un logiciel comme où vous avez une équipe de personnes et ils travaillent tous activement, vous savez, à trouver comment ce logiciel devrait interagir. Donc, les gens ici, comment ces offres devraient interagir. Maintenant, le produit est aussi la conception. C' est le document de conception. C' est donc un nom, ce qui signifie que c'est le document lui-même. C' est le produit final, quelque chose que vous pourriez gérer à la maison et ils comprendraient exactement comment fonctionne votre logiciel . Donc, quand nous parlons de conceptions, nous pouvons parler, ces deux choses étaient à la fois la conception du produit, et nous créons un design pour le produit. L' étape suivante, nous allons commencer à entrer dans les étapes de la conception en passant par les questions que nous devons poser les problèmes que nous devons résoudre. 19. 4-2 étapes de conception: passons un ensemble général d'étapes de conception pour les logiciels. Donc, la raison pour laquelle je dis cela, a dit le général c' est que ce n'est pas une solution unique. Il pourrait y avoir un autre ensemble de principes de conception à l'entreprise A Uses par rapport à l'entreprise B. Cependant, si c'est votre introduction au design, c'est un bon début, un bon endroit pour commencer chaque fois que vous pensez au design. Nous avons donc huit étapes ici, et ces étapes pourraient être aussi détaillées ou non détaillées que vous le souhaitez. quelque sorte. Ce que vous mettez, c'est ce que vous obtenez quand vous faites quelque chose comme ça. Si vous passez plus de temps ici, vous passerez moins de temps et de mise en œuvre et de revêtement. Cela dépend donc vraiment de ce que vous voulez faire. Parce que beaucoup de fois, vous trouverez en fait des bugs, des problèmes architecturaux et des problèmes de conception dans la conception ici que vous ne trouverez pas tant que vous n'avez pas déjà couvert la chose jusqu'à ce que vous ayez déjà passé, vous savez, 400 heures de revêtement et puis vous réalisez que vous devez revenir en arrière et refaire quelque chose, donc si vous passez beaucoup de temps ici, vous pouvez beaucoup de temps gagner beaucoup de temps à l'avenir. Donc, nos pas fonctionnent comme ça d'abord, c'est que nous allons briser le plus gros problème en petits problèmes. Si nous concevons, par exemple, Amazon si nous le voulons. Si nous avons cette idée de cette société appelée Amazon et que nous voulons développer ce site Web où ce sera un commerce électronique en ligne et que les gens peuvent, vous savez, envoyer leurs produits à nous et à un tas d'entreprises et venir à Yada, Yada, etcetera il y aura beaucoup de problèmes dans leur. C'est un problème qui va avoir une tonne de problèmes généraux. Et à partir de ces problèmes généraux, nous allons avoir des problèmes plus petits et plus petits jusqu'à ce que nous ayons quelque chose d'un peu plus gérable. Si nous allons avec un exemple légèrement plus petit, cependant, par exemple, dire celui avec le travail, qui crée un site Web, disons que l'un de nos problèmes est la base de données la façon de stocker nos données dans le back-end. Et donc avec ça, c'est notre problème. Ça va être le gros problème l'a divisé en un problème plus petit, qui est comment faire la base de données ? Que faisons-nous pour mettre la base de données en marche ? Donc, dans cette situation, nous l'avons décomposé en un problème de conception de base de données. Maintenant, nous devons comprendre chacun de ces problèmes. Donc, par exemple, si nous faisons cela, nous pouvons le faire un par un. Ou on peut le diviser en un tas de petits problèmes, puis passer à l'étape 2. Et une fois que nous l'avons décomposé plus loin, nous pourrions passer à l'étape 3, etc. Je vais juste faire une sorte de réunion de but ou d'approche de haut en bas, nous allons avoir un problème peut être l'un des nombreux problèmes, par exemple, et puis nous allons juste descendre, étape par étape, sur et plus comme ça. Alors nous en avons besoin. Maintenant, comprenez ce problème ? Quel est le but de ce problème ? Pourquoi avons-nous ce problème ? Le document sur les exigences pourrait être utile ici parce que les documents sur les exigences devraient nous indiquer ce que nous essayons de résoudre. Et maintenant, nous avons une sorte de moyen de revenir en arrière et de regarder, peut-être les exigences. Document dit quelque chose comme, nous avons besoin de stocker les informations de l'utilisateur. Donc, si nous avons besoin de stocker les informations de l'utilisateur. , Bien sûr,nous avons besoin d'une base de données pour ça. Peut-être. Nous devons effectuer des transactions. Si on veut faire des transactions, on va avoir besoin d'une base de données pour ça. Et nous pouvons en quelque sorte énumérer toutes les différentes parties de ce problème informations utilisateur, transactions, images, etc. pour s'adapter à notre problème. Et une fois que nous avons compris tout cela, nous avons maintenant une idée de la base de données que nous devons concevoir. Nous devons donc maintenant identifier des solutions potentielles. Quelles solutions existe-t-il pour nous aider ? Il existe quelque chose appelé AWS Amazon Web services. Nous avons que nous pourrions construire. Nos propres serveurs sont peut-être notre propre serveur. Nous pourrions acheter de l'espace serveur sur une autre société de pays pour l'acheter quelque part . On construit le nôtre, mais on l'envoie à un endroit d'achat. Nous pourrions utiliser différentes technologies comme une base de données My SQL. Une base de données régulière sauvée hors de sa place, peut-être une base de données sans SQL. Sont toutes ces différentes options Et c'est là que nous devons vraiment ouvrir nos esprits et trouver le plus de solutions possible au problème. Nous ne voulons pas entrer dans une sorte d'état d'esprit d'Ok, nous allons travailler avec AWS, et ce sera ceci et ça sans aucune raison pour cela. Peut-être que la société dit peut-être que la société de design ou le client dit que nous devons utiliser huit d'entre nous. C' est très bien. C' est une exigence que quelque chose qui contraint, nous n'avons pas le choix. Dans ce cas, ça va aller dans nos documents de conception, seulement huit d'entre nous. Mais si nous n'avons pas cette contrainte, si nous avons la possibilité de trouver différentes solutions, alors nous devons trouver cette mini solution le plus possible afin de nous assurer de choisir la meilleure . Parce que si nous sommes juste un tunnel de vision nous-mêmes et que nous ne nous concentrons pas ou ah, concentrons pas ou ah, nous allons avoir un problème où une meilleure solution aurait pu être disponible. L' étape suivante consiste à décrire les abstractions de solution. Alors, qu'est-ce que la solution ? Abstraction ? Une solution ? abstractions sont des choses comme des documents de conception qui ne sont pas techniques. Donc, il dit que nous avons un modèle X ici que les contacts, modèle, pourquoi et ce que ce flux de contrôle. Ça remonte au modèle W. et ça contacte ça. C' est une sorte de cette façon d'utiliser des graphiques et des modèles comme ça ici pour trouver un plan global pour notre logiciel. C' est donc une abstraction. C' est ainsi que nous allions mettre en place notre base de données afin que vous puissiez voir que nous avons ah utilisateurs colonne un poste principal ou la table des utilisateurs poste principal employés, poste d'administrateur. Et puis tous ces éléments et ils se connectent tous de cette façon. Maintenant, c'est un peu plus loin du côté technique que certaines abstractions pourraient aller, mais c'est bon. Nous avons que vous savez, au lieu de mettre tout ça ici, on pourrait juste trouver les noms de table. mettre tout ça ici, Ce serait une bonne abstraction pour que nous puissions décrire comment nous allons stocker les données . Mais vous pouvez voir ce que cette table ici. Nous avons une très bonne idée du fonctionnement de la base de données. Donc on l'a choisi. Nous allons utiliser la base de données my SQL dans cette situation, et l'étape suivante est le genre d'abstractions est à venir avec ces modèles. Peut-être que c'est comme ça que fonctionne le contrôleur. Et ce graphique que je viens de vous montrer, ce graphique est peut-être ce module ici. Et puis peut-être que c'est ici, euh peut-être comment les données vont entrer et sortir dans les choses organisationnelles, et qu'on puisse en quelque sorte diviser ça en d'autres. Et fondamentalement, ce que nous faisons, c'est de répéter ce processus encore et encore jusqu'à ce que nous ayons réglé tous ces problèmes. Mémoriser dit qu'on l'avait fait, comme on l'avait fait. Peut-être ces problèmes qui se sont décomposés en ces problèmes, etcetera. Donc on va essayer de tout abstraire jusqu'à ce qu'on finisse. Jusqu' à ce que nous ayons cette sorte vraiment, vraiment top down sorte de niveau sur tous les différents composants et idées sur la façon dont tout fonctionne ensemble jusqu'à ce que ces abstractions soient faites. Puis une fois que nous avons fait tout ça, une fois que toutes ces abstractions sont en quelque sorte comprises ici. Nous allons ensuite passer aux prochaines étapes ici. Donc, beaucoup de fois, nous voulons une boucle ici jusqu'à ce que nous trouvions tout et ensuite nous pouvons passer à l'étape suivante et aux étapes suivantes un peu plus avancées. Suivant. Beaucoup de gens ignorent juste parce que c'est un peu difficile à faire et vous devez avoir l' expérience pour le faire, mais ce sera en fait de coder la chose sans enduire la chose. Rappelez-vous, nous avons dit que le design n'est pas un code. Ce n'est pas un code qui est important. Cependant, cela ne signifie pas que nous ne pouvons pas déterminer comment tout va interagir. Donc, ce que je dis avec cette étape, c'est que nous allons réellement créer les composants comme ça, et ensuite avec chacun de ces composants allaient venir avec peut-être qu'il va utiliser cette classe et cette classe va avoir cette cette méthode, cette méthode. Vous savez, cette méthode parle pour entendre cette méthode parler. Pour entendre cette méthode, on va regarder encore plus loin. Quelle est cette méthode de transfert ? Peut-être que c'est le transfert en tableau. Et comment trions-nous ce tableau ? Peut-être qu'on utilise un algorithme appelé T. Peut-être que nous utilisons un algorithme appelé Merge Sort. Alors nous entrons dans, genre, vraiment, vraiment, des détails grossiers de tout ça. Nous commençons à aller pièce par pièce et à venir avec cette sorte d'arbre de classe géant, qui pourrait être vraiment, vraiment, vraiment, vraiment grand si vous planifiez tout ça. Mais à la fin, nous avons en fait ce grand document où tout le monde peut aller le regarder et comprendre comment le programme fonctionne sans jamais faire tourner un serveur ou un développement. Ils voient juste tout le code là-bas, ce processus. C' est important. Mais je le ferai. Je vais en quelque sorte le professer avec ça, et on en parlera plus tard. Dans le cours. C' est très, très fastidieux. Et il y a tout un tas de frais généraux et la plupart du temps. Une fois que vous concevez ceci, les choses changent et puis il n'est pas mis à jour, donc il devient obsolète et fondamentalement inutile. Donc, même si ces étapes sont citées sans citation importantes dans le processus de conception, nouveaux modèles de nos jours en font une sorte de renoncer à cela pour développer solutions plus rapides et plus rapides. On jette en quelque sorte la documentation juste un peu parce qu'on n'a pas besoin de livres. Nous n'avons pas besoin de livres sur la documentation de notre logiciel empilé haut et alors pas réellement avoir de logiciel que nous pouvons montrer pour elle. Nous avons juste ce très, vraiment bon design, donc il y a un équilibre là, et c'est là que nous commençons à parler de la méthodologie agile plus tard, mais juste une sorte de vouloir jeter ça dedans. Il y en a si vous allez juste à ce cours, vous savez, conférence par conférence. Ne pensez pas que vous devez le faire à 100% parce que beaucoup de fois n'est pas réaliste, et les gens en quelque sorte le jeter dehors. Cependant, comprendre peut-être les principes de base vous aide quand vous arrivez à cette autre partie, parce que maintenant vous comprenez ce que vous abandonnez pour obtenir cette vitesse, etc. Mais ce sont les étapes du design. Comme je l'ai dit, ça change tout le temps. Votre entreprise pourrait avoir un autre ensemble, mais c'est un bon ensemble pour en quelque sorte le prendre à partir de ce niveau d'idée et vraiment commencer à le décomposer en obtenir une bonne idée presque au niveau du code sur la façon dont votre programme devrait fonctionner. 20. Modularité 4-3: Nous parlons donc d'une bonne conception de logiciel. Ce que nous essayons d'obtenir, c'est cette idée de modularité. Donc la modularité est cette idée de prendre notre programme et de le diviser en différents modules. Rappelez-vous, nous avons parlé des sous-systèmes et des modules. C' est la même terminologie ici, mais avec la modularité, nous avons un ensemble d'objectifs en tête. On ne veut pas juste briser ça. Nous voulons le briser d'une manière intelligente. Et avec cela, ce que nous essayons de faire est d'atteindre les objectifs principaux. Donc, avec notre module, disons que nous avons un morceau de code ici avec notre module. Nous voulons que ce module soit indépendant, et c'est la partie d'accouplement. Indépendant signifie que toutes ses actions et données sur Lee effet lui-même. Nous n'avons pas de module ici le contrôlant à un module ici le contrôlant. Et puis peut-être qu'il contrôle un module ici. Et celui-ci contrôle ça, etcetera, etcetera. Ensuite, vous entrez dans ce très gros problème d'une erreur ici, pourrait réellement se représenter ici. Ou en fait, il pourrait aller se représenter jusqu'ici. Vous avez un problème quand ils ne sont pas indépendants, donc c'est l'un de nos objectifs. Et c'est ce qu'est le couplage. On aura toute une conférence à ce sujet. Et puis la cohésion est à quel point un module existe-t-il singulier ? Comme ce que je veux dire par singulier est, est-ce que ses objectifs sont singulièrement conçus ? Si les objectifs air singulièrement conçu affaiblissent, prenez ce module, nous pouvons le retirer du programme et le mettre dans un autre programme. Si nous avions une page Web et que cette page Web avait ce contrôleur dedans, et que ce contrôleur contrôlait tout, je veux dire, ça parle à un tas d'autres contrôleurs. Donc peut-être qu'il a en fait un assez bon couplage dans le sens où même s'il contrôle tout cela, rien ne le contrôle, et ses données sont en quelque sorte encapsulées en elle-même. Mais le problème ici est que c'est très, très bien adapté à ce problème, ce qui signifie que si jamais nous essayons de sortir ça ou de mettre un nouveau morceau, ça ne marcherait pas. Ceci est très, très spécifique à ce problème exact, donc il ne répond pas à un objectif de conception singulier. Il fait tout. n'y a pas d'objectif. Je veux dire, tu pourrais, tu sais, dire site de contrôle. Cela pourrait être votre objectif, mais c'est un objectif très large, et ce n'est pas quelque chose de très singulier, et c'est ce que nous parlons de cohésion. Donc, avec la modularité, nous essayons d'obtenir ces deux aspects. Nous essayons de les obtenir tous les deux comme optimal est possible. Nous essayons de le rendre très indépendant et ensuite très singulièrement conçu. Ainsi, les objectifs de la modularité, les objectifs de la modularité sont les suivants. Il y a un autre ensemble. Moi, si tu cherches les objectifs, ça va être différent. Pour toutes les personnes qui en parlent, cependant, c'est un ensemble que j'aime sortir. Le premier but de la modularité est l'abstraction. C' est essentiellement de prendre notre module et de le mettre dans une boîte noire pour éliminer la complexité. Nous parlons de cela dans l'information, se cachant un peu, mais l'abstraction est très importante car elle nous permet de concevoir des idées de plus haut niveau. Si nous devions, par exemple, travailler sur le langage machine, ce qui signifiequenous contrôlons en fait que les zéros tout le temps. On ne voudrait rien faire. Ce serait trop complexe, mais quelqu'un l'a abstraite à un langage d'assemblage, donc c'est assembly, et alors quelqu'un a effectivement abrégé ce langage d'assemblage jusqu'à probablement un autre , puis jusqu'à notre comme Java afin que nous puissions utiliser Java avec son. Il est relativement facile d'utiliser les fonctions, puis de le décompresser dans n'importe quel langage qui va au langage d'assemblage qui va au langage machine. langage machine contrôle réellement le ram etcetera. Donc, quand nous parlons d'abstraction, nous parlons de la capacité de prendre ces idées complexes et de les amener lentement sur supprimer cette ville complexe afin que nous puissions construire de plus en plus de programmes avancés, décomposer la capacité dans la capacité de composer. Ça veut dire qu'on peut démonter le truc et le remettre ensemble. Cela aide au débogage. Cela aide à ajouter de nouvelles fonctionnalités. Cela aide essentiellement, tout ce qui a à voir avec la maintenance, c'est que nous voulons être en mesure d'ouvrir ce programme, de prendre une partie de tout démonter et de le remettre ensemble. Et ça aide vraiment quand vous avez ces deux. Et la ligne est parce que vous pouvez enlever ce contrôleur et qu'il ne casse pas tout le site Web. Vous pouvez en fait, vous savez, chaud une nouvelle manette et peut-être une autre qui fait des choses légèrement différemment plus efficacement. Il devient très facile à maintenir après ce module, comprendre la capacité ou simplement comprendre la capacité si vous voulez les garder tous. C' est un mot ici. Ce que comprendre la capacité signifie, c'est que je pourrais sauter dans un module et comprendre instantanément de quoi il parle avec celui-ci. C' est très, très en profondeur. Ce pourrait être, disons, 35 000 lignes de code. Pensez-vous que vous seriez capable de comprendre ce que ce module fait tout de suite ? Probablement pas. Mais disons que nous avons ce petit module ici, et tout ce qu'il fait est de faire peut-être des mises à jour sur la base de données. Donc tout ce qu'il fait est de mettre à jour la base de données, et peut-être que c'est son nom. Et il y a, vous savez, fonctions comme mise à jour, entier, mise à jour, à jour, chaîne le mot de passe de mise à jour de l'utilisateur. On s'y penche. Nous disons qu'il y a un problème avec les mises à jour dans notre base de données. Nous pouvons facilement aller bien, vérifions la mise à jour, base de données, le dossier ou le fichier, et c'est très facile. Très rapide à comprendre. Le suivant est la continuité. La continuité est un peu une idée où vous avez, disons que vous utilisez Constance est d'une très bonne façon de le dire. Nous avons X égal à trois. Donc, au lieu d'avoir dans chacun de ces aspects, une variable de X est égale à trois X égal à trois X égal à trois X égal à trois X égal à trois X égal à trois X égal à trois X égal à trois. Imaginez si maintenant, dans notre situation, X équivaut à quatre. Eh bien, maintenant nous devons passer par chacune de ces choses et les changer en quatre, ce qui va être le cas ou nous allons en manquer un et ensuite nous allons avoir des erreurs bizarres commencent apparaître. Ça allait devenir difficile à entretenir. Mais si nous avions un dossier constant, nous avions un fichier constant ici avec ce qui dit, X est égal à quatre. Eh bien, alors tout ça pourrait juste faire référence à ce fichier de Constance et ça devient un peu désordonné maintenant. Mais j'essaie, tu sais, tu sais, ramener à la maison ce point juste là. Est-ce que si nous avions ce dossier constant là-haut, alors tout ce que nous avons à faire est de le changer en un seul endroit, et il sera continu tout au long de notre projet. Donc, avoir cela à l'esprit est très important aussi et enfin protéger la capacité la façon dont nous pouvons protéger les données est si nous gardons très, très sorte de déverrouillage dans des fichiers spécifiques, nous n'avons pas, vous savez, 85 fichiers différents entrent en contact dans la base de données. Nous avons un seul contrôleur ou un seul ensemble de contrôleurs qui le font. Cela nous aide non seulement avec des conséquences involontaires, mais aussi contre les hacks et autres choses. Parce que si nous avons 86 points d'entrée différents dans notre base de données, tout ce qui doit arriver est que l'un d'eux doit échouer avant que quelqu'un ne saute. Il est donc très important de contrôler cela. la Etlamodularité vous aide à maintenir et à obtenir une sécurité plus forte. C' est donc l'introduction de la modularité. Dans les prochaines conférences, nous allons parler de la dissimulation d'informations et de l'encapsulation de données, qui sont d'autres locataires clés de la modularité. 21. 4 à 4 caches d'informations et Encapsulation de données: Donc, la prochaine sorte d'étapes de la modularité ou les prochains locataires de la modularité, nos informations cachant l'encapsulation des données de fin. Et ces deux sont vraiment juste des moyens d'abstraction et de l'importance de l'abstraction. Donc, le 1er 1 est l'information qui se cache, et c'est, vous cachez la complexité dans une boîte noire. Mais quand nous parlons d'abstraction et que nous parlons de la façon dont vous pouvez l'extraire du langage machine et l'amener jusqu'au haut pour que nous puissions faire des choses de plus haut niveau, eh bien, eh bien, c'est ce que fait la dissimulation d'informations. Il cache la complexité dans une boîte noire. Chacun d'entre eux est une boîte noire qui cache la complexité. Lorsque vous écrivez des choses pour le langage d'assemblage, vous utilisez des choses que ce langage ici, le langage machine a exposé quelques yeux AP. Certains commandent certaines fonctions. Vous utilisez ce code pour construire ceci, puis avec le langage d'assemblage, vous créez un nouvel ensemble de fonctions, contrôles et de commandes, que cette prochaine langue apportera. Une fois ses prochaines langues terminées, vous créez un autre ensemble de codes et de commandes, puis Java. En plus de cela va commencer à appeler ces codes et demandes qui appelleront ces codes et commandes qui parce que ceux qui feront des choses comme déplacer la mémoire autour. Donc avec ça ici, ce que nous essayons de faire avec les informations cachées, c'est de cacher cette complexité dans une boîte noire. Nous pourrions le faire avec des choses appelées comme des fonctions macro classes, méthode l'air, tous juste les termes techniques que nous utilisons chaque fois que nous programmons. Mais disons que nous avons une boîte noire appropriée juste ici et une autre boîte noire juste ici et ce qu'ils sont est un dispositif de cryptage, cryptage puis un dispositif de décryptage. Donc si, par exemple, on a mis 35 ici et que ça sort avec je ne sais pas, pourquoi 62 ? Donc c'est la sortie. Et puis maintenant nous prenons t pourquoi 62 le mettre dans le décryptage er. Et il en sort comme 35. Doit-on comprendre comment il s'agit de chiffrer et de déchiffrer pour pouvoir utiliser ces deux boîtes pour pouvoir utiliser ces deux programmes ? Non, pas du tout. Tout ce qu'on a besoin de savoir c'est, qu'est-ce que c'est ? Entrée. Et était-ce en sortie ? Et nous sommes complètement et totalement d'accord avec l'utilisation pour toutes ses fins. Les internes ne sont pas nécessaires pour être connus, et c'est très important. C' est quelque chose qui est très utile. Chaque fois que nous concevons des programmes, surtout avec disons, nous concevons un programme pour un, disons , un constructeur automobile. Nous avons tout ce code qui peut être auto-génère du code en arrière-plan dirait que c'est , ah, ah, auto conduite quelque chose de voiture. Mais nous ne sommes pas des voitures. On ne comprend pas à quoi ressemblent les voitures. On ne comprend pas comment tout est censé être programmé. Donc, ce que nous faisons c'est nous programmons un ensemble de boutons, un ensemble de tables et d'interrupteurs, un peu comme un petit panneau de contrôle ici et avec cette programmation. Nous faisons ensuite abstraction de tout le minutieux de la programmation réelle. Les quatre boucles, le while boucle les fonctions des classes de bibliothèques de Macron. Nous résumons tout cela, et nous permettons à un technicien d'appuyer simplement sur des boutons et d'entrer des valeurs, puis notre code fera le reste. On a donc donné le contrôle à l'ingénieur automobile Mawr. Nous leur avons donné le pouvoir d'utiliser notre code avec leurs trucs, et c'est l'importance de se cacher des informations, c'est qu'il permet de construire des choses de plus en plus complexes . Il vous permet de créer une fondation, puis de construire sur cette base et de continuer à créer des choses plus fortes et plus fortes au fil du temps. Et c'est ainsi que les programmes deviennent de plus en plus complexes au fil du temps, c'est que nous nous améliorons lentement à cette abstraction et que nous allons de plus en plus sauf l'information. Je pense que c'est l'idée de cacher la complexité dans une boîte noire. Le suivant est quelque chose appelé Data Encapsulation, et cela vous remarquerez qu'ils sont en fait assez proches. Celui-ci est une sorte d'information qui se cache, alors que celui-ci pourrait être connu sous le nom de cache de données, donc ils ont une relation. Mais celui-ci est tout au sujet de cacher les détails de l'implémentation à l'utilisateur et Onley fournissant un ensemble d'outils pour manipuler les données. Ce que nous entendons par ceci, c'est, disons que nous avons une classe ici et qu'une de ses variables est, disons, um, um, des données de transaction. Donc peut-être le montant d'argent, alors on a mis la transaction ici. Maintenant, pourquoi devrions-nous mettre une fonction get et la fonction set ? Pourquoi ne pas avoir ce qui est dans cette classe s'appelle les services bancaires. Pourquoi ne pas autoriser ce programme ici à appeler quelque chose comme une transaction de points bancaires équivaut à 50. Pourquoi ne pas autoriser ça ? Pourquoi ? Pourquoi ne pas autoriser cela à faire un appel direct à la transaction ? Eh bien, ce genre de casse l'idée d'encapsulation de données. Si nous faisons cela, alors soudainement nos données peuvent être manipulées de quelque manière que ce soit, forme ou forme, et nous n'avons aucun contrôle sur elles. Nous ne pouvons pas empêcher l'utilisateur de mettre des données invalides et de gâcher non seulement nos algorithmes, mais peut-être l'intégralité de notre base de données. Donc, avec l'encapsulation de données, ce que nous faisons est de créer les getters et les centres. Donc, si nous voulons savoir ce qu'est la transaction. Il appelle le git, donc il appellerait le git, puis la fonction get retournerait la valeur Cette fonction get pourrait être très importante , car peut-être qu'elle a une couche d'authentification dessus. Peut-être qu'il a une couche d'authentification avec cela. Cela signifie qu'un mot de passe devrait être entré avant que cette classe ne donne des données. Et c'est très important dans le monde bancaire. Vous ne voulez pas seulement que les gens puissent programmer des choses et extraire directement du serveur. Tout ce qu'ils veulent. Alors obtiens son aide à protéger ça. Et puis un centre est beaucoup de fois mawr important. Le centre nous empêchera de faire certaines choses. Donc, nous allons appeler une fonction à définir. Peut-être que nous disons que nous voulons régler la transaction à 50. Eh bien, le centre va avoir une simple déclaration si vous savez moins de zéro retour. Donc, si moins de zéro retour, je ne sais pas, erreur quelque chose de vraiment, vraiment simple. Et c'est un air de retour moins que simple, inférieur à zéro. Et pourquoi est-ce important ? Eh bien, nous faisons des transactions et nous voyons continuer à facturer les gens négatifs. 50 $. Eh bien, on va commencer à obtenir de l'argent à notre façon, et c'est un problème. Nous ne voulons jamais qu'une transaction soit inférieure à n'importe quel argent, car au lieu de facturer notre compte, nous prenons simplement de l'argent aux gens. Ainsi, un simple centre ajouterait une autre couche de sécurité et protégerait également l'intégrité de nos services bancaires en ce sens qu'il peut y avoir plus de chèques ici. Et nous ne pouvions pas déposer, disons 1 000 000 000 000$ par accident, soit il pourrait y avoir une partie supérieure qui pourrait l'escalader comme un manager ou quelque chose comme ça . Mais dans l'ensemble, l'idée de l'encapsulation des données est en quelque sorte de protéger les données, ce qui en fait. Nous exposons donc uniquement ce genre d'outils pour manipuler les données au lieu de simplement permettre l'accès aux données et de les modifier de toute façon, forme ou forme que nous voulons. Et donc, avec une bonne conception logicielle, nous pensons également à cette encapsulation de données. On pense à pourquoi. Pourquoi on laisse les gens saisir ces données ? Pourquoi ne pas faire un getter dans une fonction centrale ? Pourquoi ne pas le protéger d'une manière ou d'une autre, ou créer une classe entière qui s'occupe de ce genre de choses pour protéger l'intégrité de notre base de données ? 22. Introduction à 4 à 5 coutures: Dans la dernière conférence, nous avons introduit cette idée de couplage. Et donc avec le couplage, ce dont nous parlons, c'est la force des connexions entre les modules et les sous-systèmes. Maintenant, avec le terme « force », nous avons une sorte d'idée d'une connotation positive. Cependant, avec le couplage, nous ne voulons pas de cette force. Nous voulons une réelle faiblesse entre les modèles. Nous ne voulons pas que les modèles, modules et sous-systèmes soient étroitement couplés. Et donc quand on parle de couplage, on veut dire qu'ils dépendent l'un de l'autre. Donc, par exemple, si nous avions tout un tas, un petit ensemble de modules et de sous-systèmes ici, disons qu'il y a juste ce genre de lien et de chaîne, comme ça et, vous savez, votre programme est complexe ou non complexe, nous pourrions avoir une section étroitement couplée, et quand une section est étroitement couplée, cela signifie que si nous faisons un changement ici, par exemple, nous vont alors devoir aller à ce fichier et faire un changement. Allez dans ce fichier et ils pourraient changer. Accédez à ce fichier et apportez une modification. Allez dans ce fichier et ils pourraient changer etcetera etcetera jusqu'à ce que nous ayons fondamentalement tout changé afin que cela fasse fonctionner le changement ici réellement. Cela a tout un tas d'inconvénients. Le 1er 1, c'est juste le temps. Il nous faudra du temps pour comprendre ce qui est exactement couplé avec cette Habituellement faire essai et l'air. On dirige le programme, dit-il. J' espère qu'il y a eu une pause ici. Donc, nous allons le changer là-bas, relancer le programme. Il y a eu une pause ici. Allez le changer là si vous avez une meilleure documentation, peut-être un peu plus rapide, Mais beaucoup de fois, vous pouvez. Je dois aller à cette pause et réparer. La prochaine partie est, est qu'il va juste prendre fondamentalement la capacité de maintenir le programme et de le réduire . Parce que maintenant, quand nous apporterons ce changement, peut-être que nous avons fait tous ces changements. Mais on a oublié cette affaire ici. Et cette affaire Onley fonctionne, vous savez, peut-être une fois par mois, peut-être que c'est un code bizarre qui est comme, ah, truc de serveur qui fonctionne une fois par mois, et on oublie de le changer ici . Donc nous passons tous les tests et tout ça, et ça a l'air super et puis dans un mois, nous avons ce bug géant qui arrive. On ne sait pas d'où ça vient. Eh bien, c'est parce que vous êtes étroitement liés ensemble. C' est à cause de ce changement que cela arrive. Et c'est encore pire quand on arrive à quelque chose comme ça où il est en fait là où ce problème est parce que maintenant on doit penser, qu' est-ce qu'on change ? Peut-être que nous ne regardons que ces deux dossiers ou que nous n'avons pas vraiment changé ici. Oh, c'est en fait ce changement majeur ici qui a causé cet air en cascade si étroitement couplé . Les programmes sont généralement mauvais. Vous n'allez pas vraiment arriver au point de ne pas avoir de couplage, mais vous voulez essayer de le rendre aussi lâche que possible. Donc, avec un couplage serré, nous avons l'idée de variables partagées et d'informations de contrôle. Donc tout cela ici est l'idée d'informations de contrôle. Donc, nous avons ces méthodes et les classes qui parlent toutes directement aux autres modules contrôlent directement les autres modules, donc les changements dans l'un nécessitera des changements dans tous les autres. Et puis si nous avons l'idée de variables partagées, c'est là que nous avons ce genre de liste géante de variables, et chaque programme en bas utilise ces variables. Donc, si on fait un changement ici, il y a beaucoup de fois qu'on va vraiment devoir faire des changements dans tous les fichiers de fond aussi. Et cette structure peut en fait être bénéfique dans certaines situations qui peuvent aider à réduire d'autres domaines de problèmes. Mais cela pourrait également créer un problème. C' est pourquoi toute cette idée du design nous avons ce genre d'équilibre que nous devons dessiner. Il n'y a rien qui soit parfait. Donc on a dû trouver ce qui est le plus parfait pour l'obtenir. Ce qui est le plus optimisé que nous puissions l'obtenir, et c'est la direction que nous devons prendre. Et puis la décentralisation de l'Etat crée doit être un voir leur crée couplage lâche. Ce que nous entendons par là, c'est la décentralisation de l'État, c'est là que nous avons ces petits segments ici. Peut-être que ces deux-là sont couplés ensemble, mais nous avons une autre section où ces deux-là sont couplés ensemble et, vous savez , etcetera, etc. Mais dans l'ensemble, nous n'avons pas le programme dans son ensemble, vous savez, tous les sens. Nous avons presque ces petits États qui font tous leurs propres affaires avec peu communications entre les deux. Et cela nous aide à nouveau avec tout le débogage et des trucs comme ça plus tard. Donc dans la prochaine conférence, ce dont nous parlons en fait, c'est que nous allons parler des trois niveaux de couplage qui vont être le couplage serré, le couplage moyen et ensuite le couplage lâche. Et dans il y a de petites catégories dans chacun d'eux couple de contenu dans le contrôle externe commun , la structure de données, message de données et puis aucun. Et encore une fois, comme je le disais tout à l'heure, aucun n'est assez peu pratique. y a probablement presque aucune application qui n'utilisera aucun couplage. Mais nous voulons être en mesure de passer par toutes ces étapes afin que nous puissions examiner un programme et comprendre comment, couplé à ce programme, il est serré et, vous savez, est-ce bon ou mauvais ? 23. Coupler 4-6 étroits: Parlons de notre première sorte de classifications de couplage, et ce sera le pire scénario de couplage. Et c'est l'idée d'un couplage serré. Donc, un couplage serré nous avons un tas de modules qui sont tricotés ensemble. Un tricoté étroitement avec ce moyen est que si nous faisons un changement dans un module, nous allons devoir faire un changement dans tout un tas d'autres modules pour le faire afin que le programme ne casse pas cela pourrait être un peu divisé en ce genre de sous- , ces collants air communs, de types d'accouplement serré et qui va être dans le contenu, commun puis externe. Donc on va faire un par un des devoirs et tu verras qu'ils sont une erreur très facile à faire. Mais ils peuvent causer de très gros problèmes. Le 1er 1 est avec couplage de contenu. Donc, ce que c'est que c'est quand un module modifie plus se trouve sur le fonctionnement interne d' un autre module. Dans ce scénario, nous avons le module A, puis le module B et le module A saisissent directement du module B. Il saisit le débit de données du module B et l'utilise pour ses propres choses. Disons, par exemple, que le module soit les données en question est une sorte de distance. Donc c'est une sorte de distance. Disons qu'en B, c'est représenté par des mètres. Une chose typique qui pourrait arriver. Peut-être qu'on l'a pris à partir d'un A p I. Peut-être que c'est la façon dont on l'a programmé. Mais les données ici en B sont des mètres. Eh bien, le module A veut convertir ça en Miles, donc ça va prendre des mètres et essayer de le convertir en miles. Donc tout ce qu'il fait. Est-il attrape directement de l'être. Il envoie un algorithme de conversion do no et fait ensuite ce qu'il doit faire avec. Maintenant, pouvez-vous voir le problème ici ? Le problème, c'est que si quelqu'un entre et veut modifier être, disons que nous avons aussi un autre ici qui fait la même chose. L' accaparement des données battues peut être la conversion d'une autre manière, mais c'est en supposant que B va rester le même. Et c'est le problème. Voici l'hypothèse que B ne changera jamais. Comme je l'ai dit, un autre programmeur vient ici pour être. Comme je l'ai dit, Il se rend compte que nous sommes en train de convertir 2 miles partout. Peut-être que la norme de nos jours est de représenter toutes les distances en kilomètres. Peut-être que c'est pour représenter toutes les distances en centimètres, même dans le système métrique. Vous commencez à avoir cette capacité à changer les choses. Nous pourrions également représenter toutes les distances en miles. Disons cependant, que nous décidons juste de changer cela de mètres, deux kilomètres, quelque chose qui pourrait être un changement très simple. Donc, en B, il va et fait le changement, Peut-être ce petit algorithme de conversion rapide et maintenant battre les données. Les données ici représentent les mètres. Le problème est que vous ne pouvez pas voir qui s'appuie essentiellement sur ces données d'ici. Il pourrait y avoir 1000 personnes appelant ou 1000 modules appelant ce petit extrait de données. Maintenant, chaque fois que nous changeons cela, tout d'un coup tous ces air vont casser un A et un C et tout ce qui est connecté se cassera parce que chacun d'entre eux supposait que c'était des mètres et ensuite se convertissait en fonction ce hypothèse. Donc à cause de ça, A va avoir un problème. Ça va se briser, va représenter cet insecte bizarre où se trouvent les choses. Peut-être, vous savez, une magnitude un peu à plus grande magnitude, un peu petit, cependant, Voir, Converti. Ce ne sera pas loin. Peut-être qu'il le convertissait en autre chose ici. Donc, à cause du changement à nouveau, ça va être une ampleur de notre indifférence ici aussi. Donc, à cause d'un seul changement, nous avons maintenant cassé tout un tas de modules. Et maintenant, nous devons passer par chacun de ces modules et les changer toujours et encore. Deux modules, pas la plus grosse affaire au monde. Mais si on avait 100 modules, ça devient un gros problème, parce qu'on va devoir corriger manuellement Ah, 100 modules. Et où n'avons-nous pas de plans pour nous dire lesquels sont brisés ? Nous avons juste à réparer une course à nouveau, voir quels freins ont été fixés, un qui roule à nouveau, voir ce qui casse et ainsi de suite. Ah, meilleure façon de le faire. Une sorte de façon que vous en sortiez, c'est avec les getters et les centres. Donc ce que c'est que vous créez ce genre d'interface que fondamentalement d'autres modules peuvent s'amuser et pourquoi cela est important est parce que si nous changeons les mètres ici, nous allons juste changer les deux fonctions ici, obtenir mile et obtenir kilo pour kilomètre. Donc, dans cette situation, si nous changeons de mètres deux kilomètres maintenant, tout ce que nous avons à faire est juste de retourner cela directement . Avant, Peut-être qu'il y avait comme, une fois 10 ou effectivement ah, diviser par je pense 100 pour obtenir des kilomètres de remorquage, puis envoyer cela et puis un mile. Il y a une grande équation pour ça. Maintenant, tout ce que nous faisons c'est que nous changeons ça pour représenter les kilomètres changer ces deux getters et centres et tous ceux qui saisissaient de tout ça sont parfaitement bien maintenant parce qu'ils reçoivent la même information. Nous avons fait un seul changement dans un seul fichier et tout est mis à jour au lieu de l' avoir au lieu de l'avoir pour que tout soit cassé. La prochaine chose que nous avons ici, c'est que nous avons un couplage commun. Donc, avec le couplage commun, nous avons cette idée de quand plusieurs modules ont accès aux mêmes données globales et les manipulent . Donc vous pouvez voir ça, nous allons tous être semblables. Mais juste un peu différent dans cette situation. Ce que nous avons, c'est que nous avons peut-être un gros fichier de Constance ou que nous avons ce genre de base de données presque interne où nous stockons des données et les retirons. Et nous faisons tout cela à partir de tous ces modules. Le problème avec ceci est que nous avons la capacité, par exemple, si celui-ci y écrit, et puis celui-ci saisit de là et puis pendant le processus de calcul, celui-ci écrit une nouvelle valeur, et celui-ci saisit cette valeur et celui-ci écrit une nouvelle valeur. On va commencer à avoir ces incohérences bizarres, ces bugs, ces changements vont se déplacer partout. Eso vous avez en quelque sorte ce manque d'intégrité des données, vous n'avez pas la capacité de contrôler les données qui arrivent et les variables peuvent commencer changer. Et disons que nous avons une petite erreur ici. Donc ce module ici, tous ces autres fonctionnent et d'une manière ou d'une autre il ne s'ajuste pas. Mais celui-ci fait juste une conversion légèrement erronée. Et donc quand il envoie ces données, cela rend cette variable corrompue. Cette variable est maintenant. n'y a pas d'intégrité avec ça. C' est en fait une variable incorrecte. Eh bien, le problème est que tout le monde saisit des mêmes données globales en lisant, en écrivant , en poussant, tirant ce genre d'air que celui-ci crée va se propager ici et ici et ici et ici, ici et ici et ici, et ainsi de suite et ainsi de suite. Et vous allez avoir ce problème où vous allez avoir un bug incroyablement difficile à suivre parce que le bug va se représenter dans chaque module. Et tu ne sauras pas que la petite ligne de code ici était l'air. Et c'est pourquoi le couplage commun, avoir cette idée de tout manipuler les mêmes données globales est mauvais. Si vous avez, par exemple, cependant, comme une liste de constantes qui ne changent jamais, n'est pas correct, le temps d'avoir ce genre de tout le monde saisit du même genre de liste géante de Constance. Maintenant, il pourrait y avoir de meilleures façons d'élaborer une liste géante de Constance, mais je veux en quelque sorte différencier ça tant que vous venez de là et ça ne change jamais, c'est parfaitement bien. Le problème apparaît est que le rôle le manipulant. Et si nous le manipulons, alors nous avons ce problème où de minuscules héritiers peuvent en cascade et casser tous les modules. Donc je voulais juste faire cette petite différence. Le dernier est le couplage externe. L' accouplement externe est lorsque plusieurs modèles ont un accès direct à la même chose que je dois. Donc, ce que c'est que cela pourrait être un A p I. Cela pourrait être, par exemple, contrôler la souris. Peut-être que vous avez un programme qui utilise tout un tas de modules pour saisir les données de la souris et faire choses avec cela. Mais on va en parler comme si c'était une IA. Le problème est le A P I. Le problème avec ceci est que si le A p I change son externe, c'est le genre de mot clé ici qui signifie que nous n'avons pas le contrôle sur. Nous n'avons aucun contrôle sur le fonctionnement de l'extérieur. Par conséquent, disons que nous travaillons avec Google. On utilise un de leurs yeux AP. Si nous avons 1000 modules, 1000 modules différents, donc nous avons un module. Écoutez les milliers d'hommes ici, et ils contactent tous Google un p I, et appellent une seule fonction. Écoutez les milliers d'hommes ici, et ils contactent tous Google un p I, Que se passe-t-il lorsque Google décide que nous n'aimons plus cette fonction ? On va le changer et on va changer. Ça peut être drastiquement ou peut-être juste un peu. On va changer un peu sa sortie. Le problème est, c'est que maintenant nous avons 1000 modules à nouveau qui ont cassé. Nous devons passer en revue et changer la façon dont nos modules gèrent les données 1000 fois différentes tout au long de ces derniers. Et cela pourrait être un très gros projet et un gros problème, surtout si vous utilisez tout un tas d'yeux AP et que cela se produit chaque semaine, vous pouvez voir les frais généraux qui seraient ici. Et si le nous avions à la place ap I contrôleur. Donc nous avons ce petit contrôleur ici, et ils parlent tous à ça avec des getters et des centres appropriés. Et puis cela parle à l'AP cool I. Donc Google fait un changement, puis tout ce que nous avons à faire est de faire un changement de ligne unique. Et puis tous ces air mis à jour en conséquence parce qu'ils sont juste qu'ils parlent à ça. Cette fonction qui fournit le Google un p I. Et c'est donc une façon de résoudre ce genre d'idée. Et encore une fois, c'est votre début à être couplé par le A P que j'entends. Mais c'est un pas mieux que ça, et nous pouvons en quelque sorte le décomposer avec un peu plus de processus de réflexion plus tard. Mais ce sont les pires cas d'accouplement. J' espère qu'il y en a différents. Ce sont plus de cas, bien sûr, pour le couplage serré de différents scénarios de Vincent. Ça peut arriver. Mais j'espère que vous comprenez. Fais ça. Le problème sur le thème global ici est que nous y accédons tous. Les mêmes données étaient à cheval et en saisissaient. Et si nous avons cette idée où une seule ligne de code peut casser 1000 modules différents, seule ligne de code peut même casser seulement deux modules, alors il y a probablement un problème là. Il y a probablement quelque chose que nous pourrions faire pour extraire ce contrôleur, extraire certaines de ces informations et résoudre ce problème. La prochaine conférence parlera du prochain niveau de ceci, ce qui est légèrement meilleur, et ce sera le couplage moyen 24. Couplage moyen de 4 à 7 supports: Alors passons à notre prochaine déchirure de couplage. Et ça va être un peu meilleur ensemble de couplage, mais encore quelques problèmes, et c'est un couplage moyen. Alors que nous nous rapprochons de plus en plus de perdre couple, vous commencerez à voir que peut-être certains scénarios pourraient réellement fonctionner pour ces domaines. Et peut-être que nous commençons à entrer dans le minutieux de, vous savez, sur l'optimisation de notre code. Et ce genre de décision que les concepteurs doivent prendre est, veulent-ils passer le temps supplémentaire, vous savez, concevoir des choses à fond, ou est-ce mieux juste pour obtenir le produit sur le marché ? Beaucoup de fois, il est préférable de mettre le produit sur le marché, afin que les gens puissent mettre certaines de ces choses là et espérer les réparer plus tard ou simplement dire, vous savez ce qui est un problème. Mais on va s'en occuper de toute façon. Et donc il suffit de garder cela à l'esprit est que nous n'avons pas besoin d'être parfait lors du codage de logiciels et il y a des exigences différentes, en fonction des différents projets. Mais de toute façon, le prochain niveau de couplage dont nous parlons est le couplage moyen, et donc le premier genre de classifications. Du côté de cela, question commune que nous avons est cette idée de couplage de contrôle. C' est donc quand les données sont passées qui influence la logique interne d'un autre module. Ce que ça fait, c'est que ça brise la mentalité de la boîte noire. Le module ne prend plus simplement l'entrée, fait quelque chose et produit ensuite la sortie. Maintenant, nous avons cette idée que nous devons réellement regarder dans la boîte noire pour comprendre ce que nous avons besoin de dio. Donc, au lieu de simplement pouvoir entrer trois, nous devons maintenant entrer des drapeaux, des contrôleurs et des commutateurs afin que nous contrôlions réellement les internes de ceci, ce qui, encore une fois, casse cette mentalité de boîte noire. Et il faut tous les modules que nous communiquons avec cet orteil. Est-ce que ces commutateurs sont impliqués ? Maintenant, où cela devient-il un problème ? Eh bien, disons que nous avons cette idée de données ensemble, donc nous avons ces getters et les centres fonctionnaient bien, mais au lieu d'être au centre au lieu de plages décider de son propre destin, faire ses propres choses, il attend un drapeau d'un A lui dit comment opérer en envoyant ce drapeau. Si vous n'avez pas entendu parler d'un drapeau qui combat juste vrai, faux ou une autre valeur, vous envoyez leur. Et en fonction de cette valeur, cela change le comportement. drapeaux internes sont parfaitement bien. Cependant, quand nous les faisons en externe, comme ici, nous avons ce problème où maintenant l'utilisateur a besoin de savoir exactement ce qui se passe dans ce module à contrôler, soit vrai ou faux, devrait être activé. Et cela devient un problème parce que encore une fois nous pourrions avoir 1000 modules différents sorte de communiquer et d'appeler cette fonction de données ensemble. Et si on change ça au lieu de vrai, on a peut-être fait une petite chose au lieu de la vraie. On va avec juste du thé au lieu de, euh, faux. On y va avec l'EPH. Donc, au lieu de ces deux-là, nous allons juste une sorte de changement peut être juste la sémantique, juste en regardant, l'esthétique de ça au lieu de, vous savez, vrai changement significatif. Mais de toute façon, cela casserait chaque module. Parce que chaque module est formé, il est maintenant réglé pour appeler ce drapeau. Donc, tous les changements à l'intérieur ici vont maintenant casser chaque module et vous voyez que ce modèle a été incapable de changer un module sans casser. Ah tout un tas d'autres modules, et c'est une sorte de l'ensemble. Le problème arqué avec des choses étroitement couple est cette idée que si on fait un changement , on casse tout un tas. Donc, cette idée de couplage de contrôle est de nouveau lorsque nous envoyons des drapeaux ou des signaux de contrôle à un autre module pour essayer de contrôler le flux de données ou les opérations sur ce module. Cela doit être brisé d'une manière plus intelligente afin que peut-être nous ayons un ensemble de données, un certain type dans les données de l'ensemble, autre type et ensuite définir des données de type différent. Vous savez, je dis que nous avons trois données différentes sont et que cela nous permet d'au lieu d'avoir à mettre des indicateurs de contrôle, nous pouvons juste appeler toutes les données d'ensemble dont nous avons besoin dans cette situation. Et donc au lieu d'avoir ce genre de module de contrôle bizarre où tout contrôle, nous avons maintenant un p I. Et nous appelons tous juste le P I. Donc si vous faites des changements, nous pouvons faire change à cela, a p I. L'idée suivante est ce couplage de structure de données et avec la structure de données. Couple dans ce que nous avons est que c'est quand plusieurs modules disent partager la même structure de données. Et donc la structure de données est exactement comme ceci dans un tableau ou une liste liée ou une autre sorte de structure que nous gardons les données ensemble Maintenant, le problème avec ceci est si nous appelons directement à partir de cette structure de données. Que se passe-t-il si nous voulons changer la structure des données ? Et s'il y a quelque chose de plus intelligent, une meilleure façon de l'implémenter ? Encore une fois, en descendant cette ligne de mauvais couplage ? Il va casser plusieurs modules. Disons qu'on utilise des appels de rayons. Donc on dit, tu sais, um, Array, disons juste que c'est un rayon A Donc on dit comme un cinq. Donc on fait des appels directs ici. A de font en fait un de deux, puis zéro. C' est des suppressions. C' est un 101234 quatre et cinq. Et c'est donc un de trois. Peut-être que nous sommes en train de fixer un égal de six ou quelque chose yada, etc. Mais le problème avec cela, le problème que nous avons chaque fois que nous appelons directement à partir de ce tableau est que si nous voulons changer cela à une liste liée et une liste liée ? On dirait quelque chose comme ça sera la liste liée. Ces appels ne fonctionnent pas. Donc, si nous avons changé, nous avons soudainement ce problème où tous ces appels cassent chaque appel comme celui-ci est maintenant cassé. Nous devons changer tout un tas de modules. Une façon plus intelligente de le faire serait orteil avoir presque une classe de contrôle de contrôleur de données. Donc, au lieu d'appeler des fonctions directes dans le tableau, ce que nous faisons est d'appeler un getter et un centre ici, et cela parlerait à la structure de données. De cette façon, chaque fois que nous changeons la structure de données autour, nous changeons juste chaque getter et setter ici. Et tout cela fonctionnerait parfaitement bien à nouveau. Eso comme au lieu de, tu sais, ce genre de cinq faisaient un appel direct. On va dire, peut-être avoir un index et ensuite on passera un cinq. De cette façon. Le fonctionnement interne de la façon dont nous obtenons le numéro cinq. On n'a pas besoin de savoir. On ne l'appelle pas directement. Au lieu de cela, nous prenons en fait ce genre de dépendance, et nous permettons à cela de contrôler toute cette logique de contrôle. Par conséquent, encore une fois, si nous venons de l'échanger vers une autre structure de données, inju liste de fuite ou une autre sorte de stockage des informations que nous avons créées. Nous ne pouvons pas simplement faire quelques mises à jour rapides dans cette classe de contrôleur dans tous nos modules a fonctionné parfaitement bien à nouveau. Donc, c'est le couplage de la structure de données. C' est un peu plus commun. Ce n'est pas la pire chose au monde parce que, vous savez, échange de structures de données n'est pas quelque chose qui se passe tout le temps, et nous n'avons généralement pas tout un tas de module c'est parler à la même structure de données, mais cela arrive. Et dans ces situations, nous voulons penser au lieu de peut-être contacter directement cette structure de données cherchant à construire une classe de contrôle afin que nous abstrayons ce contrôle juste un peu. Ce sont donc deux idées principales de couplage moyen. Tu verrais comment ils ne sont pas aussi mauvais que les autres où nous faisons des changements uniques en brisant des milliers de choses. Cependant, ils peuvent être mauvais si nous faisons de petits changements dans certains domaines de certaines façons très spécifiques , nous cassons encore tout un tas de modules. Prochaine élection, nous couvrons le dernier côté des choses, qui va être les choses de couplage lâches qui se passaient en quelque sorte pour des zones que nous voulons utiliser un peu de couplage à des fins stratégiques, mais gardez-le aussi lâche que possible. 25. Coupler 4-8 en vrac: Donc, le dernier niveau de couplage est celui de cette idée de couplage lâche. Donc, avec un couplage lâche, ce que nous avons est cet état de communication très optimal entre les modules. Donc, dans cette situation étaient seulement avoir des informations très pertinentes étant transmis d'un module à l'autre. Donc, le très lâchement couplé, ce qui signifie que nous pourrions changer un pour un autre et il n'y aurait pas de gros problème . Peut-être que nous devons changer une ligne de code ici et là pour le faire fonctionner. Mais ce ne sera pas ce projet géant. De plus, nous n'allons pas avoir ce problème de ces bugs bizarres en cascade partout parce que le train de données transmises va être très facile à suivre. Maintenant, nous ne visons pas ce n'est pas un couplage. Il y a donc cette catégorie de pas de couplage. Mais cela signifie simplement qu'il n'y a pas de communication entre les modules. Ou peut-être qu'on a juste un très, vraiment, très gros module. Donc vous savez, ce module qui a juste des informations tout le long, c'est complètement et totalement fou. Et vous pouvez déjà, vous savez, comprendre que ce serait un problème aussi. Est-ce que c'est ? Ayez un seul module et soyez comme, oui, oui, il n'y a pas de couple ici. C' est un problème qui n'est pas un modèle anti. C' est ce que nous appelons un anti modèle, qui est l'opposé d'un modèle productif. Et le peu briser aussi ce que notre prochain locataire est, qui est la cohésion, parce que cela n'aurait pas un but singulier. Cela aurait essentiellement le but de l'ensemble de la demande. Donc ce n'est pas non plus qu'on va dio. Donc, aucun couplage n'est pas là où nous sommes allés de l'avant. Ce n'est pas une communication. Et nos modules, ils ont besoin de se parler. Ils ont besoin de communiquer d'une manière ou d'une autre. Il doit y avoir un lien entre eux. Donc ça veut dire qu'il nous reste avec ces deux zones de couplage. Et ça va être l'idée du couplage de données et l'idée du couplage de messages. Alors quoi ? Ils ont un couple dans ce qu'on a ? C' est quand deux modules partagent ou passent les mêmes données. Et ce que cela signifie, c'est que nous avons juste des données dans une, et nous les transmettons à une autre donnée ou à un autre module en passant ces données à un autre module . Rappelez-vous, nous parlons de mettre un getter ou un centre bien pour le centre. Qu' est-ce qu'on doit passer ? Nous devons transmettre des données pour définir les informations ici dans ce module. C' est un passage de données. C' est un lien entre les deux. Si on change les données ici, quelque chose va changer ici. Si nous décidons que nous voulons passer un autre type de données à être, eh bien, alors cela va arriver. Il se peut que nous devions changer et accepter ce nouveau type de données. Donc, même si le changement serait faible, que seulement une petite ligne de code là pour changer, il y a encore une petite quantité de liaison. Cependant, nous ne pouvons pas vraiment dépasser cela parce que les modules doivent communiquer. Nous devons pouvoir transmettre des données d'un bout à l'autre. Donc ce couplage n'est pas mauvais. C' est juste une sorte de l'état optimal de couplage à nouveau. Il va y en avoir un peu. C' est parfaitement bien. L' autre idée est le couple de messages, et c'est quand les messages ou les commandes sont transmis entre les modules. Ce que nous entendons par ceci est si peut-être nous avons ceci est notre Isar initial donc nous avons une application, et cette initialisation est l'application. Et puis peut-être que nous avons ici, peut-être que ça démarre les services de fond ou quelque chose comme ça, et ensuite ça appelle et fait le This sera le responsable des notifications. C' est peut-être le gestionnaire de sauvegarde. C' est potentiellement, je ne sais pas, peut-être comme certains dans les calculs. Donc calcul Juste canapé pour court juste là. Et donc vous pouvez voir que c'est en fait une assez bonne installation ici. On ne l'a pas dedans. Il appelle à une commande pour démarrer les choses d'arrière-plan, les choses arrière-plan qui le partitionne très intelligemment à la tâche de calculatrice d'arrière-plan, la tâche de sauvegarde d'arrière-plan, la tâche de notification d'arrière-plan. Et tout ça démarre. Et ils ont passé des ordres sur leurs propos, tu sais, être dit que ça fonctionnerait toutes les 12 heures. Cela fonctionne toutes les trois heures pour arrêter le taux toutes les 14 heures, etcetera, etcetera, leurs commandes étant transmises, leurs messages. Ils disent que tu tu devrais commencer cette tâche. Hé, tu devrais commencer cette tâche. Ils ne vont pas dans la grossière qu'ils ne contrôlent pas, rappelez-vous, c'est la différence. Le couplage de contrôle ne signifie-t-il pas ? Nous passons des drapeaux dans chacun d'entre eux pour changer le contrôle, disions juste ce qui doit être accompli. Donc, dans cette situation, nous le disons, le processus de calcul devrait s'exécuter. Et puis cela figure donnée sur l'ensemble des paramètres dans l'état actuel de l'application, ce que cela signifie et même avec la sauvegarde. Nous ne passons pas de commandes ou pas. Passer les drapeaux était juste le dire, Faites l'opération que vous êtes censé dio et dans la gestion de sauvegarde fera cela juste qu' il va regarder l'état de l'APP et cela fera l'affaire. C' est le travail. Il va sauvegarder l'état de l'APP partout où il doit aller. Et c'est donc ce que le couplage de messages est, et vous pouvez voir quelle est la combinaison de mess, couplage et couplage de données. Nous pouvons créer n'importe quelle application dont nous avons besoin. Nous n'avons besoin d'aucun de ces autres couples pour travailler essentiellement notre application ou notre programme de quelque façon que ce soit, forme ou forme que ce soit. Eh bien, étant donné un peu, il y a des situations où vous allez devoir peut-être le coupler un peu plus . Peut-être que si tu couples ça juste un tout petit gant de plus. Peut-être que vous êtes allé au couplage moyen pour une section de votre application qui pourrait économiser 200 heures de travail. Ou il pourrait être mormon maintenable. Et ces situations vont bien. Mais notre objectif ici, notre idée est que nous voulons nous lâcher le plus possible. Nous voulons réduire le réseau de dépendances au sein de notre application. Et c'est le genre de l'objectif de tout cela sont couplage lâche ici encore. On ne veut pas y aller sans accouplement. Nous voulons cette idée d'accouplement lâche. 26. Conclusion de couplage de 4 à 9: un de ses couplage avec quelques dernières pensées ici. Donc nous sommes tous sur la même page. est important de mesurer le couplage à mesure que nous concevons et développons. C' est ce qu'on a fait tout ce temps. C' est là que tu t'es concentré sur beaucoup. Et ce n'est pas juste de planifier ce dont nous avons besoin pour le planifier. , Ce que je veux dire par là,c'est qu'on peut avoir un plan de 1000 pages vraiment en profondeur. Mais si c'est juste des conceptions vraiment horribles de modules vraiment étroitement couplés, peu importe que nous ayons le plan de celui-ci. Nous l'avons mal conçu. On n'a pas pensé à un couple. Nous n'avons pas pensé à la cohésion. Nous n'avons pas pensé à l'idée de la maintenir et de pouvoir déplacer et changer l' application au fil du temps. Tout ce que nous avons fait, c'est que nous avons mis nos idées sur le papier, pas pensé à une solution plus intelligente, et ensuite nous allons développer ça. Donc, ce n'est pas parce que nous avons un plan que c'est un bon plan. Et c'est ce que l'idée du design est non seulement pour la planète, mais pour en faire un bon plan. Et puis enfin, nous essayons de viser le couplage de couple lâche et d'affaiblir justifier en écrivant quelque chose plus fort. Et donc, comme je le disais dans la précédente, il y a peut-être une situation où vous ne pouvez pas penser à une meilleure solution que de renforcer légèrement comme je le disais dans la précédente,il y a peut-être une situation où vous ne pouvez pas penser à une meilleure solution que de renforcer légèrementle couplage droit, vous savez, le couplage droit, vous savez, rendre les choses un peu plus serrées dans ces situations. Ne vous battez pas sur la tête, essayant de le rendre aussi lâche que possible, essayant d'ajouter, Vous savez, 85 modules supplémentaires pour que vous n'ayez pas à le faire, sorte que vous pouvez le ramener à ce couplage très lâche . Ce n'est pas là qu'on veut aller. Donc, dans ces situations, justifie-le par écrit, juste, tu sais, expliquer à quelqu'un d'autre qui pourrait regarder ça. Pourquoi avons-nous utilisé un couplage plus serré, même si c'est juste, euh, euh, l'autre plan aurait exigé du temps de développement supplémentaire sans nous faire économiser temps de maintenance. Quelque chose comme ça. Écrivez-le et, vous savez, passez à autre chose, passez à la conception. Mais dans l'ensemble, nous essayons de viser ce couplage lâche. C' est notre objectif. C' est comme une cible. Nous essayons de frapper le plus près possible du centre. Si nous sommes ici de temps en temps ou peut-être dehors de temps en temps, c'est parfaitement bien. Mais nous visons le centre. Nous essayons de le rapprocher le plus possible de cet objectif central. Et si nous faisons ça, nous faisons notre travail correctement. Dans la prochaine conférence, nous allons passer en revue l'autre côté de ça, qui est l'idée de cohésion. La cohésion est intéressante, et elle va presque à l'encontre du couplage d'une certaine manière, ce qui nécessitera un peu d'équilibre. Alors, on va sauter là-bas. 27. Introduction de cohésion 4-10: Alors passons à l'autre côté de la pièce, si vous voulez, et parlons de l'autre idée vraiment importante lors de la séparation des choses en modules. Et c'est cette idée de cohésion. Donc, dans les dernières conférences, nous avons parlé de cette idée de couplage où nous ne voulons pas que les modules soient trop étroitement associés les uns aux autres, mais avec la cohésion. Ce que nous voulons, c'est que nous voulons que chaque module soit aussi défini que possible. rencontrer n'effectue qu'une seule tâche. Donc, nous ne voulons pas avoir tout un tas de modules faisant tout un tas de choses, qui signifie que nous ne voulons pas de modules vraiment volumineux ou ce module fait un peu dans cette catégorie. Ce modèle fait un peu dans cette catégorie ici et dans cette catégorie. Et puis, bien sûr, l'autre exemple est juste un très grand, où vous avez juste un seul fichier faisant tout. Nous voulons qu'ils soient très concentrés pour qu'on puisse sortir les choses, et qu'on puisse presque les mélanger et les assortir. Euh, nous avons cette idée de modularité où nous pourrions prendre un module et le remplacer par un autre module et cela fonctionnerait parfaitement. Donc, par exemple, si c'était le module de couleur rouge et que c'était une couleur, peut-être un module vert, nous pourrions retirer le module rouge et coller le vert à sa place, et cela fonctionnerait parfaitement bien en raison de la définition et de la spécificité de ces deux éléments. C' est donc ce que nous recherchons avec la cohésion. Maintenant ces deux-là. Comme je l'ai dit, ils travaillent l'un contre l'autre. Vous pouvez avoir un ensemble vraiment, vraiment fort, vraiment fort, cohésif de modules qui sont très, très étroitement couplés, et vous pouvez avoir un ensemble très, très lâchement couplé de modules qui est très, très faible dans la cohésion. L' exemple que j'aime utiliser pour cela est si nous avons un fichier géant, Si nous avons un seul fichier géant qui fait tout bien, par définition, par définition, nous avons en fait un couplage très lâche. n'y a pas de lien avec d'autres fichiers ici. Ce module est lâchement couple qui n'a pas de liens. Nous pourrions dire que ce n'est pas un couplage dans cette situation, donc ce serait bien et le couplage. Mais avec cela, nous avons la cohésion la plus faible de toute. Donc, ce que nous avons ici, c'est un fichier qui fait tout et qui n'a donc aucun but. Il n'a aucun facteur déterminant de ce qu'il est censé dio. Et donc à cause de cela, au lieu de chercher l'un ou l'autre, nous devons essayer de faire rencontrer les deux. Nous devons trouver un équilibre. Et c'est là que nous allons avec ce principe de cohésion forte et de couplage lâche. Nous ne serons pas en mesure d'être parfaits de chaque côté, mais ce que nous cherchons s'ils étaient tous les deux comme des graphiques comme, euh comme ça ici, nous cherchons à essayer toe mah, maximiser au centre ici. Nous cherchons à optimiser notre programme afin qu'il soit assez bien et lâchement couplé et en même temps, assez cohésif. Si nous pouvons le faire, nous avons un excellent programme. Nous avons un excellent design et cela rendra le processus de maintenance et de construction beaucoup plus facile. Alors les prochaines conférences, commençons à entrer dans certains des différents niveaux de cohésion comme nous l'avons fait avec le couplage et voyons quelques-uns des pièges communs et des choses qui viennent avec la construction en ce qui concerne couplage 28. Cohesion faible 4-11: Commençons donc notre première catégorie avec une faible cohésion. cohésion est donc la pire forme de cohésion incitée. Cela signifie que nous n'avons pas beaucoup de cohésion. Et rappelez-vous, nous voulons une forte cohésion et un couplage lâche. Donc, avec une faible cohésion, ce que nous avons, c'est que nous avons ces modules qui sont construits, mais ils n'ont pas vraiment de but. Cela crée cette idée de mot code spaghetti, ce qui signifie qu'il pourrait y avoir peut-être 1000 modules différents dans un fichier. Mais aucun d'entre eux n'a de but, et aucun n'est lié entre eux de quelque manière que ce soit. Par conséquent, toute autre personne essayant de rejoindre le projet n'aurait aucune idée de comment tout fonctionne. y aurait pas d'ensemble ou de ligne directrice, rien qu'ils pourraient suivre pour le comprendre. Ils auraient juste à jouer avec ça jusqu'à ce qu'ils l'apprennent. Et cela ralentit vraiment la production parce que vous ne pouvez pas embaucher d'autres personnes sans tout ce temps nécessaire pour les mettre au point. Donc, avec une faible cohésion, nous avons quelques catégories pour commencer. Le 1er 1 est son idée de cohésion coïncidente, donc la cohésion coïncidente signifie que la seule raison pour laquelle ces idées, activités et choses sont réunies dans ce module est juste parce qu'elles sont dans le même dossier, coïncidence ensemble. Donc nous avons un dossier, et nous avons juste mis un tas de trucs aléatoires différents dedans. Donc, par coïncidence, ils ont cette association. Ils sont ensemble parce que nous disons qu'ils sont ensemble et vous savez qu'un exemple de ça pourrait être propre le siège auto Restaurant droit Livre Rapport de vol de Dallas, Texas. n'y a pas de combinaison logique de ces choses. n'y a rien de concentré là-dessus. C' est juste un tas de tâches aléatoires ici, et c'est en fait cela pourrait être un pas plus loin que par hasard. Juste parce que ce sont toutes des activités, nous pourrions même avoir quelque chose comme où nous avons mis E ici. Et c'est juste quelque chose comme un nom comme un chien. Et maintenant, vous. Maintenant, ce ne sont même pas toutes les activités. Maintenant, ils sont encore plus aléatoires. Et donc quand tu arrives à ce point de juste hasard, ça te fait tomber trop par hasard. Et comme je l'ai dit, il est impossible de démystifier quelque chose comme ça parce que vous aurez, genre, un tas de fichiers du tout. Faites ceci et puis ils sont tous liés aléatoirement, les autres fichiers et cela n'a aucun sens le flux du programme. Certains exemples de ceci sont comme un programme de fichier unique. Donc, comme nous parlons de ce fichier unique géant sur l'ensemble du programme fonctionne à partir de ce fichier peut-être Java script ou Java fichier ou quelque chose comme ça. C' est une coïncidence de cohésion. n'y a rien qui relie ça ensemble, sauf qu'ils font tous partie du même programme, et qu'ils sont tous dans le même fichier, le contrôleur de non-correspondance aussi. Donc, si nous avons, par exemple, comme un contrôleur de vue modèle, nous avons une classe de contrôleur dans laquelle nous essayons, vous savez, vous savez,de tout transmettre. Nous avons ces idées et nous essayons de créer un meilleur code. Mais si nous ne lui donnons pas vraiment un but, et que nous mettons tout dans cette classe de contrôleur, cela devient aussi une cohésion fortuite. Et peut-être le petit peu sur la logique s'ils sont tous contrôleurs, s'ils sont tous réellement faire des activités. Mais généralement, il y a quelque chose en eux qu'il ne le fait pas et ça tombe en quelque sorte dans cette catégorie, et puis, comme je l'ai dit, code spaghetti où nous avions juste tous ces modules qui n'ont absolument aucun but parler les uns aux autres. C' est donc une coïncidence. Cohésion juste déposer. Mais plus de l'a, c'est qu'il est dans le même fichier. La suivante est cette idée de cohésion temporelle, et cela signifie que cela a été lié ensemble parce que les événements se produisent autour du même temps. Et donc si nous allions à un exemple du monde réel ici, ce serait comme des dents brossées. Prenez une douche, mangez le petit déjeuner. Réveillez-vous. Qu' est-ce que c'est ? Est-ce qu'il y a un matin ton ado ? Donc ils ont tous été au début de notre matinée, donc ils sont en quelque sorte qu'il y a un lien entre eux. Ils sont meilleurs que ça ici. Mais encore une fois, ce n'est pas très utile car il y a encore des activités qui sont partout. Ici, nous avons quelque chose qui arrive à ce qui se passe. La salle de bain. Un dans la cuisine. Celui-ci est dans la chambre. Certains d' entre eux consomment des objets, d'autres en utilisent d'autres. Certains d'entre eux sont en train de nettoyer. Certains d'entre eux sont un changement d'état d'acte. Donc on va du sommeil au réveil. Ils sont tous complètement différents dans leur là-bas. Quantité de contrôle, leur quantité de changer les choses autour d'eux et si vous pensez dans le programme, vous pouvez voir que c'est bien comme Imaginez si quelque chose se passait sur le front et c'est et peut-être comme, la base de données ici. Ceci est purement sur le dos peut être sur les serveurs d'encaissement. Certains d'entre eux changent de front invariable, quelqu'un changeant de retour invariable. Certains sont saisies de la base de données. Ils sont partout, même s'ils se reproduisent relativement au même moment, ce n'est pas très cohésif. Et un exemple de ceci est comme un programme, comme arrêter des activités ou faire, euh, peut-être démarrer une activité. genre de choses, c'est ce genre de choses qui s'activent à un certain moment à la même époque, et c'est la cohésion temporelle. La suivante est la cohésion logique. Nous sommes donc en quelque sorte un peu mieux avec la cohésion logique et, en ce sens, ses activités qui sont liées dans la même catégorie générale. Donc, ce que nous avons c'est que nous avons en voiture pour Dallas, voler pour Dallas, prendre le train pour Dallas et prendre le bateau pour Dallas. Donc ce sont toutes des activités dans lesquelles nous allons à Dallas. Mais le problème ici, c'est qu'ils sont tous utilisés à différents endroits et voir ce que je veux dire par là, c'est que nous ne pourrions pas avoir un programme écrit. Disons que ceci ici, ce regroupement est dans ce contrôleur juste ici. Nous pourrions avoir un tas de modules différents appelant un off de ce contrôleur un à fois, un à la fois, un à la fois. Et le problème avec ça, c'est qu'ils sont tous forcés de changer leur interface pour qu' ils correspondent aux autres. exemple, Par exemple, si on prend un train, on pourrait avoir besoin d'un billet. Cependant, on prend un bateau. Peut-être qu'on n'a pas besoin d'un billet, mais on doit quand même passer une variable vide disant qu'il n'y a pas de billet pour le train , mais on utilise un bateau. Et donc nous avons ce genre d'interface verrouillée qui ne nous permet pas de communiquer clairement avec cela, et souvent, nous pourrions ne jamais utiliser Fly to Dallas, par exemple. Et maintenant, nous avons cette méthode qui n'est pas vraiment utilisée, mais c'est avec d'autres méthodes qui sont fréquemment utilisées, et donc cela devient dans un problème où nous ne pouvons pas nous ne pouvons pas éditer, il devient difficile de suivre certaines choses, et ce n'est tout simplement pas un fichier très utile dans l'ensemble et quelque chose Ah, qui pourrait être un exemple du monde réel de cela serait quelque chose comme un contrôleur de sauvegarde qui a tout un tas de zones différentes qu'il devrait sauvegarder. Alors peut-être que l'un d'eux est dans le nuage. L' un d'eux est d'aimer une sauvegarde, un disque dur ou quelque chose comme ça. d' L' und'eux est une sauvegarde locale, etcetera, etcetera. Nous avons toutes ces différentes sauvegardes ici, et nous les appelons simplement une à la fois et devons fournir ces différentes interfaces pour chacun de ces appels. Donc, au lieu de ça, on pourrait essayer, tu sais, rompre plus tard, et c'est de ça que nous parlerons un peu plus tard. Mais ce sont là quelques exemples de cohésion très faible, choses qui ne sont tout simplement pas très bien organisées et qui ne sont en quelque sorte qu'ensemble avec une très petite quantité de pensée, soit leur coïncidence ensemble. Donc ils sont juste ensemble à cause du fait qu'ils sont ensemble, que temporairement, donc on aime les mettre en même temps, ou logiquement donc il les a mis dans la même catégorie générale. Mais encore une fois, il y a une très bonne spécialisation ici, donc c'est une lésion faible. Ensuite, nous allons parler de la cohésion moyenne, qui est une sorte de domaine que nous voulons viser, et nous avons. On passera à partir de là. 29. Cohesion moyen 4-12: Notre prochain niveau de cohésion est celui de la cohésion moyenne. cohésion moyenne est donc la prochaine étape vers une forte cohésion. Avec une cohésion moyenne. Nous commençons à avoir une petite idée de ce que font nos modules. Ils font des tâches bien ciblées. Cependant, ils atteignent encore un peu trop loin dans un tas de directions différentes. Et commençons par la cohésion procédurale ici pour ramener un peu ce point à la maison . Donc une cohésion procédurale. Ce que nous avons, c'est où l'ordre d'exécution passe d'une commande à l'autre. Cela signifie que nous avons cet ensemble de commandes ici. Nous en appelons un qui va à l'autre. Celle-ci va la date suivante et la suivante dans la suivante jusqu'à ce que la tâche soit terminée. Maintenant, le problème de la cohésion procédurale est que ces tâches n'ont pas à être dans le même domaine . Ils ont juste à accomplir la même activité globale. Et cette activité primordiale est de nettoyer la voiture. Donc, dans cette situation, ce que nous avons est que nous avons d'abord pulvériser la voiture avec de l'eau, Ensuite, nous remplissons un formulaire. Peut-être que c'est une forme d'affaires ou peut-être qu'on accepte de l'argent ou quelque chose comme ça. Et puis on frotte l'assurance automobile et on sèche la voiture. Comme vous le voyez, la tâche de nettoyage de la voiture a été terminée. C' est fait maintenant, cependant, nous avons ce problème là où nous faisons. On va trop loin. Donc, ce module, au lieu de simplement faire des activités liées à la voiture, il fait aussi des activités financières potentielles et peut-être des activités administratives, peut-être des activités organisationnelles avec des bases de données. Il va dans d'autres domaines où il ne devrait pas entrer. Donc, si nous regardons cela, si nous regardons ce module de voiture propre, nous ne nous attendons pas à ce que la carte blanche soit en train de manipuler les données financières. C' est un grand non non, c'est une grosse chose à laquelle on ressemble plus. Eh bien, pourquoi ça touche financier ? Que ça ne devrait pas faire ça. Cela devrait être, Ah, certain nombre de personnes et de commandements qui font ça pour ne pas rencontrer de problèmes avec la loi ou notre propre comptabilité qui va mal. Ce serait donc un très gros problème s'il le faisait. Et donc ce que nous ne voulons pas, c'est d'avoir ce module où nous le regardons. Nous ne savons pas qu'il fait ces tâches très importantes juste en le regardant. Donc, dans cette situation particulière, nous avons cette légère cohésion où elle accomplit une seule tâche. Cependant, il atteint beaucoup trop loin et faire un tas de directions différentes. Un exemple de cela serait la mise à jour de toutes les bases de données et journaux. Donc, vous voyez que nous ne mettons pas seulement à jour toutes les bases de données, ce qui signifie que nous pourrions être en train de mettre à jour vous demander bien et mon SQL et peut-être peut-être Mongo. Et puis nous mettons à jour tous les journaux, qui pourraient être vraiment n'importe quel ensemble de fichiers texte, etc., tout en une seule commande. Donc, il accomplit une tâche, mais nous sommes en train d'atteindre un tas de domaines différents ici. La prochaine est la communication sur la cohésion, et c'est là que toutes les activités prennent en charge les mêmes données d'entrée ou de sortie. Donc, dans cette situation, nous avons fondamentalement le genre de colle à ce module est l'article que nous avons article, article, article, article. Donc, nous trouvons l'auteur, nous trouvons la date, nous trouvons le long de leur article, Um et puis nous définissons le contenu de l'article. Donc tous ces sont liés à l'article. Cependant, ils font tout un tas d'opérations différentes sur leur genre de toucher ce même ensemble de données au lieu d'avoir les Gators et les centres peuvent être dans différents modules ou, euh, ou le diviser en un peu un peu plus compréhensible. Donc, dans cette semaine et les deux manipuler fin lecture, données, affaiblir, sorte de changements autour, nous pouvons réellement obtenir les conditions de course si pour essayer de définir en même temps. Il y a juste un peu loin, et maintenant on commence. Une fois que nous sommes arrivés à ce niveau, en passant, nous commençons à arriver au point où cela est assez courant dans les programmes. Il y a beaucoup de fois que nous allons avoir une pile, et cette pile va contenir toutes les opérations pour la pile. Cependant, nous devons également noter que cela pourrait être un peu meilleur. On pourrait en quelque sorte briser ça encore plus et en faire tous des modules très, très ciblés. Et aussi, je fais juste une note ici, c'est que nous n'avons pas besoin d'en avoir un seul. Un programme pourrait permettre la communication et la cohésion procédurale. Dans le même temps, il pourrait avoir la communication, Elin, temporel ou toutes ces autres couches de cohésion en même temps. Donc, ce que nous essayons d'obtenir, nous essayons juste d'obtenir le plus haut niveau de cohésion et éliminer toutes les petites parties mauvaises de la cohésion. Donc, même si nous avons le plus haut niveau d'accord, la cohésion, cela ne signifie pas que nous avons une activité qui s'écarte de la cohésion globale et qui rompt en fait . Quoi qu'il en soit, c'est une communication lorsque toutes les activités prennent en charge les mêmes données d'entrée ou de sortie. Mais c'est à ce sujet que nous parlions juste d'un article ici, mais nous pourrions vraiment faire n'importe quoi avec cet article que nous pourrions avoir dit que nous pourrions utiliser. Peut-être qu'il y a un commandement ici pour l'envoyer quelque part. Il suffit de le stocker dans la base de données. Teoh, faites un achat avec l'article à nouveau, nous touchons les données financières, ce qui est, ah, un problème pour définir le contenu pour trouver le contenu. On fait tout avec l'article. C' est la même entrée, pas les données, mais nous avons beaucoup d'opérations différentes ici. Puis, enfin, ce que nous avons est la collusion séquentielle, qui est souvent confondue avec la cohésion procédurale, avec la cohésion séquentielle. C' est lorsque toutes les activités fonctionnent dans lesquelles les données en sortie pour l'une sont les données en entrée pour la suivante. C' est donc une sorte de combinaison de procédure et de communication. Tout ce que nous avons cette idée de ce morceau de données partagé, l'article dans cette situation ou la voiture dans cette situation et la nature de la procédure où nous allons, un à l'autre le suivant. Donc, dans cette situation, nous ponçons la voiture, en appliquant l' apprêt, pulvérisant la couche principale et en pulvérisant la couche transparente. Alors, on le fait ? On repeint une voiture ou on peint une voiture. Donc, dans cette situation, on pourrait mettre une voiture de peinture, et on sait que la seule chose qui se passe ici, c'est qu'on peint une voiture. Il n'atteint nulle part ailleurs, sauf le domaine d'une voiture et de la peinture appliquée à la voiture. Donc, nous n'avons pas l'argent que nous n'avons pas les données administratives. Nous n'avons pas les données de base de données, tout ce que nous faisons et je vais le répéter encore une fois, c'est peindre une voiture, et c'est pourquoi nous commençons à entrer dans une très bonne cohésion ici, c'est une très bien définie, Ah, une sorte de zone. Eh bien, module défini, et c'est aussi procédural. Donc nous savons qu'une opération se poursuivra dans la semaine prochaine avec la prochaine réunion dont nous allons nous occuper. Chacun de ces points va être touché, donc il n'y aura pas comme une partie qui est abandonnée ou une partie qui est appelée d' ailleurs là-bas. C' est un module très défini sur L'ensemble du module est utilisé, et dans cette situation, il pourrait être de mettre à jour un roso de base de données spécifique à cet endroit. Je viens de mettre la ligne de base de données, mais nous pourrions vouloir être plus précis ici. Donc peut-être un mon sur lui là quand vous n'y êtes pas. Mon s Q l donc mettre à jour mon rôle de base de données SQL . Donc, comme nous l'avons noté, ici, nous mettons à jour tout. Nous terminons cette tâche géante qui concerne tous ces domaines. Mais ici, nous faisons quelque chose de très spécifique. Nous mettons à jour une seule ligne d'une base de données SQL utilisant une seule technologie. Nous travaillons avec une seule fonction de mise à jour et c'est tout. Nous ne sommes pas le leader étaient pas nous n'ajoutons pas une nouvelle ligne étaient juste mise à jour. Nous utilisons uniquement mon SQL. Nous mettons à jour la base de données ah et ça va être une ligne pour que vous puissiez voir très spécifique. Il y a peut-être quelques étapes à cette procédure, mais dans l'ensemble, elle sera très, très concentrée. Et donc, comme vous pouvez le voir, nous nous sommes un peu améliorés. Dans le prochain article ou dans la prochaine conférence, la cohésion devait parler d'une sorte de cohésion forte , et c'est là que nous entrons dans ce que nous essayons de viser avec notre cohésion. Et ça arrive un peu dans Rome irréaliste où c'est un peu plus difficile d'arriver cette région, et peut-être que beaucoup de gens reviennent dans ces zones et encore, comme je l'ai dit, c'est assez bien. Mais nous voulons viser cela. Nous ne comprenons pas ce que nous visons pour que nous puissions réellement y arriver et essayer d'obtenir le meilleur logiciel possible. 30. Cohésion forte de 4-13: notre dernier niveau de cohésion sera donc celui d'une forte cohésion. Donc une forte cohésion. Nous avons à sorte de catégories avec nous et ces air les deux catégories les plus élevées. L' un d'eux n'est pas meilleur que l'autre. Il essayait juste d'obtenir ces deux dans un module. Donc, ce dont nous parlons est la cohésion globale de l'objet et la cohésion fonctionnelle, la cohésion des fonctions, parle des fonctions au sein d'un objet. Ou si nous ne parlons pas de langages orientés objet, quelque chose comme original juste C, pas C plus, plus juste C original alors nous n'avons pas d'objets avec lesquels travailler. Par conséquent, nous ne pouvons pas obtenir la cohésion des objets, donc nous allons seulement avec la cohésion fonctionnelle. Donc avec ces deux-là, vous remarquerez qu'ils sont très spécifiques. Il nous permet de ne pas sur Lee de regarder un module et de savoir instantanément ce qu'il fait. Cela nous permet également d'échanger ce module. Donc, par exemple, dans le côté gauche ici, avec la cohésion fonctionnelle, nous avons ces zones vraiment, vraiment définies ici, et c'est l'un des modules supporte les activités nécessaires pour un et un sur Lee. Une tâche liée à un problème. Et donc nous avons ce paiement mensuel déterminer ici. Et le fait est, c'est qu'avec une bonne cohésion, on pourrait en fait sortir ça. On pourrait prendre ça. Nous dirons que c'est le paiement mensuel et nous pourrions peut-être déposer un nouveau module de paiement hebdomadaire et ce sera si simple parce qu'il est mis en place d'une manière où tout ce qu'il prend est les données d'entrée appropriées. Et il est sorti de mettre les bonnes données de sortie. Par conséquent, si nous mettons dans un module qui est similaire à lui, Mais avec certaines choses changées, cela va changer l'ensemble du programme vraiment, vraiment rapide et nous permet de mélanger et de faire correspondre notre programme et de personnaliser un peu de cette façon. Donc, avec la cohésion fonctionnelle, tout ce que nous essayons de faire est d'obtenir ces modules qui sont très, très spécifiques dans leurs tâches, et les fonctions dans le module devraient faire de même. Donc, nous n'avons pas besoin d'une fonction dans le module qui fait tout ce que vous savez, comme dans une sorte de ah, beaucoup de fois auront comme dans une fonction tricot, et nous ne voulons pas que cela dans la fonction pour juste faire littéralement tout dans le module . Nous voulons d'autres fonctions là-dedans. Nous voulons le briser de sorte que même si l'unité fonctionne, même si elle va aller dans un ordre séquentiel et qu'elle va appeler tout le module, ce n'est module, pas seulement un regroupement géant de code. Nous avons ces appels de fonction fondamentalement qui vont à une autre section de code et est-ce que la fonction va savoir que la section fait la fonction, vous savez, section fait la fonction et donc nous avons cette cohésion fonctionnelle dans le également. Et chaque fois que nous construisons des modules comme celui-ci, nous arrivons à l'objectif. Nous sommes enfin en train d'arriver à ce point où notre programme devient plus facile à digérer et il devient facile à maintenir. Et donc juste un autre exemple qui est si, par exemple, nous avons dit de calculer l'interception hors graphique. Donc vous savez, nous n'avons que deux graphiques, et tout ce que nous faisons c'est que nous lui donnons ces deux graphiques d'information. Donc nous disons que nous avons ce métier dans ce graphique, nous lui donnons les points, et ensuite cela nous donne juste le point où ils interceptent. C' est une chose très, très spécifique. Tout ce dont il a besoin est de graphiques en tant que données d'entrée, et il fera tous les calculs à l'intérieur, puis juste sortir l'ex exact et pourquoi arriver à ce point. Donc, encore une fois, vous pouvez voir comment c'est très, très rétréci dans, et l'autre est la cohésion de l'objet. Donc, c'est quand toutes les activités sur Lee modifient un seul objet. Et ce que nous entendons par ceci, c'est, disons que nous avons soit comme un paiement hypothécaire, soit nous irons avec ça le 2ème 1 ici , l'objet de l'utilisateur. Alors quoi ? L' objet utilisateur, nous avons essentiellement l'objet lui-même. Donc, c'est l'utilisateur et puis en haut ici, ce que nous avons est un tas d'attributs de peut-être l'adresse e-mail du nom. Combien de fois ils se sont connectés aux points actuels. Si c'est comme un système de jeu, comme dans les fonctions ici sont seulement manipuler ces données, ces morceaux de données. Donc vous savez, vous pourriez avoir quelque chose comme de nouveaux utilisateurs. Donc c'est, vous savez, nouvel utilisateur, et donc un nouvel an ou va initialiser toutes les données, et alors peut-être que nous avons des getters et des centres. Donc, si vous pouvez lire que getters et centres, ce qui signifie qu'ils sont juste quelque chose de spécifique pour obtenir ou définir chacun de ces attributs. Et puis vous pourriez avoir quelque chose comme, euh, peut-être que si vous faites un certain objectif, ça ajoute un point à l'une de ces catégories. Donc, comme, par exemple, on pourrait faire comme, ah, se connecter, hum, sorte de fonction ici et ce que ça va faire, ça ne va pas tendre la main à n' importe où ailleurs. Il s'agit juste de mettre à jour les attributs de l'utilisateur. Donc si on se connecte, on va juste avoir un point dans cette zone ou quelque chose comme ça. Et donc dans l'ensemble, vous pouvez voir que c'est très, très en quelque sorte localisé. L' utilisateur a des attributs, et ses fonctions ne font que des choses très spécifiques et sur Lee mettre à jour les attributs dans l' objet que la vie nous obtient cette cohésion de l'objet. Donc une cohésion fonctionnelle, un objet. Nous avons un problème qui est maintenant défini vraiment, vraiment bien et d'une certaine manière, sorte qu'il est très facile de mélanger et de faire correspondre. Et il n'y a pas beaucoup de code spaghetti de toutes ces choses qui atteignent partout ailleurs. Nous avons juste des entrées simples d'une classe de contrôleur ici disant à l'utilisateur, vous savez quoi ? Il devrait mettre à jour vous savez qu'un utilisateur connecté utilisateur déconnecté a obtenu 50 points supplémentaires aujourd'hui , et puis il va juste mettre à jour toutes ces choses ici, et il n'a même pas besoin de renvoyer des choses, parce que si nous avons besoin de voir, nous allons juste attraper l'objet utilisateur et regarder les données avec un getter à partir de là. Mais nous essayons de créer ce très petit flux de contrôle ici tout au long de notre projet . Restez simple, gardez-le défini. Et nous avons nous-mêmes une forte cohésion. Maintenant, sur un côté, vous remarquerez comme si je parlais. Si nous avons un couplage très fort, beaucoup de fois auront une faible cohésion et la même chose peut être liée ici est si nous commençons, vous savez, prendre un problème et à le décomposer en chaque fonction, par exemple, est un module. Nous pourrions avoir une cohésion très élevée, une très bonne cohésion fonctionnelle. Chacun d'entre eux a un problème de projet très spécifique. Cependant, vous remarquerez également que maintenant ces choses doivent se parler. Donc maintenant on va commencer à avoir cette zone où ils commencent en fait à un lien. Même si le flux de contrôle est petit, ce qui signifie que nous n'avons pas 1000 flèches allant dans chaque direction. Nous avons encore ce genre de zones qui sont juste liées entre elles, un peu plus serrées que vous pourriez le souhaiter. Et donc, dans cette situation, chaque fois que nous arrivons à une cohésion vraiment, vraiment forte , nous pouvons souvent perdre notre couplage et notre couplage devient aussi plus fort. Et encore une fois, on ne veut pas ça. Donc, nous essayons de trouver cet équilibre entre les deux essayaient de trouver une bonne idée de résolution de problèmes ici afin que nous ayons tous les deux une forte cohésion et un couple faible . 31. 4-14 Importance de conception: Je veux ramener ce point à la maison sur l'importance du design. Beaucoup de gens aiment simplement sauter dans le code et commencer à travailler dessus. Et je dis, tu sais, je vais le concevoir comme je vais. Le problème avec cela est que la conception devient de plus en plus difficile avec le code MAWR. Vous avez raison ? Donc, sur la gauche ici, nous avons une sorte d'exemple simple ici. Ce n'est même pas beaucoup de choses qui se passent, mais ce que nous avons, c'est cinq modules avec peut-être 3 à 5 fonctions dans chaque module. Cependant, il y a cette division très forte entre la signification que chaque fonction ici fait un peu d'une seule tâche. Donc, si nous revenons à quelque chose comme calculer le paiement hypothécaire ou, vous savez, trouver ou trier dans une feuille de calcul Excel ou quelque chose comme ça, nous avons ce genre, cette seule fonction de calculer le paiement hypothécaire un peu mordez ici. Ensuite, il va par ici et il calcule quelque chose se déplace ici, et peut-être qu'il y a une valeur de retour de ce côté qui revient par ici, et ensuite que l'on l'envoie ici et puis, vous savez, peut-être un Salut. Peut-être qu'il va tout le chemin et salut incomplet. Et maintenant, on a fini. Mais vous verrez que tout est étalé ici. Nous avons de multiples activités différentes qui se déroulent dans ce domaine. Peut-être comme je l'ai fait parce que son paiement hypothécaire, Peut-être que c'est comme un document fiscal ou quelque chose, et ou un programme fiscal documents. Donc peut-être pas un document, mais programme. C' était donc un programme fiscal. Et donc nous avons, ah, un tas de tâches différentes qui doivent être accomplies. Cependant, vous pouvez voir qu'il y a juste cette cascade de tout ce qui se passe. Imaginez s'il y avait un air qui se passait ici. Où devrions-nous le tracer ? Nous devrions vérifier non seulement cette fonction. Nous devons vérifier cette fonction. Nous devons vérifier cette fonction avec vérification ici. Là-bas dans tout ce module. Imaginez qu'il est 1000 d'entre eux, Cela prend un certain temps. Maintenant, si on avait planifié à l'avance comment tout ça allait fonctionner, alors on peut en quelque sorte obtenir ce côté ici. Et comme on dit avec l'orange, peut-être que c'est ton hypothèque. Peut-être que le vert ici est un truc à voir avec vos revenus. Peut-être que le violet est un truc à voir avec vos affaires. Et le bleu est peut-être quelque chose à voir avec, genre, genre, les enfants de dépendance. Et donc vous pouvez voir maintenant nous avons une très bonne scission. Il y a un peu de communication entre les modules. Nous avons cet endroit très facile où nous sommes comme, Ok, revenus sont terminés dans cette section du programme. Le côté des affaires est fini dans cette section. Le côté de l'hypothèque est là-haut. Le côté enfant est par ici. Et imaginez que si on créait un nouveau, peut-être que la manette voulait créer, genre, un front end ici. Trouvons une nouvelle couleur ici. Peut-être voulu contrôler créer un front end qui va se distribuer lui-même. Donc ça va aller au revenu. Ça va aller au business. Ça va aller à l'hypothèque, et ça ira à l'enfant. Et maintenant, tout ce que nous avons à faire est simplement de créer un lien unique dans toutes ces sections. Prenez toutes ces données là-bas, et ensuite nous avons ce front end. Imaginez essayer de faire ça ici. À quel point pensez-vous qu'il serait difficile d'essayer de faire fonctionner tous ces orteils correctement pour trouver le bon dans les points, envoyer les données correctes ici et ensuite de faire des calculs et d'autres choses ? C' est tellement plus difficile. Et c'est tout. J' essaye avec cette toile géante de couleurs et d'autres choses ici. C' est tout ce que j'essaye de mettre là-bas, c'est que le temps passé dans la conception va vous faire gagner beaucoup de temps plus tard, parce qu'à un moment donné, cela devient tellement, Emmanuel qu'il faut abandonner tout le projet ou nous devons le reconstruire pour le faire fonctionner fondamentalement comme ça. Donc, si vous planifiez à l'avance, vous pouvez sortir ça du chemin. Vous pourriez avoir au moins, ah, un bon plan sur la façon dont se passera le flux général des choses, et cela vous fera gagner tant de temps à l'avenir. 32. Les bases de la mise en œuvre en 5-1: notre prochaine unité après celle de la conception sera la mise en œuvre. Et cela est typique dans le cycle de vie du logiciel aussi est, une fois que nous devons concevoir, nous pouvons commencer à travailler sur l'implémentation ou le codage de la chose. Donc, nous parlons d'implémentation maintenant, cette unité entière ne sera pas aussi profonde que les autres car l'implémentation est très spécifique à la technologie que vous utilisez. Donc, si vous créez une application en ligne, ce sera très différent de si vous créez une application mobile ou très différent de si vous créez une application serveur qui parle les institutions financières et n'interagit jamais avec le utilisateur frontal. Il y a 1000 façons différentes que vous pouvez implémenter quelque chose. Et donc, comme je l'ai dit, qu'il n'y a pas beaucoup de choses dont nous pouvons parler ici qui ne seraient pas vraiment spécifiques à un certain type de problèmes. Ce que nous allons examiner, ce ne sont que quelques-uns des principaux locataires, puis beaucoup sur le déploiement et ce genre de zone, parce que le déploiement est une sorte de domaine théorique et il y a des domaines que vous pouvez faire là-dedans . Certaines choses que vous pouvez apprendre là-bas. Alors passons en revue certains des locataires de la programmation. L' une des principales choses que vous devriez faire, ou que l'entreprise devrait faire est de prendre soin des programmeurs. C' est très important parce que la mise en œuvre de l'endroit où la plupart du temps sera consacré. Et si elle est mal implémentée, alors c'est là que fondamentalement, la plupart du temps pourrait être perdu si vous avez le document de conception le plus étonnant au monde et que vos programmeurs ne le conçoivent pas comme le document, eh bien, peu importe que vous ayez passé tout ce temps à la conception, car maintenant vous avez un produit tout aussi inférieur que si vous ne l'aviez pas consacré à la conception. Et donc ce dont vous avez besoin, c'est que vos programmeurs soient alertes et concentrés. Vous devez les avoir concentrés sur la tâche à accomplir et penser aux meilleures solutions à mesure qu' elles vont de l'avant. Parce que même si notre conception peut être assez en profondeur, nous n'avons pas encore une partie du minutieux conçu, et il y a encore des choix qui pourraient être faits à l'intérieur de cela. Il y a encore de très mauvais choix qui pourraient être faits, et ce que nous obtenons, c'est ce qu'on appelle la dette technique qui ne cesse de revenir. Donc, si nous commençons à accumuler de plus en plus de dettes techniques, il faudra plus de temps plus tard pour la réparer. Donc si on a économisé 10 heures maintenant, ça pourrait prendre 100 heures plus tard pour réparer ça. 10 heures qu'on a sauvées. Et pour qu'on puisse y penser comme ça. 35 heures de programmation par semaine, semaines de travail difficiles, comme 40 heures avec 35 heures de programmation vraiment ciblée, pourraient être aussi productives que 70 heures. Donc, si vous avez vos ouvriers, vous savez, travailler jusqu'à 8 heures du soir tous les soirs, vous savez, vraiment essayer de sortir quelque chose. C' est probablement vous pourriez être capable de repousser la date où, au lieu de sortir ici, il sort, vous savez, quelques jours plus tôt. Cependant, la quantité de problèmes et la quantité de correctifs que vous allez devoir faire pour l'obtenir à cet état optimal va coûter beaucoup plus de temps plus tard pour corriger cela. Donc, en gardant cela à l'esprit, c'est que juste parce que tu as eu plus d'heures, ça n'arrive pas. Mork Orrico productif est très important et la programmation prend l'accent. Des interruptions constantes réduiront l'attention globale. Donc, si vous êtes dans une entreprise et que votre entreprise appelle constamment des réunions, peut-être que c'est quelque chose qui doit être soulevé. Peut-être que la production globale pourrait être plus rapide si vous n'allez pas aux réunions tout le temps. Si vous avez le droit d'avoir, vous savez, peut-être un bloc de quatre heures au début, pour vraiment vous asseoir et vous concentrer sur le codage. Et si vous êtes un travailleur indépendant ou si vous travaillez pour des siestes en euros, alors vous devez vous concentrer. Vous devez vous assurer de savoir que vous ne vous détournez pas vers les médias sociaux ou regarder des vidéos YouTube que vous restez très concentré sur la tâche à accomplir. Et il y a des principes d'encodage là juste une sorte de, ah, ensemble de principes que vous devriez garder à l'esprit tout en permettant. Et c'est utiliser un guide de style. Donc, tout le code semble relativement le même. Ceci est très important si vous avez plusieurs personnes différentes travaillant sur le même projet. Imaginez quelque chose comme Microsoft lorsqu'ils travaillent sur les systèmes d'exploitation. Imaginez si chaque programmeur met son propre petit tour de style sur des choses que vous auriez code que chaque fichier est différent et donc difficile à comprendre. Et cela peut se résumer à simple, comme si nous disions, une fonction soviétique comme fonction. Que sauf un paramètre a Mettons-nous l'accolade sur la même ligne et ensuite l'étreinte ici, Ou sommes-nous toujours en retrait et mettre l'orthèse bouclée comme ça ? Il y a 1000 ces petites décisions, et un guide de style aidera à s'assurer que le code ressemble tous au même. Par conséquent, il est plus facile de lire et plus facile de mettre les gens au courant. Le code est écrit pour les personnes, pas pour les ordinateurs. C' est quelque chose de très dur que quelque chose de très important comprennent, et beaucoup de programmeurs informatiques ne comprennent pas ce concept. Ils essaient. Ça va en quelque sorte avec celle-là aussi. Le code court n'est pas égal au code de pâte. Beaucoup de gens le considèrent comme une sorte de fierté. S' ils peuvent écrire une fonction qui aurait pu être sept lignes de code et ensuite ils essaient écrire dans quelque chose comme trois lignes de code, ils essaient d'utiliser une fonction vraiment complexe, vous savez, vous savez,de A de B fois six x trois d'entre vous le savez, multiplié par neuf. Tu sais, des trucs comme ça, où ça se passe et encore. C' est une fonction de ligne unique où ils auraient pu en fait divisée en une expression vraiment agréable et lisible que quelqu'un pourrait sauter et être comme, OK, donc nous prenons cette fonction que nous ajoutons gratuitement et lisible que quelqu'un pourrait sauter et être comme, OK, c'est que nous divisons le montant des impôts qu'ils doivent payer et que nous le multiplions par le revenu brut , quelque chose comme ça. Et donc ils pourraient être comme, OK, cette fonction fait ça. Où avec celui-ci, ils sont comme, je ne suis pas tout à fait sûr de ce que cela fait, et il n'y a pas de commentaires pour vous dire ce qu'il fait. Alors cette fonction est fondamentalement un mystère. C' est une boîte noire que ce programmeur n'aura pas à jeter des données à travers Gary qui met une entrée et ensuite mettre des données de sortie pour comprendre ce qui se passe . Et pourquoi cette mise en œuvre était-elle ? Quel est le but de l'implémenter comme ça ? Alors ça n'a pas gagné de temps. Ces deux équivalents air. Cela le rend plus difficile à lire, et dans l'ensemble, il rend juste le maintenir plus difficile. Donc, il ne sert à rien de le rendre aussi concis que possible comme ça quand vous le pouvez. Maintenant, vous voulez le garder concis, mais quand vous pouvez le rendre juste un peu plus lisible, toujours de l'air dans le côté de plus lisibles rendre les modules faciles à apprendre et à comprendre aussi. Donc encore une fois, cela revient aux choses de modularité, le couplage, le découplage Chaque fois que vous programmez, si vous devez trouver un nouveau, j'aimerais des méthodes différentes et différentes tous agissant ensemble, alors assurez-vous de les rendre faciles à apprendre et faciles à comprendre. Faites-les, vous savez, haute cohésion, faible couplage. Faites-le pour que je puisse le regarder. Et je pourrais immédiatement dire, OK, que nous traitons de nos informations de paiement qui traitent avec Vous savez, c'est de l'information de l'utilisateur qui traite avec l'utilisateur lui-même, quelque chose de rapide comme ça. Et enfin, nous voulons briser nos actions dans les méthodes. Nous parlions beaucoup de modularité où nous avons ces grands modules. Cependant, à l'intérieur des modules, nous avons généralement ces choses appelées méthodes. Si vous n'avez pas encore suivi un cours de programmation, ces méthodes sont fondamentalement comme de petites fonctions dans un module, et nous voulons nous assurer que nous créons assez de ces méthodes et que nous ne codons pas. Donc, si nous faisons exactement la même tâche dans cette fonction et cette fonction dans cette fonction, peut-être au lieu de copier et coller à trois endroits, nous créons une nouvelle méthode pour la rendre plus lisible au fil du temps. Mais dans l'ensemble, nous voulons créer du code qui est, quatre personnes que nous voulons créer du code qui est lisible. Nous allons créer un code facile à maintenir et facile à attirer d'autres personnes parce que nous voulons que notre programme réussisse. Et si notre programme réussit, il se peut que nous devions faire appel à plus de gens pour suivre la maintenance et ajouter de nouvelles fonctionnalités , etc. Et si on a un très mauvais code, ça va être impossible. Et même si nos programmes ont dépassé, il va échouer avec le temps parce que nous ne pouvons pas continuer à le faire avancer. est donc quelque chose que les principaux locataires de la mise en œuvre. Et maintenant, passons en quelque sorte dans le problème du déploiement parce que c'est important, c' est de savoir comment déployer notre logiciel correctement afin que nous puissions le sauvegarder ou l'affaiblir . Fondamentalement, prédire certains des bugs qui pourraient sortir et le rendre aussi exempt de douleur que possible. 33. 5-2 Acheter Vs Build: et dernière conférence. J' ai dit qu'on allait commencer à travailler, mais je veux couvrir une chose de plus avant d'être déployés. Et c'est cette idée d'acheter contre construire. Cette idée est donc très importante car elle peut vous faire économiser beaucoup de temps et vous faire économiser de l'argent à long terme également. Alors quoi ? L' idée de construire Ivers ? Ce que nous avons, c'est que chaque fois que nous avons notre document de conception, nous avons tous ces modules et sous-systèmes classés pour nous. Nous pouvons commencer à regarder ces modules et voir s'il y a quelque chose là-bas qui s'affaiblit au lieu de se développer en interne. Beaucoup d' entreprises ont l'idée qu'elles doivent tout développer par elles-mêmes. Ils doivent le développer en interne, et c'est la seule façon de le faire. Mais cela peut vous laisser à beaucoup de problèmes. Tout d'abord, il pourrait être plus coûteux, développé quelque chose au lieu d'acheter quelque chose. Si nous avons acheté quelque chose, une autre société l'a déjà développé et ils gagnent de l'argent parce qu'ils le vendent à des tonnes de gens. Donc ils ne le vendent pas pour, vous savez, une solution unique qui est généralement plus chère. Ils le vendent à un tas de gens, je crois. Microsoft Office Combien cela coûte-t-il ? Je pense que c'est sur un modèle d'abonnement de quelque chose comme 100$ par an maintenant. Imaginez si vous, en tant qu'entreprise, décidez que vous allez construire votre propre suite Microsoft ou votre propre, vous savez, Excel, Excel, qui est des feuilles de calcul, votre ancien traitement de texte votre propre essentiellement power point. Donc, vous êtes sur le processeur de diaporama lui-même. Combien pensez-vous que ça coûterait ? Ça ne coûtera certainement pas 100$ par an. Ça va probablement vous coûter quelque part environ 500 000 dollars plus pour obtenir un programme qui est même décemment proche de Microsoft. Donc, dans cette situation, bien sûr, vous n'allez pas le développer vous-même. Tu vas l'acheter. Et cela peut aussi se produire dans le cadre de nos propres projets. Pourquoi réinventer la roue quand nous pouvons dépenser un peu d'argent, économiser beaucoup de temps et avoir réellement un produit qui est développé et entretenu par quelqu'un d'autre pour que nous n'ayons même plus à travailler sur son entretien ? Il est complètement entretenu par quelqu'un d'autre pour tous les coûts qu'on a payés. Donc, dans cette situation, ce que nous pouvons faire est que nous pouvons réellement descendre nos modules avant de commencer la mise en œuvre et regarder les choses. Donc, par exemple, dans celui-ci, on pourrait dire, oui , il y a quelque chose. Il y a une excellente solution. C' est vraiment, vraiment bien considéré. On va aller de l'avant par celui-là. Ça dit de le développer, et peut-être que ça ici et ça allait acheter aussi. Tout le reste ne correspond pas à ce que nous voulons. Donc on va finir par devoir construire ces choses et donc juste construire tout ça ici. Mais dans l'ensemble, imaginez si c'était à gauche, vous savez , peut-être, ah 500 notre projet et celui-ci sur la droite ici. Peut-être que c'était quelque chose comme un 2000. Notre projet pour que ça fonctionne. Nous nous sommes sauvés tout un tas de temps. Et maintenant, nos ingénieurs qui travailleraient là-dessus peuvent nous aider à les finir. Donc nous avons ce produit qui va sortir beaucoup plus vite. Nous allons économiser de l'argent à long terme parce qu'à 2000 heures coûtent beaucoup avec ingénieurs logiciels, et nous allons en fait avoir des parties qui sont maintenues par d'autres entreprises. Donc, chaque fois que vous cherchez à construire votre projet, avant de commencer à implémenter, faites une recherche rapide, voyez s'il y a une implémentation là-bas et que beaucoup de fois sont en fait gratuits, ce qui est un peu fou, mais ils sont appelés open source. Incroyable, mais faites une recherche rapide, voir si quelqu'un d'autre l'a déjà fait. Et ne réinventez pas cette roue. Assurez-vous de voir s'il y a quelque chose que vous pouvez acheter, quelque chose que vous pouvez même commencer, un modèle quelque part pour commencer afin que vous puissiez gagner du temps, économiser de l'argent et faire sortir votre projet à temps. 34. Aperçu de déploiement 5 -3: Ok, alors commençons à parler de déploiement. Le chômage est un peu délicat en ce sens qu'il s'agit en fait d'un mélange entre deux choses différentes. Et qu'est-ce que je veux dire par là ? Ce que je veux dire, c'est que le déploiement se produit dans un espace de temps après les tests après la construction. C' est arrivé en quelque sorte à la fin du cycle de vie. Cependant, dans la phase de construction, déploiement est souvent pris en compte lors de la mise en œuvre au cours de la construction réelle du projet. Et c'est parce que beaucoup de fois avec le déploiement, ce que nous avons, c'est qu'il doit avoir une sorte d'implémentation créée pour cela. Alors peut-être qu'on doit coder. Le projet est un peu différent. Peut-être devrions-nous mettre en place un serveur supplémentaire. Nous devons mettre en place des zones de secours dans tous ces trucs. Cela se produit dans la phase de mise en œuvre. C' est pourquoi beaucoup de fois l'ingénierie informatique et moi aimons penser au déploiement dans cette sphère d' implémentation, parce que la seule façon d'obtenir le bon déploiement est de le construire dans le projet lui-même, et c'est très important. Est-ce que c'est un déploiement ? Beaucoup de fois doit être planifié, et il était utilisé dans le codage de l'APP. Nous ne parlons pas ici d'une sorte d'emploi réduit ou juste, vous savez, s'occuper de certains testeurs internes ou de quelque chose comme ça. Nous parlons du déploiement final. Ce que je veux dire par là, c'est celui où nous avons le projet et il va en fait aller aux utilisateurs finaux ici. Donc, ce sera le produit final qui sera payé pour que les gens vont utiliser, et c'est là que nous devons avoir un plan. Nous avions un plan pour deux ou trois raisons différentes. La première, une raison majeure, c'est qu'on ne veut pas casser les choses. Peut-être que c'est, tu sais, un point. Oh, et dans ce cas, nous n'avons pas vraiment à penser à Rollback parce que nous libérons le produit. Donc, s'il y a un problème avec ça, le seul retour en arrière que nous pourrions faire de la seule façon que nous puissions revenir en arrière est celui qui a cessé d'offrir le produit. Cela n'a généralement pas de sens, mais ce que nous devons vraiment nous assurer, c'est si nous partons de ce point. Oh, et on passe à deux points. Oh, maintenant c'est là que cette idée de retraite entre en jeu. Le retour en arrière du retour. Si on se déploie, on ne veut pas tout casser. Si nous avons, par exemple, nous courons un point par ici. 1.0 pourrait faire de l'argent à l'entreprise. En ce moment, 1.0 nous rapporte des profits. Nous essayons juste de le mettre à niveau à deux points. Oh, parce que nous pensons que ce sera mieux. Ça attirera plus de clients et fera plus d'argent au fond ici. Donc, nous voulons mettre à niveau pour souligner que le problème existe ici si une erreur survient au cours cette phase, quelque chose que nous ne nous attendions pas à venir sera. Maintenant, non seulement nous ne gagnons pas de l'argent à partir de 1.0, pour souligner n'a pas non plus sorti. n'avons donc plus de produit. Nous offrons à chaque seconde Mme vers le bas. On perd de l'argent. Imaginez si Amazon dot com imaginez le géant que vous connaissez, le marché qu'Amazon est. Imaginez si ça descend pendant cinq minutes, 10 minutes. Combien d'argent pensez-vous qu'ils perdraient à cause de ces petites périodes d'inactivité ? Donc, dans ces situations, une idée de rollback est très importante, et l'idée de rollback vient en quelque sorte dans Nous ne savons pas. On pense que ça va passer, mais on se prépare à échouer à n'importe quelle étape. Et si elle échoue, l' une de ces étapes, notre programme ou la personne exécutant la mise à niveau saura exactement quoi faire. Il y aura un plan pour qu'il puisse revenir en arrière et revenir à un point, puis nous le réparerons plus tard et réessaierons plus tard. C' est la chose que nous avons le plus besoin de planifier, c'est d'avoir ce plan en place de sorte que lorsque quelque chose se passe mal, ce n'est pas complètement et totalement inattendu. On éclate sur l'air comme, Ok, il y a une erreur. On ne l'avait pas anticipé. Revenons en un seul et nous allons le comprendre. Donc, remonte sur l'un. On recommence à gagner de l'argent et on découvre ce qui ne va pas pour faire mâcher ? Et ce niveau de planification est directement lié à la façon dont le déploiement affecte l' ensemble du projet. Donc, si c'est une petite mise à jour, une grande mise à jour ou complète dans l'ensemble, dans cette situation, nous parlons d'une révision complète, donc nous avons besoin de toutes les situations couvertes pour que quoi que ce soit, nous aurons un produit à la fin de cette annulation. Si nous parlons d'une très petite mise à jour, peut-être que nous changeons la couleur d'un bouton quelque part. Nous n'avons probablement pas besoin de trouver un plan de dos noir géant pour ça. n'y a pas beaucoup de choses qui peuvent mal tourner. C' est juste une mise à jour de document HTML minuscule. Et peut-être que le seul plan que nous avons est de simplement sauver l'ancien et un petit dossier de sauvegarde puis exécuté. Et si quelque chose ne va pas, il suffit de le remplacer. C' est vraiment, vraiment simple. C' est, vous savez, ce serait exactement une très petite mise à jour. Lorsque nous arrivons à ces mises à jour plus importantes, nous avons besoin Il pourrait y avoir des centaines de fichiers qui changent. Il y en a peut-être des milliers. Il pourrait y avoir de nouvelles bases de données qui arrivent en ligne, lignes de communication nouvelleslignes de communication, de nouveaux flux de contrôle, et nous devons nous assurer que si au milieu de cela, il est en train de construire et que nous avons celui-ci monte et puis il s'écrase ici. Que se passe-t-il ? Est-ce que nous supprimerons cela et supprimons cela ? Retourne tout le chemin juste à l'un. Existe-t-il, comme, comme, serveur de sauvegarde qui a un point tous en cours d'exécution. Et donc nous prenons ce serveur, détruisons, puis passons en quelque sorte tout le trafic sur le serveur, ce qui fonctionne beaucoup de choses différentes. On pourrait y aller, et c'est qu'on va passer en déploiement. 35. Planification de déploiement 5 ou 4: ce soir, nous avons abordé l'introduction, le déploiement. Examinons la planification réelle du déploiement. Maintenant, avec la planification du déploiement, nous n'avons pas ce genre de modèle que nous pouvons créer dans beaucoup d'autres domaines. Et cela est essentiellement dû au fait que la planification et l'idée de déploiement sont très, très concentrées sur exactement le problème à portée de main. Ce que je veux dire par là, c'est dire que nous parlons d'Amazon et que nous voulons ajouter une nouvelle fonctionnalité ou quelque chose de nouveau à Amazon. Maintenant, si nous ajoutons quelque chose comme un changers backend, nouveaux produits ou une nouvelle taxe Jha Amazon, ce sera un processus de déploiement différent. Ensuite, si nous l'avons ajouté à walmart dot com, ou si nous l'ajoutons à eBay ou à tout autre détaillant en ligne, et c'est parce que chacun est construit différemment. Par conséquent, il n'y a pas de taille unique pour tous les plans pour ceux-ci et à cause de cela, Comme je l'ai dit, nous n'avons pas de modèles ici. Tout ce que nous avons, ce sont ces questions que nous devons nous poser pendant que nous élaborons le déploiement pour réellement créer un plan de déploiement que nous pouvons ensuite mettre en œuvre, donc ne vous attendez pas comme n'importe quel modèle ou quoi que ce soit dans cette partie particulière, il suffit de trouver ces idées et ces questions que nous pouvons poser. Donc, la première chose que nous comprenons est la quantité de planification qui dépend de l'ampleur du changement. Et ça fait référence à Thean. La vue d'ensemble de la portée du changement est très importante. Si nous faisons un très petit changement Tex, disons que l'un des produits sur Amazon est légèrement mal orthographié. Nous n'avons pas besoin de passer par un processus géant. Tout ce que nous avons à faire est essentiellement de mettre à jour rapidement la base de données, et nous avons maintenant déployé notre changement. Ce n'est rien de grand. C' est juste un très petit changement maintenant pour ajouter de nouveaux produits que nous avons repris. Nous sommes montés dans le niveau, donc nous avons changé le texte. Mais maintenant, nous sommes en train de créer de nouveaux produits entiers. Ceux-ci sont très indépendants. Il ne s'agit pas de l'architecture d'Amazon. Il ne s'agit pas des serveurs dorsaux des données financières. Tout ce que nous faisons, c'est ajouter et quelques produits, il y a quelques choses qui pourraient mal tourner ici. On n'offre pas de choses qu'on n'a pas. Nous ne voulons pas, vous savez, vous savez, enfreindre les droits d'auteur ou quoi que ce soit. Donc un peu plus de planification va là-dedans si nous ouvrons une nouvelle section entière. Donc, disons que nous ouvrons comme une nouvelle section appelée Jouets, où nous mettons en œuvre une tonne de nouveaux produits et peut-être même de nouvelles fonctionnalités. Donc ce n'est pas qu'un seul produit, tu sais. Nous avons plusieurs produits. Tous peuvent être liés à leurs propres petites catégories. Maintenant, nous commençons à avoir cette chose où l'architecture entre en jeu, comment les placer ? L' une de ces nouvelles fonctionnalités a été mise en œuvre. Les choses peuvent commencer à mal tourner dans cette section. Et peut-être qu'après ça, nous ne faisons pas que mettre à niveau, vous savez, une section. Nous mettons à niveau l'ensemble du back-end afin de mettre à niveau toute la façon dont Amazon traite ses informations ou n'importe quel détaillant en ligne. Donc maintenant, nous avons ces clusters de toutes ces données ici que nous touchons. Donc j'essaie de faire, genre, des petites boîtes ici. Donc, vous savez, nous avons, genre, cette boîte est ici dans cette boîte, est là, et c'est très, très détaillé, et ça continue et encore et encore. Donc on met à jour le tout ici. On va avoir besoin d'une tonne de planification pour ça et beaucoup de choses qui pourraient mal tourner. Et nous arrivons à ce point où les choses critiques pourraient mal tourner. Là où un échec ici, Ah, échec à ce stade le ferait. Donc, nous arrêtons de faire des affaires, nous commençons à perdre des tonnes et des tonnes d'argent et ainsi de suite et ainsi de suite jusqu'à ce que vous sachiez, notre mise à jour de l'ensemble du site. Donc, chaque fois que nous créons ces changements, nous devons garder à l'esprit que la portée est très, très importante. Et nous examinons les domaines qui auront probablement les plus grands problèmes et certains des domaines qui la regardent ici. ne s'agit pas d'une liste exhaustive qui correspond à leur bras ou à des domaines que nous pourrions souhaiter examiner. Mais ce ne sont que quelques idées de choses qui pourraient changer. Donc, nous cherchons où les plus gros problèmes pourraient survenir. Et encore une fois, nous n'avons pas besoin de passer beaucoup de temps si nous faisons, même si dans cette mise à jour géante nous faisons quelques changements de texte, nous n'avons probablement pas besoin de faire un rôle noir ou un moyen de revenir sur ces domaines. Ce que nous devons examiner, c'est des choses comme ça, par exemple, des activités de base de données. Peut-être qu'on change le fonctionnement de la base de données. Si nous modifions le fonctionnement de la base de données, il est possible que la base de données devienne corrompue. Peut-être que Power s'éteint pendant une demi-seconde pendant qu'il met à jour la base de données, et maintenant nous avons une sorte de base de données inachevée, latéralement, qui ne fonctionnera pas pour aucune version. Peut-être qu'il y a une faute de frappe, et l'ancienne version ne fonctionne pas avec cette nouvelle version. Et maintenant, nous avons ce gros problème de mishmash de données, et les demandes arrivent constamment. Nous devons donc comprendre ce qu'il faut faire avec la base de données. Intégration de logiciels tiers. Nous changeons notre programme. Mais si on ne pouvait pas dire aux autres trois autres tiers. Cela signifie que ce n'est pas nous, c'est le logiciel de quelqu'un d'autre utilisait. Nous ne pouvons pas leur dire de changer avec nous, donc si nous faisons un changement, nous devons nous assurer que nous sommes toujours bien intégrés. Sinon, cette modification pourrait casser tous les logiciels tiers. Et soudainement, par exemple, si nous travaillons à nouveau avec Amazon, peut-être que l'eBay ou peut-être le système de paiement PayPal ne fonctionne plus, et c'est un gros problème là-bas. Ensuite, nous avons des changements de temps d'exécution. Ainsi, par exemple, pendant l'exécution peut, les choses ont changé. Nous avons obtenu le code pour fonctionner, mais quand nous le déployons et l'exécutons, il peut y avoir quelque chose de changé que nous n'avions pas prévu. Et c'est important de comprendre, ne pas revenir en arrière de la formation sur les deux utilisateurs. Du côté des affaires, le site utilisépour fonctionner d'une certaine manière. Le programme fonctionnait d'une certaine façon, et maintenant il a changé. Donc nous avons besoin d'une formation. Nous avons besoin d'une formation à la fois du côté utilisateur. Peut-être, nous savons que nous avons créé un tutoriel pour aider les gens à le surmonter afin que nous ne perdions pas d'affaires. Et nous avons besoin d'une formation du côté des affaires. Peut-être que les serveurs sont différents. Peut-être que le backend est différent. Nous devons nous assurer que nos entreprises, nos employés, sont formés pour suivre ces changements. Temps d'arrêt, comment on va gérer les temps d'arrêt. Allons-nous,par exemple, par exemple, garder le front en place et juste avoir des ordres ? Peut-être comme empiler ? Si nous, comme si nous parlions d'un détaillant en ligne, est-ce que nous allons juste les mettre dans une file d'attente et attendre que les serveurs soient restaurés ou nous allons simplement fermer tout le site Web et ne laisser personne passer. Et quelles sont les implications financières de toutes ces sauvegardes ? Mémoire réseau. Ce sont des choses qui pourraient changer. Peut-être que les sauvegardes qu'on va aller dans un autre endroit. Peut-être que le nouveau site Web est trop grand et nos sauvegardes ne vont plus fonctionner parce que nous avons besoin d'un espace de stockage plus important, ce qui se passe avec la mémoire. Peut-être qu'on introduit un nouveau A P que j'appelle, c' est-à-dire Ah, fac du serveur. Et peut-être qu'avec cet appel au serveur, nous commençons à avoir des problèmes de réseau. Nous ne l'avions pas anticipé. Ça va passer d'un gigaoctet par seconde à, je ne sais pas, peut-être 10 téraoctets par seconde. Peut-être que nous avons fait un grand changement et peut-être que nos câbles sont du matériel lui-même, ne peuvent même pas gérer ça. Et nous devons implémenter une nouvelle batterie de serveurs ou quelque chose comme ça. Donc, toutes ces choses sont des idées et des domaines que nous devons examiner, et nous devons planifier les étapes et nous devons planifier comment revenir sur ces étapes. Comment on va en arrière ? Quel est un moyen de rétablir le bien ? L' ancien site Web fonctionne parfaitement bien Nous essayons de l'améliorer, peut-être corriger quelques bugs, mais en ce moment, ça nous fait de l'argent. Nous ne voulons pas brûler toute l'affaire. Donc, nous devons nous assurer que nous allons de l'avant par incréments et puis si quelque chose va mal, sautant tout le chemin en arrière et re travailler comme nous le faisons, laissez le jeu planifier. Il y a quelques questions à poser et en quelque sorte de devoir travailler pour que ce soit un déploiement réussi . 36. Rappel de 5 à déploiement: Je veux couvrir l'idée d'un retour en arrière de déploiement. Donc, l'idée de la restauration du déploiement est comme je l'ai dit dans les autres leçons, et c'est l'idée que nous pouvons revenir en arrière. Donc, si nous avons ces étapes, qu'est-ce que c'est que nous avons l'étape 1, puis que nous passons à l'étape 2 et à l'étape 3, et ensuite, disons que cinq, c'est là qu'il est entièrement déployé et opérationnel. Donc, à ce stade, ce que nous devons faire est de regarder les étapes que nous allons utiliser pour déployer notre nouvelle mise à jour, puis nous devons chercher un point de non-retour et nous connaissons le point de non-retour. Nous savons si nous devons aller de l'avant, travailler à travers les héritiers et voir si nous ne pouvons pas vous faire vivre face à vous ou si nous devons revenir en arrière et à chaque étape du processus de déploiement, nous devons décider si la restauration est une meilleure option. Nous devons donc avoir des options sur les moyens de revenir sur tout le monde ces étapes et aussi sur certaines des grosses erreurs qui pourraient se produire. Comment revenir à Let's ah, peut-être que celui-ci est le début ici. La branche maîtresse. Comment revenons au maître ? Donc nous essayons de le faire à partir de cinq orteils. Disons que nous allons mettre ces frais généraux deux points. Oh, donc nous essayons de franchir les étapes jusqu'à deux points. Oh, et nous avons maître ici. Donc, ce que nous essayons de comprendre, c'est à chacune de ces étapes, une des façons que nous pourrions revenir en arrière là où les décisions que nous devons prendre sur la question de savoir si nous devons continuer ou revenir en arrière, Disons que nous disons notre point de aucun retour n'est à l'étape trois juste après l'étape trois. Et la raison pour laquelle cela est important à savoir est que c'est le moment où il faut plus de temps pour revenir en arrière que pour continuer à travers. Peut-être que vous avez déjà passé plus de temps qu'on ne le pensait au début, mais nous en sommes déjà à l'étape 3. Nous savons maintenant qu'il n'y a aucune raison que nous ayons besoin de revenir en arrière parce que cela prendra encore plus de temps que pour continuer et passer à deux points. Oh, donc dans cette situation, si nous savions notre point de non-retour au lieu de quelqu'un qui annule le déploiement, nous dirions que continuer à pousser vers l'avant était en fait très proche de terminer le déploiement . Maintenant, à tout moment, s'il y a une erreur, nous devrions revenir en arrière, peu importe combien de temps cela prendra. Nous ne voulons pas déployer, vous le savez complètement et totalement cassé morceau de logiciel. Et aussi à chacune de ces étapes, nous devons décider si la restauration est une meilleure option. Disons qu'on prévoyait que celui-ci prendrait 30 minutes. Cette heure, 10 minutes, 5 minutes, peut-être 15 minutes. Quelque chose comme ça. Si nous passons au-delà et que cela est déjà pris deux heures, peut-être que nous ne voulons pas continuer à passer ici. Peut-être que nous avons déjà compris que notre plan était que vous le savez bien, si cela prend quatre fois plus de temps que prévu, notre plan n'est pas très bon. Donc, nous devrions probablement le ramener au maître et recréer notre plan pour que nous ne finissions pas, vous savez, huit heures d'arrêt alors que nous ne prévoyons que juste environ une heure, et donc c'est très important après chaque étape pour nous assurer que nous en avons besoin si nous avons besoin de revenir arrière si la restauration est une meilleure option. Mais juste pour garder l'idée de la restauration du déploiement à l'esprit créera de meilleurs plans pour le déploiement. Beaucoup de gens vont simplement ne pas planifier le déploiement ou ils vont venir avec un plan. Mais ils ne viennent jamais avec un plan sur la façon de revenir en arrière. Et revenir en arrière est à nouveau la partie la plus importante du processus planétaire. C' est pour s'assurer de ne pas casser tout ce que nous pouvons recommencer, revenir sur le nouveau plan et de le refaire. restauration du déploiement n'en tient donc pas compte lorsque vous établissez votre plan de déploiement . 37. Aperçu des tests 6: passons au test, qui est fondamentalement l'étape longue du cycle du logiciel. Et ce que je veux dire par ceci, c'est que tester beaucoup de fois n'est pas fait correctement et beaucoup de fois tout simplement pas fait du tout. Et cela est dû à quelques choses différentes. L' une des principales raisons de cela est que le test est très difficile de savoir exactement comment fonctionne votre programme et de comprendre ce qui ne va pas. Et ce qui est juste, c'est quelque chose qui est difficile à faire. Et beaucoup de gens aiment simplement le publier au public et laisser le public être essentiellement testeurs. Et je veux dire, c'est une façon de le faire. Mais vous pouvez avoir de mauvaises perceptions de vos programmes si vous le faites, en particulier les jeux vidéo. Si les jeux vidéo sont libérés avec une tonne de bugs. Ah, beaucoup de fois les gens remboursent le jeu ou ils abandonnent toute la franchise à cause des bugs. Avoir une stratégie de test solide en place est très important pour s'assurer que votre produit est libéré avec la plus grande qualité qu'il peut avoir, parce que même si nous avons tout construit environ 90% si 10% des choses cassent le programme, ou plus, le vers le bas inutilement, ou créer des erreurs que nous devons traverser. C' est considéré comme un mauvais travail et les gens vont passer à autre chose. Il y a tellement de logiciels là-bas que les gens vont passer au suivant, donc le processus de test est très, très important. Les gens abandonneront également cette étape à cause des craquements de temps. S' il y a une date d'échéance. Les tests sont généralement à la fin du cycle de vie du logiciel. Cela signifie que si les dates d'échéance arrivent, les gens vont essentiellement sauter cette dernière partie. Ils vont sauter la partie test avant qu'ils ne la libèrent. Et encore une fois, c'est ainsi que les bugs sont créés. Donc, ces deux choses pourraient contribuer aux tests. Être pour les gens acquis ne le font généralement pas, mais c'est extrêmement important. test est donc le processus de recherche d'erreurs. C' est très, très simple. Tout ce que nous essayons de faire, c'est de voir si notre programme fait ce que nous voulons . Nous contestons essentiellement tout ce que nous contestons. Le code lui-même, qui est ce qu'est beaucoup de tests, exécute réellement le programme, en déterminant si cela fonctionne, nous contestons les implémentations. Donc, en passant par différentes façons de la façon dont les données sont rassemblées, comment, vous savez, les données du serveur sont transférées ? Est-ce que cela arrive essentiellement avec une intégrité totale, ce qui signifie que si une mise à jour arrive sur le serveur est-ce que cela se passe sur le client local ? Les choses fonctionnent-elles exactement comme elles devraient ? On ne peut même pas tester la documentation. Nous pouvons regarder dans la documentation avant même de commencer la programmation et d'affaiblir le test si le plan est quelque chose de intelligent, s'il pourrait être affiné, s'il fonctionnera plus tard lorsque nous commencerons à le construire. Et nous pouvons même tester d'autres tests. Parce que si nous avons un mauvais logiciel de test, si nous avons un logiciel semble que même si nous mettons une entrée, il ne donne pas la sortie correcte, il va dans la mauvaise direction ou quelque chose comme ça. Eh bien, c'est plutôt mauvais, parce que ça veut dire que tous les tests auront un bon programme. Eh bien, ça dira que c'est mauvais, et nous allons le changer en un mauvais programme pour que nous puissions même créer des tests quatre autres tests. Et voici un joli petit graphique que j'ai trouvé fourni par cette université que vous voyez ici. Et c'est une sorte d'idée sur la façon dont les tests pourraient être faits. Donc on peut le faire dans ce genre de ce qu'on va être. Ce que l'on appellera la méthode des chutes d'eau quand on parle de méthodes ou de façons de développer des logiciels, où on va faire une étape, puis l'étape suivante, l'étape suivante, l'étape suivante. Ou on pourrait le faire comme ça. Et nous voilà, leurs exigences étape. Et aussi les spécifications de l'assistant Rappelez-vous, spécifications et exigences. Quoi ? Nous pouvons réellement faire un plan de test d'acceptation, qui signifie que nous testons si c'est même quelque chose que nous voulons créer. Ensuite, une fois que nous entrons dans les spécifications, nous allons à la conception, rappelez-vous parler de conception, puis nous pouvons commencer à discuter du plan de test d'intégration du système. Alors, quel est le plan que nous allons utiliser pour tester l'acceptation ? Quel est le plan que nous allons utiliser pour tester l'intégration ? Et puis on va décider, tu sais, avec ça, comment est-ce un bon usage ? Est-ce ce que nous voulons continuer avec cela ? Ensuite, une fois que nous arrivons à la conception détaillée que nous avons commencé à examiner l' intégration des tests de sous-système . Donc, encore une fois, nous planifions les tests d'intégration réels, et vous pouvez voir que pendant toute cette étape, non seulement nous avons fait un peu de tests , nous faisons également beaucoup de planification de tests. Nous planifions donc les tests que nous devrions mettre en œuvre à chaque étape que nous traversons. Ensuite, nous avons des tests de module et de code unitaire. Et c'est bien sûr, après le rire de la conception de détail, nous commençons à le construire. Et puis une fois que nous l' avons construit, nous pouvons ensuite passer par les tests et c'est contre la méthode des chutes d'eau où nous allons juste étape par étape. Sauf que ces plans sont ensuite mis en œuvre dans les étapes. Donc nous commençons à tester les sous-systèmes que les systèmes plus grands, et ensuite s'il fait réellement ce que nous voulions faire, donc nous allons tester fondamentalement, çava passer d' ça une méthode ascendante. Donc, nous testons les très petits, les cœurs, les lignes de code, et ensuite nous allons voir si les lignes de code s'intègrent bien et commencent réellement transférer des données, comment nous les voulions. Et enfin, nous voyons bien, ok, nous avons ce logiciel ne fait pas ce que nous avions prévu pour qu'il fasse. Si nous le faisions, si nous décidons de créer un traitement de texte, nous ne vérifions plus jamais les exigences. Et à la fin, nous avons un gestionnaire de feuilles de calcul. Je me fiche de comment tu sais, peu d'insectes qu'il a. Je me fiche de comment tu sais, Il n'accomplit pas le fondamentalement le problème que nous avons entrepris d'accomplir son quelque chose de complètement différent. Nous devons donc nous assurer qu'il accomplit toujours ce que nous voulons et qu'il soit libéré. Nous avons quelques mots clés tout au long de ce processus. Donc, les mots clés vont être test hors cas de test, puis Oracle. Donc ce qu'ils sont, ils sont fondamentalement une terminologie commune. Les données de test sont les importations qui sont conçues pour tester le système. Donc, chaque fois que nous testons quelque chose, nous avons un ensemble d'entrées. On essaie quelque chose, et ça va être les données du test. Même le test qui n'a pas besoin d'être comme des textes ou des chiffres. Il peut s'agir d'une séquence d'étapes que nous faisons Donc, par exemple, faisant une transaction financière, il pourrait être de payer via PayPal. Il pourrait s'agir de payer par carte de crédit. Cela pourrait être l'apport de la façon dont nous allons le faire. Et puis avec ces données de test, nous pouvons alors créer des cas de test et des façons d'utiliser le système avec les données données données. Et encore une fois, ces deux sortes de vont un peu main dans la main. Donc si nous faisons ce truc financier, peut-être que le cas de test utiliserait PayPal, et les données de test seraient un bien connu et une mauvaise carte de crédit connue. Mais ces deux ensemble sont ce que nous allons utiliser ces entrées et la façon d' utiliser les entrées que nous allons utiliser pour tester le système. Et enfin, nous devons savoir, est-ce un bon résultat ou un mauvais résultat ? Et c'est ce qu'est Oracle. C' est une sorte de terminologie unique pour l'informatique ici en ce sens que nous avons utilisé l'oracle pour l'ensemble de bons résultats. Donc, chaque fois qu'on teste quelque chose, on avait quelque chose à comparer. Nous, par exemple, si nous construisons une calculatrice très complexe et qu'elle est censée faire ces problèmes de mathématiques, peut-être que je ne sais pas comment fonctionnent ces problèmes de mathématiques donc j'ai besoin d'une feuille de papier pour me dire que je devrais pouvoir entrer dans cette équation mathématique, et il devrait être en mesure de me donner ce résultat. Si je n'ai pas cette feuille de papier. Peu importe combien je mets. Si je ne sais pas quel est le résultat attendu, comment puis-je le comparer pour voir si c'est réellement bon et tout cela est lié de différentes manières . Donc, d'habitude, on commence par quelque chose ici où c'est comme les cas de test. Donc on est en quelque sorte au départ. Qu' est-ce qu'on va tester ? Quelles sont les choses que nous devons tester ? Et avec cela, nous finissons ensuite avec les entrées ou les données de test, et ensuite nous devons aussi trouver une sorte de sortie attendue. Donc, quelle est la sortie, la bonne sortie, et puis Ou nous allons nous assurer que nous mettons cela comme prévu, Un peu bâclé, mais c'est la sortie attendue là-bas. Alors quoi ? Les données de test que nous allons ensuite exécuter vont mettre le logiciel à l'essai . Nous allons faire le test, et ensuite avec ça, nous allons obtenir une sortie ici, et ensuite avec cette sortie, nous allons la comparer à la sortie attendue et à ce qui est attendu. Mais c' est l'oracle. Donc, l'Oracle est juste ici et puis avec les données de test, nous devons comprendre quelle était l'entrée pour voir quelle était la sortie correcte. Donc, si nous avons l'oracle de la sortie d'entrée, donc nous avons la sortie d'entrée, et c'est une sorte de l'oracle ici. Cette ligne de code devrait être la suivante. Ça devrait être, tu le sais etc. Nous avons besoin des données d'entrée pour voir ce que la sortie Danish. Donc c'est notre test. Cela, ainsi va à l'oracle sont attendus. La sortie est le côté droit. Ensuite, nous le comparons avec la sortie entrant. Donc, la sortie entre, nous regardons la comparaison et nous créons le test. C' est juste une sorte de petit flux de la façon dont cela devrait fonctionner. Ici encore, nous avons des cas de test qui va tester et la sortie attendue. Les données de test sont entrées dans un test. Donc, nous faisons le test, il obtient la sortie. Nous le comparons à l'oracle pour voir si c'est bon et c'est une sorte de vue d'ensemble des tests , et maintenant il est en quelque sorte de plonger dans un peu plus de l'importance des tests de différentes façons que nous pouvons le faire. 38. 6-2 Bugs de test: Alors passons aux tests en ce qui concerne les bogues. Discutons vraiment de ce qu'est un problème. Qu' est-ce que nous recherchons chaque fois que nous testons et c'est cette idée de bugs. Donc les bogues sont fondamentalement un écart par rapport au comportement attendu, et nous devons considérer s'il s'agit d'un bug ou d'une fonctionnalité ? Parce que si on n'a pas une idée de ce qu'est le comportement attendu, comment savoir si on s'en dévie ? Une personne pourrait regarder le logiciel et s'attendre à ce qu'il soit. Et puis ils pourraient penser que le logiciel fonctionne parfaitement bien. d' Quelqu' und'autre pourrait avoir une autre attente quant à ce que ce logiciel devrait faire. Et quand ils cliquent sur quelque chose, quelque chose d'inattendu leur arrive. Et donc ils pensent que c'est un bug. Nous devons donc savoir si c'est un bug ou une fonctionnalité. Nous devons comprendre quel est le logiciel censé dio et s'écarte-t-il de cela ? Et BookScan soit à la fois un air. Donc, fondamentalement une ventilation de l'ensemble du code, la partie du code qui conduit réellement à l'échec ou, ce sujet, la terminologie aérienne. Ici, ce n'est pas, Vous savez, le bogue de niveau spécifique ici. C' est plus que je pense qu'on les appelle un défaut. C' est comme le terme technique ici. Donc les bogues pourraient être à la fois un défaut où une erreur est Quoi ? La nomenclature commune de la façon commune de dire qu'il est Onda déviation du comportement attendu . Donc, il pourrait être à la fois un système mettant fin à des choses que nous cliquons dessus et l'ensemble du système se bloque ou juste un léger écart par rapport au comportement attendu. On a mis trois plus trois, et ça équivaut à sept. Il a fait un calcul parce que si on fait trois plus deux, peut-être égal six. Donc, il fait des calculs. Mais il y a une déviation dans ce comportement attendu. Et il semble peut-être qu'avec ça, il y a ah plus un qui se passe et s'éteint par un seul air quelque part dans le code. Mais maintenant, si bien sûr, nous avons aimé trois plus trois et nous venons d'avoir, vous savez, vous savez, air et l'ensemble des accidents de l'émission qui sont également supérieurs à ceux qui sont tous les deux dans la même catégorie. Donc, nous devons regarder à nouveau. Qu' est-ce qu'on attend ? C' est déviant ? Est-ce qu'il s'écrase ? Et puis on pourrait en quelque sorte le classer et trouver comment le réparer. Et donc nous avons ce genre de terminologie spécifique, cette idée d'un échec et de l'air de notre faute. Et toute cette idée d'un bug peut encore être mise dans la catégorie d'un défaut. Donc, l'échec est l'événement par lequel le code s'écarte du comportement attendu. Donc, l'événement qui signifie que la panne réelle du code si nous avons si nous écrivons un rapport de bogue, l'échec est ce que nous pourrions mettre dans le titre du programme de rapport de bogue se bloque en faisant cela. C' est là l'échec réel. L' erreur est la partie du code qui conduit à l'échec. Donc, si nous regardons réellement dans le code, l'air , le code, disons les lignes de code ici, ceci ici, peut-être que c'est l'erreur. C' est la partie où le code dévie réellement de prévu. Et puis la faute est ce que le résultat réellement Waas. Nous avons donc une entrée et c'est la sortie attendue. La sortie attendue est ici, mais le réel ce qui s'est réellement passé ici est la faute. C' est le changement. Ce qui a réellement fini par se passer et c'est ce que nous pourrions mettre en défaut. Nous nous attendions donc à un, mais nous avons B. Et c'est là que la faute entre en jeu. Ainsi, les tests pourraient être utilisés pour montrer la présence de bogues, mais jamais pour assurer leur absence. C' est très important, c'est que nous pourrions tester le programme 1000 façons différentes. Mais qu'est-ce qui ne va jamais arriver au point où nous pouvons garantir leur absence ? Et c'est en fait une sorte de, Ah, peu que j'ai besoin de mettre comme un petit tour de cul ici parce que tu peux en assurer l' absence. Mais c'est très, très compliqué, et vous devez prouver mathématiquement chaque ligne de code, ce qui signifie que vous devez trouver des équations qui prouvent que chaque méthode chaque système ne peut pas y avoir d'erreurs. Et cela est extrêmement coûteux et généralement utilisé uniquement dans quelque chose comme peut-être des missiles, dessystèmes de défense, systèmes de défense NASA. Donc, comme une exploration spatiale ou des choses de haute sécurité comme des entités gouvernementales. Et même alors, il n'est généralement pas complètement assuré. C' est comme juste, vous savez, 99% l'ont assuré très, très difficile d'assurer leur absence et rappelez-vous encore de dire qu'ils assurent l' absence dont nous parlons. Nous pourrions en extraire la plupart des bugs, mais nous disons que nous ne pourrions jamais, vous savez, vous savez, garantir que 100% des bogues ont été vérifiés à moins que nous ne fassions ce genre de preuve mathématique, ce qui est presque impossible. Donc on voulait en parler. Alors gardez ça à l'esprit, c'est que nous pouvons le tester. On a confiné les insectes, mais on ne pourra jamais le dire. Oh, parce que tous ces cas de test fonctionnent. n'y a plus de bogues dans notre programme. On n'arrivera jamais vraiment à ce point. Et voici juste une sorte de petit graphique intéressant du cycle de vie d'un bug, et vous pouvez voir que c'est un processus un peu complexe. Nous obtenons un bug qui arrive et qui vient dans un état non confirmé, et ensuite avec cela, nous devons le catégoriser. Donc nous avons ces étapes, nous l'assignons d'abord à quelqu'un pour le faire. Peut-être que vous ne chiez pas les changements. C' est ce genre de mode. Et puis on doit, tu sais, trouver l'insecte. On va ensuite le mettre dans une catégorie de, tu sais, quand on travaille sur l'insecte. Était-ce réparé ? Était-ce un duplicata comme cela a déjà été signalé ? Peut-être que ce n'est pas une solution, ce qui veut dire que ce n'est pas vraiment si important, et ça prend beaucoup trop de temps. Il y a plus de questions pressantes à la fin des travaux pour moi. Celui-ci est en fait assez typique. Si vous n'avez pas ce que les gens signalent des bogues, ils ont besoin d'une étape par étape très spécifique pour accéder à ce bogue. Sinon, ah, le programmeur pourrait le regarder. Allez bien. Je l'ai fait et ça marche parfaitement bien. Ils n'ont pas compris que toutes ces étapes supplémentaires ont été utilisées, et donc, ça revient en quelque sorte comme une œuvre pour moi. Tu ne peux pas réparer quelque chose que tu ne vois pas vraiment se briser. Donc, beaucoup de fois cela va arriver avec un bug. Invalide signifie peut-être que ce n'est pas un bug. Peut-être que c'est une fonctionnalité. Peut-être que c'est quelque chose qui devrait être ça. Et nous devons mieux communiquer avec le client sur le fonctionnement du programme, rappeler et plus tard, ce genre de le mettre sur le feu arrière. Nous allons le corriger plus tard sur les choses de tri, et il y a tous ces différents flux ici hors si le bug a été résolu. Et enfin, quand c'est fini, tu sais, tu sais, nous fermons ça et nous attendons que d'autres bugs arrivent. Et c'est un test de bogues très typique ou un cycle de vie de bogues. Le bug arrive, on passe par toutes ces choses. À un moment donné, il va être confirmé ou essentiellement mis sur le brûleur arrière. Ou mon père va être réparé ou mis sur le backburner à un moment donné et peut-être qu'on le réparera plus tard. Ou mon père va être réparé ou mis sur le backburner à un moment donné et peut-être qu'on le réparera Peut-être que nous ne le ferons pas. Mais les bugs sont importants à comprendre. Ils sont à la base de ce qu'est le test. On essaie de les trouver. Nous essayons de comprendre comment les arrêter, et nous essayons de nous assurer que l'utilisateur ne les trouve jamais comme nous le faisons en premier. 39. Vérification 6-3 et validation: une discussion importante lorsque nous parlons de tests est cette idée de vérification et validation. Donc, avec la vérification et la validation, nous avons ces deux mots qui semblent semblables, et ils regardent tous les deux des choses similaires, et c'est pourquoi ils sont beaucoup confus. Alors passons par la validation de vérification et assurez-vous que nous sommes tous sur la même page ici. Donc la vérification est qu'on construit la chose juste ? Et vous remarquerez que la validation est qu'on construit la bonne chose ? Juste ah, petit changement du mot ici, mais c'est une différence très, très nette. Alors, est-ce qu'on construit la chose juste ? Construisons le logiciel correctement et ce que nous comparons quand nous parlons de cela ? Eh bien, chaque fois que nous parlons de vérification, nous parlons du logiciel fonctionne-t-il par rapport aux spécifications données ? On nous a donné un ensemble d'instructions sur ce que nous devrions construire. Est-ce que ça marche par rapport à cet ensemble de choses que nous devrions construire Teoh ? Et donc un exemple est cette vacances rapide que le logiciel calculera le prochain paiement mensuel en utilisant le formulaire. Vous pouvez voir que c'est un peu ambigu. Donc, ce que nous faisons, c'est de prendre une certaine liberté créative. Peut-être qu'on crée un front et une forme qu'on met, tu sais, peut-être quelque chose comme ça, quelque chose comme ça et un petit bouton ici. Vous cliquez sur le bouton et puis peut-être qu'il l'envoie dans un e-mail. Peut-être que c'est comme ça que ça marche. Donc il l'envoie comme ça. Email à, ah, retour dans le serveur quelque part. Et donc ça marche ? Cela fonctionne-t-il par rapport à ces spécifications ? Oui, ça marche. C' est tout à fait bien. C' est vérifié. Nous faisons la bonne chose par rapport aux spécifications données. Voilà le problème. Est-ce que la validation est que nous construisons la bonne chose ? Sommes-nous en train de construire ce dont l'utilisateur a réellement besoin ? Est-ce que nous construisons ce que l'utilisateur veut utiliser ? Et il y a beaucoup de fois une rupture dans la communication est que ce n'était pas assez spécifique . Donc, nous l'avons construit en pensant que nous savons ce que les besoins habituels ou veulent, et donc le logiciel est vérifié. Ça marche exactement comme ils nous ont dit que ça fonctionnerait, mais ce n'est pas valide. Ce n'est pas quelque chose dont l'utilisateur a réellement besoin à ce moment donné. Ils ne voulaient pas ce type de formulaire. Ils voulaient peut-être, ah, une sorte de script Java. Ils voulaient, tu sais, quelque chose qu'on pourrait mettre ici. Cliquez sur un bouton, puis il ira à une autre page. Et peut-être qu'il vous montrera quelque chose comme un graphique, ou ça vous montrera, vous savez, votre paiement mensuel. Ou peut-être que tout est sur la même page ici, et vous remarquerez que cela fait exactement la même chose que les spécifications aussi. Il calcule le paiement mensuel du cou en utilisant un formulaire, mais ce sont deux implémentations différentes. Donc, même si les deux sont vérifiés, ils ne sont pas tous les deux validés. Et cette validation de validation est la plus difficile. Fondamentalement, la zone qui est la plus difficile à accomplir est parce que souvent nous ne savons pas ce que l' utilisateur veut, et l'utilisateur peut même ne pas savoir ce que l'utilisateur veut. Et il est donc très difficile de comprendre ce que l'utilisateur veut et de construire le bon logiciel. Parce que nous, en tant qu'ingénieurs logiciels nous en tant qu'entreprise de conception de solutions pour les problèmes. Nous essayons de trouver une solution au problème, exactement ce que je viens de dire. Cependant, si le problème n'est pas défini correctement, nous pourrions construire une solution pour un problème différent, et je vais le répéter. Nous pourrions construire une solution pour un problème différent et donc l'utilisateur n'a pas besoin de cela parce qu'ils n'ont pas ce problème. Donc on a un problème Ah, hein ? Et un problème est que nous pourrions construire une solution pour le problème A. Et si une entreprise vient avec, vous connaissez le problème A. Nous avons trouvé une solution. Notre programme ici est la solution à un problème. R. Mais ce que l'utilisateur veut réellement, ce que les utilisateurs payent est une solution. Le problème en soit ainsi, même si nous avons construit une solution qui fonctionne, il résout un problème. Ce n'est pas le cas. Ce n'est pas la solution au problème actuel, et ce n'est donc pas une solution valable. Donc, chaque fois que nous parlons de vérification et de validation, nous devons juste comprendre cette vérification. Est-ce que nous construisons la chose juste avec les spécifications données ? Est-ce que nous construisons correctement et ensuite la validation ? Sommes-nous construire la bonne chose sont de reconstruire la chose que l'utilisateur que le client veut que nous construisions 40. Tests d'unité 6 ou 4: Donc, l'une des façons de tester les choses est que nous utilisons cette idée appelée test unitaire. Ainsi, le test unitaire est l'idée de tester pour se concentrer sur la plus petite unité d'un logiciel. Et en gros, ça veut dire que nous essayons d'isoler. Nous essayons d'isoler différentes zones encore et encore et encore et de tester l'ensemble du programme comme ça. Donc, le programme va essentiellement être composé. Ah, tout un tas de petits modules communiquant tous les uns avec les autres de différentes manières et que ces petits modules seront probablement emballés dans les plus grands modules et ainsi de suite et ainsi de suite. Mais ce que nous voulons dio, c'est que nous voulons tester le plus petit possible. Donc, nous essayons de tester ces modules individuels ici, et la raison pour laquelle nous le faisons est parce que si nous contestons tous ces éléments sur dire qu'ils fonctionnent exactement comme nous voulons qu'ils fonctionnent. Eh bien, en fin de compte, on peut dire que tout devrait fonctionner. Comment nous voulons que ce soit Maintenant, bien sûr, cela dépend de si notre architecture logicielle est bonne, parce que même si tous les modules fonctionnent, si notre architecture dans son ensemble était mauvaise, alors ils vont toujours pour être des bogues, et c'est là que nous entrons dans quelque chose comme l'intégration, tests ou les tests d'architecture. Mais le premier 1 dont nous parlons est cette idée de test unitaire, et ce que nous faisons avec les tests unitaires, c'est encore une fois que nous essayons d'isoler. Donc, si nous testons cela, disons que nous avons un module ici, ici, ici. Si on teste celui-ci ici et qu'ils communiquent tous comme si bien, que se passe-t-il s'il y a un bug ici ? Il pourrait se propager dans ce module, et nous ne voulons pas cela. Donc, avec les tests unitaires, nous essayons d'isoler. Donc nous allons faire, c'est que nous allons construire des valeurs fondamentalement fictives et toutes ces valeurs fictives que nous savons fonctionner correctement et que nous savons fonctionnent parfaitement. Donc, il va mettre ces inbred. Donc, au lieu de simplement avoir ce module ici intégré dans tout le reste, ce que nous faisons est juste de mettre le module dans un environnement isolé, et nous devons en fait créer des cas de test. Nous devons créer une intégration qui fonctionne parfaitement bien. Peut-être que ce n'est pas aussi intelligent, mais il fait exactement ce dont cette chose a besoin et de cela à partir de la construction de ces idées, ces pilotes aériens et Stubbs et nous allons parler de ces tests plus progressifs. Mais cela nous permettra d'isoler cela. Et une fois qu'on glace comme ça, on peut le tester sans faille. Une fois que nous savons que ça marche, nous passons à la suivante. Donc, nous passons à peut-être, par exemple, celui-là. Donc nous, vous savez, en fait, testons celui-ci, et puis celui-ci sera créé comme un talon ou avec des tests incrémentiels. Peut-être qu'on garde celle-là parce qu'on sait que ça marche. Donc c'est bien à utiliser à partir de maintenant, mais de toute façon, ça prend un peu d'avance sur mais de toute façon, nous-mêmes. Tout ce que nous avons besoin de ne pas savoir, c'est que l'idée d'un test unitaire est de tester la plus petite partie possible du logiciel. Nous essayons d'isoler ce logiciel. Nous ne voulons pas tester accidentellement un sous-système ou un module entier. Nous devons nous assurer qu'il est isolé pour ne pas avoir ces bugs en cascade que nous pensons être potentiellement ici. Isolement. Il est important 41. Tests d'intégration: Nous avons donc parlé d'unités et de tests unitaires, mais le niveau suivant est cette idée de tests d'intégration. Donc, avec les tests unitaires, nous testions les très petits modules, les plus petits logiciels, et peut-être nous travaillons à 100% d'entre eux. Nous avons travaillé à 100% de tous les modules, et ils fonctionnent tous. Cependant, cela ne signifie pas que nous sommes absents de bugs parce que le programme aurait pu être mal construit . La communication pourrait toujours ne pas fonctionner correctement. Il pourrait y avoir, par exemple, peut-être qu'il y a 100 modules ici. Et peut-être qu'il y a 50 modules ici. Et ces deux sous-systèmes ont parlé à quelque chose qui a 60 modules et ainsi de suite et ainsi de suite. Et peut-être que quand tous ces air communiquent dans cette grande architecture avec les bases de données ici et peut-être avec un front dans le serveur ou quelque chose par ici, il y a encore des bugs qui se posent. Et donc avec ça, nous devons réellement les combiner. Nous avons tout testé isolément, ça marche toujours bien isolé. Mais maintenant, nous devons commencer à les combiner ensemble dans cette idée d'intégration, de test et avec les tests d'intégration, nous commençons en fait à faire ce genre d'incrémental ou non incrémental. Donc, nous allons parler de l'incrémental dans la prochaine conférence, parce que c'est en fait un peu plus difficile. Cette idée de non-incrémentielle est juste une sorte de force brute qui teste le tout. Alors quoi ? Pas incrémentielle. Peut-être que nous avons encore une fois que ce genre de gros modules de sous-système comme celui-ci et peut-être comme un gros contrôleur, quelque chose de classe qui les appelle dans ces appels petits et ainsi de suite. C' est un peu une architecture compliquée, avec des tests d'intégration non incrémentiels. On teste juste tout ça. Nous venons de passer des tests géants, et c'est en fait le test le plus courant que les gens dio est. Chaque fois que nous construisons notre produit, nous testons simplement l'ensemble du produit. On voit ce qui ne va pas dans tout ça. Donc, pour construire une application, nous ne testons pas. Les pages individuelles ne faisaient que tester le tout dans son ensemble. Donc, nous avons téléchargé sur notre téléphone et nous avons juste parcouru et faisons des cas d'utilisation courants. Nous faisons des choses courantes sur l'application, et nous voyons faire ces choses communes casser n'importe quoi à ces choses communes. Y a-t-il quelque chose que je peux faire pour le casser ? Et encore une fois, c'est comme ce test d'intégration non incrémentielle que nous faisons. On teste l'ensemble du programme dans son ensemble. Cependant, cela ne nous montre généralement pas certains des domaines parce que peut-être nous faisons quelque chose et nous obtenons une erreur comme celle-ci. Ce module ici. Eh bien, comment pouvons-nous savoir que ça n'a pas été propagé par ça et par l'air ici et peut-être une époque qui se propage à une erreur ici et encore ? Cela se produirait si nous avons, comme, couplage serré sont faible cohésion. Mais quand même, ces choses arrivent. Et donc si nous faisons tout ce test d'intégration, bien sûr, avec cela maintenant, nous pouvons en fait, nous avons un peu d'avantage. Nous avons un bug, nous pouvons identifier le bug. Cependant, il est beaucoup plus difficile de réparer le mais parce que tout ce que nous avons est l'inverse. Tout ce que nous avons est le fondamentalement par défaut ce qui s'est réellement passé ici. Mais ce dont nous avons besoin, c'est de tester où c'est arrivé. Et c'est là que ce genre de tests incrémentiels entrera en jeu. Il nous permet de construire les uns sur les autres et ensuite c o. Chaque fois que nous ajoutons ce module, nous commençons à obtenir des erreurs ici ou nous commençons à obtenir des erreurs. Vous savez, ici d'un air en bas, ça permet de le localiser un peu mieux. Donc la prochaine conférence parlera de ça, qui sera le test incrémentiel. 42. 6-6 Tests par 6-6: passons en revue la première idée de tester, et ce sera cette idée de tests incrémentiels. Donc, les tests incrémentiels sont des tests. Lorsque vous créez un module, vous faites des tests, vous créez un autre module, vous faites d'autres tests, et ce mot create est utilisé de manière lâche. Donc affaiblir Faire des tests de deux façons différentes et nous en parlerons un peu plus. Nous arrivons aux modèles de logiciels, et c'est que nous pouvons soit construire un module, puis tester la construction, puis tester. Ou peut-être qu'on peut construire tout le système. Et puis avec ce test, nous saisissons un module que de test saisir un module puis tester. Donc, quand je dis créer, je veux dire que nous le construisons à partir de zéro ou que nous le retirions du programme que nous avons déjà développé, et nous les testons un peu à la fois. Alors, quel est le modèle incrémental ? Ce que nous avons, c'est que nous avons ces étapes. Donc, par exemple, nous pourrions attraper un module, peut-être le module de premier niveau, le module de démarrage, et ensuite ce que nous faisons est de le tester, voir si ça marche, voir si ça marche, comment nous voulons que cela fonctionne, voir s'il fait ce qu'il doit faire. Si c'est le cas , nous passons à l'étape suivante. Peut-être qu'il se connecte dans ces deux domaines. Donc, nous ajoutons un autre wa jal et un autre module et ensuite faire quelques tests supplémentaires, assurez-vous que tous ces air travaillant ensemble correctement ajouté un autre module. Peut-être qu'il y en a un ici qui communique comme ça. Alors on va tester ça et affaiblir, genre, juste faire des petites, euh, petites coches pour dire où on était. Donc on peut dire ici, ici et ici. Donc, quand nous faisons deux autres tests maintenant, nous avons vérifié ici et ici et ainsi de suite et ainsi de suite jusqu'à ce que nous ayons testé l'ensemble du programme et vous pouvez voir que c'est en fait une façon assez décente de le faire juste parce que nous le testons dans de cette façon, nous ajoutons lentement de plus en plus de fonctionnalités et testons. Le problème avec ceci est que c'est très difficile à accomplir correctement parce que peut-être votre logiciel n'a pas été construit, donc c'est complètement et totalement modulaire. Peut-être qu'il y a un peu trop de couplage dedans. Peut-être qu'il n'y a pas assez de cohésion. Et donc, quoi que vous incrémentez un pas, c'est peut-être comme si vous commenciez avec 10%, puis vous incrémentez une étape et c'est soudainement , vous savez, 40% du code et une étape de plus. Et maintenant, vous êtes à, genre, 95% du code et cela arrive beaucoup, c'est pourquoi ce n'est parfois pas aussi pratique, mais c'est très important cette idée. Une autre lacune de ceci est, par exemple, si nous voulions juste tester la relation entre ces deux unités avant que nous en arrivions ici, ce que nous avons c'est que nous testons l'ensemble du système. Plus ça. Donc, dans cette situation, nous pourrions même devoir ajouter une autre étape où nous faisons les tests incrémentiels. Et puis nous faisons comme un peu d'un test unitaire ici où nous testons juste une zone spécifique pour voir si chacun de ces fonctionne et que si cela fonctionne et si cela fonctionne donc c'est comme une tonne de différentes façons de le faire, et c'est pourquoi cela rend les choses un peu difficiles. Maintenant. Quelques idées différentes pour faire une sorte de test incrémentiel est cette idée de test de haut en bas. Donc, avec les tests de haut en bas, ce que nous avons c'est que nous avons l'idée de tester fondamentalement le niveau supérieur, puis nous descendons après chaque niveau supérieur terminé, et nous allons avoir besoin d'une nouvelle terminologie d'apprentissage ici. Et c'est cette idée d'un talon. Et le stub est un modèle du modèle qui sera implémenté, généralement renvoyé les valeurs codées en dur. Alors, qu'est-ce qu'on veut dire par là ? Disons que nous testons ce module ici et dirons que c'est, par exemple, le niveau un. Donc, nous testons le module le plus haut maintenant. Le truc, c'est que nous ne testons rien en dessous de ça. Nous essayons juste de tester ce module. Par conséquent, ce que nous créons, ce sont ces idées de Stubbs ici. Donc cette prochaine couche va être un truc. Tout en rouge sera un talon ici, et ce qu'un talon fait, c'est juste un modèle du modèle qui sera implémenté. Donc, au lieu d'avoir toutes ces méthodes qui sont entièrement réalisées, nous pourrions avoir la possibilité d'appeler la fonction. Donc c'est là que vous avez besoin de planification aussi, parce que vous allez devoir savoir exactement quelle méthode appelle. Quelles fonctions ? Quels sous-systèmes sont essentiellement enchevêtrés dans chacun de ces petits sous-composants. Donc, par exemple, par ici, peut-être que c'est, Ah, Ah, horloge ou quelque chose comme ça. Donc on peut avoir un get notre Peut-être qu'on aura une minute get. Peut-être qu'on aura même, genre, genre, je ne sais pas, peut-être, peut-être, comme ce qu'il y a demain ? Prends demain. Ajoute juste un peu d'y arriver, arrive demain. Peut-être que nous avons toutes ces fonctions, mais nous n'avons pas encore implémenté dans elles à l'époque, mais nous voulons voir si elles vont travailler en relation avec cela. Donc, ce que nous faisons, c'est que nous créons ceci essentiellement ce talon où nous ne remplissons pas réellement aucun du code en dessous. Nous créons tous les appels de méthode, mais nous n'en implémentons pas. La méthode appelle. Tout ce que nous faisons, c'est que nous retournons des valeurs codées en dur ou quelque chose qui, vous savez, fait en sorte que nous sachions qu'il appelait réellement cette fonction et, vous savez, quelque chose comme ça. Il pourrait être juste comme une console pensait Lawgiver travaillant dans quelque chose comme JavaScript où nous pouvons dire demain qu'il retournera juste une date aléatoire là-dedans. De cette façon, nous savons si elle renvoie cette date exacte, nous y avons accédé et nous avons obtenu les informations correctement et cela aide parce que peut-être cela appelle ici, puis il rappelle et nous faisons quelque chose avec les données. Nous devons donc nous assurer que c'est ce flux de contrôle qui fonctionne. Nous devons nous assurer que si nous appelons notre méthode ici, elle descend, elle saisit la bonne méthode, puis elle revient et tout se passe bien. Et c'est pour ça que tu as besoin de ces talons. Et encore une fois, cela peut être un moyen de développer ou un moyen de tester. Donc peut-être qu'avec notre développement, nous faisons une sorte de développement de haut en bas aussi. Donc, nous construisons le niveau un, puis les talons qui se connectent à elle. Et puis après cela est terminé, alors nous construisons réellement chacun de ces talons. Nous les implémentons, puis nous créons une nouvelle couche de stubs que nous devons utiliser. Donc tu sais, plus de Stubbs ici. Et cela est également utile si, par exemple, nous avons une base de données que nous essayons que nous allons utiliser mais les bases de données et implémentée encore afin que nous puissions réellement créer ce stub qui au lieu d'appeler la base de données au lieu de l' appelant, il retourne juste à nouveau ce journal de concert. Donc peut-être que nous disons quelque chose comme Get user Donc, nous essayons une commande get user et généralement ce serait l'utilisateur sera stocké dans la base de données. Mais dans cette situation, tout ce que nous faisons, c'est que nous retournons des informations utilisateur, de fausses informations utilisateur et les affaiblissons sans réellement développer notre base de données de temps temps. Bien sûr, quand nous arrivons au point de développer la base de données qui va réellement implémenter cela et nous continuerons à partir de là, vous pouvez voir qu'il y a un peu d'organisation sympa ici. Il y a, ah, flux. Nous avons ces objectifs que nous pouvons atteindre. Nous commençons au niveau 1. Ensuite, nous sommes passés au niveau 2. Ensuite, nous sommes passés au niveau 3 et nous continuons et ainsi de suite, et ainsi de suite au niveau juste là. Et c'est essentiellement la façon dont nous faisons des tests de haut en bas. Donc nous avons commencé le haut et nous continuons à avancer vers le bas L'autre façon que nous pourrions faire est cette idée de tests ascendants, qui est fondamentalement l'inverse ici et ce dont nous avons besoin pour cela c'était. On a besoin de chauffeurs. Alors rappelez-vous, ici, nous avions déjà ce module ici, qui appelle la commande. Il a les variables initialisées. Il a tout ce dont nous avons besoin pour que ceux-ci fonctionnent ici parce que le flux de contrôle de haut en bas va de haut en bas. Donc, il passe dans certaines variables, en passant certaines informations. Cela s'exécute ensuite, et puis il revient. Et c'est contrôler ce flux d'exécution Eh bien, avec des tests ascendants, comment pouvons-nous tester, par exemple ? Disons que nous avons ces trois derniers ici. Comment on les teste ? Si nous voulions commencer par le bas et peut-être que nous voulons commencer par le bas parce que, par exemple, peut-être que le haut est comme le serveur, et peut-être que le bas est comme l'extrémité frontale, et nous voulons nous assurer que le front terminer le travail avant que nous atteignions réellement les serveurs. Donc, dans cette situation, nous devons commencer par le bas, voulez-vous travailler notre chemin vers le haut. Donc, ce que nous faisons c'est nous testons ces modules et nous avons en fait ces choses ici appelées pilotes. Donc, nous créons un pilote qui est essentiellement la même chose qu'un talon sauf juste le côté opposé de la pièce Ici, au lieu d'être un modèle qui a des contrôles de modèle, un modèle qui a, vous savez, fonctions à mon retour. Il s'agit d'un modèle qui a des contrôles d'exécution. Donc, ici, nous pourrions avoir des fonctions qui vont faire qui ne sont pas entièrement implémentées. Mais ça appelle les bonnes autres fonctions ici. Donc on pourrait avoir, tu sais, un temps d'arrivée ici. Et ce que cela va faire, c'est qu'il va faire les appels appropriés. Peut-être encore ça. C' est la même horloge ici. Donc, le temps de get va appeler, par exemple, disons qu'il va passer un appel pour obtenir notre et ensuite obtenir une minute et peut-être quelques autres choses, et ensuite il est censé les combiner dans le peut-être revenir encore plus loin. Mais dans cette situation, nous avons maintenant ce pilote et test d'affaiblissement si les commandes entrant retournent correctement. Et donc ce que nous faisons c'est que nous créons ce petit pilote ferait en sorte que toutes les variables ici, nos A initiaux, peut-être qu'il a besoin du passé. Dans le fuseau horaire, peut-être le fuseau horaire ou quelque chose comme ça. Il doit le passer. Donc, nous allons de l'avant et nous créons une variable appelée Fuseau horaire et nous l'initialisons à juste quelque chose. Allons donc avec l'heure normale de l'Est, qui est généralement un E T précédent est son heure normale de l'Est des États-Unis. Donc, nous définissons le fuseau horaire. Bien sûr, si c'était un vrai programme, ce serait peut-être appeler une base de données pour voir ce qu'est l'utilisateur ou quelque chose. Mais dans cette situation, nous ne faisons que créer un chauffeur. Donc, nous codons en dur toutes les variables, nous codons en dur certaines des méthodes ici. Et puis maintenant, nous pouvons tester pour voir si quand les appels arrivent, faites les données appropriées vous obtenez Ne revenez pas ici. Et là où nous avons codé en dur le hors-la-loi du concert , demain est un moment peut-être pas. Peut-être que nous disons que c'est comme le 19 février 2012 ou quelque chose où nous avons réellement coupé dur dans celui-ci parce que nous testons le module, le fond, et il va retourner le réel get notre et le réel get minute et le réel get get Demain. Ça fera ces choses, donc tout ce qu'on a à faire, c'est qu'on ait quelque chose à appeler pour vérifier, pour s'assurer que ces choses fonctionnent. Et puis, bien sûr, une fois que nous avons fini, nous allons de l'avant et nous avons réellement initialisé cela et nous continuons à avancer dans la chaîne jusqu'à ce que nous ayons tout testé. Et c'est donc vraiment des tests incrémentiels. En un mot, c'est Cette idée de commencer quelque part n'a pas d'importance si son sommet inférieur il y a d'autres moyens d'accord et puis juste passer à la suivante. Une fois que nous avons fini, passer aux hormones suivantes ont été faites. Continuez à les désactiver, puis gardez incrémentiel jusqu'à ce que vous ayez testé chaque module du programme. 43. 6-7 Test de dos à l'dos: une autre façon de tester est cette idée de test dos à dos. Donc, c'est quelque chose que vous faites une fois le programme construit ou cela pourrait faire partie de cette idée de tests incrémentiels. Donc nous construisons une section et ensuite nous faisons une autre section et dans aucune section uniquement incrémentielle l'une de l'autre et dire quoi ? Encore des tests ? Ce n'est pas forcément une construction. Ça pourrait l'être. Nous testons une section et nous allons orteil Ah, plus grande section une plus grande section. Mais avec cette idée de tests dos à dos, ce que nous faisons ici, c'est que nous comparons un bien connu à une nouvelle version. Donc, ce que cela signifie, c'est, disons que nous avons un programme ici ou que nous avons des commentaires en haut de la page. Nous avons donc cette entrée dans notre programme, et sur le côté gauche est la version 1. C' est la version qui était avant que nous ayons apporté des modifications. Donc, nous exécutons l'entrée dans le jeu 1, puis nous obtenons en sortie. Donc, nous avons une sorte de sortie juste ici. Maintenant, nous pouvons comparer cela à un oracle ou une façon de voir si c'est bon ou non, et nous assurer que c'est correct. Une fois que nous savons que toute la sortie de ceci est OK, alors nous pouvons faire retour à dos de test parce que maintenant ce que nous dio est nous avons réellement créé une nouvelle version. Alors on y va, peut-être qu'on ajoute de nouvelles choses. Peut-être qu'on développe une nouvelle partie de ce logiciel. Eh bien, une fois que nous avons fait ça, nous avons une version 2. Et donc ce que nous faisons est que nous prenons cette même entrée ici, le même ensemble de nombres ou de séquences ou de personnages ou d'actions, et nous mettons cela dans le jeu et obtenons exactement la même sortie ici. Donc nous allons voir maintenant, disons, le côté gauche, le côté gauche, nous allons avoir une sortie sous, comme 2357 et le côté droit aura 2357 et ce n'est pas le cas. Ce que nous faisons, c'est que nous faisons ce qu'on appelle un rapport de différence ou que nous examinons simplement les différences. Donc on voit, est-ce que tout correspond ? Et si tout correspond que nous savons que le programme fonctionne toujours, nous savons que cette nouvelle chose n'a pas cassé de vieilles choses. Ce n'est pas pour tester de nouvelles fonctionnalités. Donc, nous allons encore devoir tester une toute autre partie de nouvelles fonctionnalités, une nouvelle fonction, sortie. Et on va devoir comparer quelque chose d'un nouvel oracle pour le tester. Mais avec les vieux trucs, nous avons maintenant cette façon de nous assurer que nous ne cassions pas les choses alors que nous bombardions ajoutons de nouvelles choses. Donc avec ça, nous pourrions vraiment faire ça, cette chose où nous comparons l'ancien et puis peut-être nous avons une version trois. Donc, quand nous avons la troisième version ici, nous mettons l'entrée là-dedans, et cela se compare à la sortie de la nouvelle fonction. Donc, nous connaissons la version pour régler cela. Mettez maintenant, nous savons que la version trois fonctionne avec cela. On pourrait même le comparer à cela aussi. Faites les mêmes tests et nous pouvons continuer à aller de plus en plus loin, et cela nous permet de gagner un peu de temps parce que encore une fois, nous n'avons pas à refaire tous ces tests. Nous devons juste exécuter exactement la même entrée et nous assurer que tout est toujours le même parce que nous avons déjà vérifié que cela correspond à l'oracle. Nous avons donc déjà vérifié que c'est bon. Donc, cela signifie que cela de ce côté-ci devrait être bon aussi. Et bien sûr, si vous avez une différence ici. Donc, disons, par exemple, au lieu d'un sept ici, nous obtenons quelque chose comme, je ne sais pas, dans huit avec cette situation allaient alors avoir fondamentalement cette situation où nous pouvons voir maintenant quels tests ont échoué. Donc, ici, on peut. Maintenant, changeons la couleur ici. Et peut-être qu'on avait raison d'avoir un petit programme pour nous le dire. Mais il va y avoir un rayon X ici. Nous savons que ce dernier test a échoué. Donc maintenant, nous savons qu'il y a eu un changement avec jamais, quel que soit ce test. Donc, par exemple, si c'est, vous savez, calculer un certain ou peut-être c'est combien de parties comme combien de choses finissent dans un tableau ou certaines dans le résultat ici. On sait qu'entre tout ça, ça marche bien. Mais cette zone spécifique est en rupture, donc nous pourrions aller dans notre code et le réparer et essayer de remettre cela en ligne. Mais les tests dos à dos est un excellent test itératif qui vous permet de gagner du temps et comparer rapidement pour vous assurer que vous ne cassez pas de vieilles choses avec vos nouvelles choses 44. 6-8 qui doivent tester: Chaque fois que nous parlons de tests, nous avons souvent besoin de comprendre qui devrait le tester. Si nous venons sur le plan de test, nous devons comprendre quel groupe de personnes devrait tester notre logiciel. Donc, le 1er 1 est le développeur eux-mêmes. Donc le développeur est, vous savez, celui qui a construit le système. Ils comprennent le système, ils peuvent faire ces tests techniques. Et ce que je veux dire par là, c'est qu'ils comprennent. Par exemple, s'il y a un module ici qui communique avec un module là-bas, ils comprennent, tout d' abord, qu'il s'agit de deux modules distincts. Ils comprennent que protéger. Peut-être en particulier, il y a un tableau ici et comme une liste liée ici. Et ce ne sont que quelques termes techniques. Ils comprennent la mise en œuvre. Donc, ils pourraient essayer de faire des tests qui cassent spécifiquement ces implémentations où un utilisateur normal pourrait simplement taper des choses là-dedans, essayant de, vous savez, type de choses vraiment longues dans ou taper des choses vraiment courtes dans le numéro, lettres ou quelque chose du genre pour briser leur mise en œuvre spécifique afin qu'ils puissent faire ce genre de tests techniques. Maintenant, l'inconvénient est qu'ils peuvent traiter les tests à la légère. C' est en quelque sorte leur bébé. C' est ce qu'ils ont développé. C' est ce qu'ils ont passé beaucoup de temps à créer, donc ils ne veulent pas que ce soit mauvais. Ils ne veulent pas que ça soit mauvais. Les données elles-mêmes ne veulent pas que les orteils soient mauvais. Donc, le développeur lui-même va probablement le tester un peu plus léger que les gens pourraient. Tu sais, d'autres pourraient vouloir qu'ils le testent. Et les développeurs sont motivés par différentes choses. Ils sont motivés par un beau respect des échéances et la construction du développeur de logiciels eux-mêmes ne vont pas essayer de continuer à venir avec des bugs. S' ils ont une date limite imminente, ils veulent juste la repousser et dire, Hey, j'ai fini. Et donc leur motivation à nouveau fait de lui pas les meilleurs testeurs du monde. Maintenant, ils connaissent le code qui cause les problèmes. Donc, s'ils trouvent des bogues, ils sont beaucoup plus susceptibles de les corriger en temps opportun que si vous avez ces deux. Parce qu'ils vont devoir essentiellement écrire des rapports de bogue et passer par toutes les étapes pour y arriver, puis le développeur devra passer par ce rapport de bogue et ils devront trouver le code qui crée le bogue. Mais ici, ils voient le bug qui comme Oh, ouais, c' est probablement dans ce fichier qui fait ça. L' étape suivante ou la couche suivante est le testeur. Un testeur est un professionnel, un professionnel qui est spécifiquement formé aux programmes de rupture. Donc ce qu'ils vont faire, c'est qu'ils vont apprendre le système, ce qui est encore une fois un avantage, parce qu'ils l'apprennent, ils pourraient être confondus dans certains domaines, ce qui aidera en général la qualité. Peut-être que quelque chose doit être raffiné, et peut-être que cela signifie être un peu meilleur. Mais ils vont essayer d'apprendre le système, et ensuite ils vont essayer de tout tester. Ils ne vont pas tester des choses techniques. Ils vont tester autant qu'ils peuvent, et ils vont essayer de briser le programme à tout prix. Le testeur est motivé légèrement différemment. Ils sont motivés par des qualités avec peut-être que celle-ci est la date limite ou peut-être même l'ego ou, vous savez, habileté. Ils sont motivés en essayant de créer de très bons programmes, mais pas entièrement sur la qualité qu'ils pourraient être. Vous savez bien la date limite imminente et essayez de le pousser bien, Le testeur ici est complètement motivé sur la qualité. Ce qu'ils veulent faire, c'est qu'ils veulent s'assurer qu'il n'y a pas de bogues, car si vous transmettez un logiciel sur le testeur, le testeur est maintenant responsable. S' il y a des bogues, le développeur l'a développé. Ils font le Dev initial. Mais ce gars est l'importation est prêt pour la qualité, donc il est tenu responsable de la qualité. S' il y a un bug, il revient à lui ou elle, et donc ils vont essayer de tout casser. Ils veulent trouver chaque bogue dans ce programme, sorte que quand il est poussé, il n'y a pas beaucoup de bogues du tout, et ils auront l'air un peu mieux, et ils seront fondamentalement bien dans leur travail. Donc, le testeur est très important ainsi qu'un développeur, et enfin, beaucoup d'entreprises vont réellement l'utiliser. De nos jours, ils sortiront une version bêta ou une version démo, et ils la publieront au public pour un test utilisateur. Donc test utilisateur est beaucoup de fois que vous verrez des jeux faire cela Peut-être, comme ils ont, comme, comme, week-end bêta ou quelque chose comme ça. Ils sont en train de tester. Les serveurs testent le gameplay. Ils s'assurent que tout est optimisé. Et la meilleure façon de le faire est de le distribuer à un million de personnes et de voir comment les gens l'utilisent-ils ? Quelle configuration du matériel sur leur ordinateur le casse ? Quoi ? Tu sais, qu'est-ce qu'ils font que nous n'avions pas prévu ? C' est donc très important aussi. Et encore une fois, ils doivent apprendre le système Azad passer par, qui encore une fois, est à peu près un avantage qu'ils Mais ils savent comment ils vont utiliser le système. Donc, l'utilisateur utilise le système. C' est pour ça que tout le système a été conçu pour qu'un utilisateur l'utilise afin qu'il sache comment ça va fonctionner. Et ils vont essayer de l'utiliser. Ils ne vont pas essayer de le casser ou d'y aller très dur. Ils vont essayer de l'utiliser. Et si ça casse, alors ils vont publier un rapport de bug. La mauvaise fin est que l'utilisateur n'est pas vraiment motivé par le signalement d'un bug, donc ils sont simplement motivés par l'utilisation du logiciel. Donc, en utilisant le logiciel et si nous créons un par exemple. Ah, logiciel pour une entreprise. Bien sûr, ils vont probablement signaler les bugs parce qu'ils veulent le meilleur logiciel possible. Mais si nous créons, comme, un logiciel commercialisable, donc vous savez, un Microsoft Word ou un jeu vidéo ou une application en ligne ? Beaucoup de fois, l'utilisateur ne va pas signaler la source des bogues. Ils ne vont pas aller aux marches. Le, vous savez, 15 20 minutes qu'il pourrait prendre pour écrire un vrai, vraiment bon rapport de bug. Et à cause de cela, nous ne recevrons pas beaucoup de rapports de bogues de leur part. Donc on va devoir faire un peu, comme conservation anonyme de données ou autre chose pour obtenir des informations. Donc, même si c'est un très bon vecteur de test, c'est très difficile pour nous d'obtenir des informations utilisables. Donc, chaque fois que nous créons notre plan, nous devons comprendre tout cela. Nous ne comprenons pas les motivations derrière chacune d'elles. Nous devons comprendre où nous allons obtenir le plus de qualité pour le plus grand nombre de temps que nous avons passé. Et nous avons juste besoin de comprendre que différents testeurs nous allons le tester différemment, et ils vont trouver des bogues différemment, et comprendre tout cela à nouveau ensemble nous aidera à créer un meilleur plan de test. 45. Tests automatiques et manuels: notre prochain domaine de stratégies de mise à l'essai que nous voulons examiner est son idée et cette distinction entre les tests manuels et automatiques. Et quelle est l'importance de l'une ou l'autre ? Pourquoi utiliserons-nous soit si le test manuel est juste que c'est fait manuellement. Donc, si j'ai , par exemple, besoin, par exemple,de tester un morceau de code, nous avons ce morceau de code, et j'ai besoin de voir si cela fonctionne sur différents navigateurs Web. Eh bien, tout ce que je fais c'est que je vais littéralement, et je l'ai ouvert dans chaque navigateur Web, et je le vérifie visuellement pour voir si ça a l'air bien. Si c'est le cas, alors je coche de chaque côté, puis je le mets dans une sorte de rapport et je l'envoie à celui qui a besoin d'orteils avoir ce rapport, celui qui a besoin de le signer ou de dire ça, oui, ces choses fonctionnent, et c'est des tests manuels, et vous verrez qu'il y a quelque chose de facile dans ce sens que nous n' avons pas à concevoir quoi que ce soit pour cela. On le fait juste. Donc, nous avons juste compris ce qui doit être fait, et nous le faisons immédiatement. Donc il n'y a pas de frais généraux à ça. Cependant, si nous avions besoin de tester un serveur pour 15 millions d'appels de serveur en même temps, disons que le serveur était garanti à 15 millions d'appels de serveur. Comment pouvons-nous savoir si ces 15 millions fonctionneront ou ne fonctionneront pas ? Ça va être assez difficile pour nous de dio manuellement. Et peut-être que nous ferons quelque chose comme un test bêta où nous permettons réellement aux vrais utilisateurs de l'utiliser . C' est une façon intelligente de le faire. Mais une façon encore plus intelligente de le faire est de le tester automatiquement, ou les utilisateurs n'ont pas besoin d'être les cas de test et de le tester automatiquement. Ça prend du temps et ça demande des efforts, et on se retrouve en quelque sorte comme ce graphique qui se passe ici. C' est donc l'effort requis dans la phase de test. Donc, c'est un peu comme ce graphique exponentiel inverse ici, et c'est l'effort requis dans la phase de développement pour les tests. Donc, ce que cela signifie, c'est dire que si nous ne passons pas du tout du temps dans le visage de développement traité , donc le rouge est Dev ou ah, faisons la terminologie. Nous avons utilisé la phase de mise en œuvre et leur mise en œuvre, puis nous dirons noir . Voici la phase de test. Donc, si nous ne passons pas du tout du temps dans le développement, vous remarquerez qu'il y a un temps extrêmement élevé que nous allons passer dans la phase de test où si nous passons juste un peu de temps à planifier et à développer des tests et vraiment divin le logiciel de test parce que si nous faisons des tests automatiques, cela signifie que nous devons réellement concevoir plus de logiciels. Et nous allons tester ce logiciel aussi. Les subventions viennent avec des documents de conception. va falloir trouver des moyens pour que ça marche et de l'architecture et des trucs comme ça . Mais si nous passons ce temps dans la phase de mise en œuvre et la phase de conception et tout ce qui est nécessaire pour obtenir ce travail de remorquage, nous pouvons réduire le temps de test de beaucoup. Il s'agit donc de la phase de test, et le problème est beaucoup d'entreprises ne passeront pas le temps de développer le logiciel avant d'entrer dans la phase de test. Et cela signifie que pendant que nous développons le logiciel, nous ne pensons même pas aux tests, et ensuite nous devons retourner en arrière, briser le logiciel à nouveau, et trouver comment mettre des cas de test appropriés. Où si nous avions juste mis des cas de test pendant que nous travaillions, nous aurions économisé beaucoup de temps plus tard. Et ce qui est est généralement finissent par créer. Quoi qu'on arrive à la phase de test et qu'on l'ait déjà fait, on n'a pas passé de temps à le faire. Quoi qu'on arrive à la phase de test et qu'on l'ait déjà fait, Et nous examinons cette quantité de temps pour mettre en œuvre un logiciel de test approprié. Eh bien, ce que nous dions, c'est qu'on saute la phase de test ou on fait un très petit ensemble de tests manuels et dit, oui air bien et on pousse le logiciel et ça arrive plus souvent qu'autrement. C' est donc l'une des plus grandes pannes dans le processus de développement de logiciels n'est pas développement de logiciels de test appropriés tout au long du processus. Si vous pouvez voir tout ce que nous avons besoin de dio et développé juste un peu de tests pendant que nous travaillons et tout au long du processus de mise en œuvre, et nous pouvons réellement nous économiser beaucoup de temps. Et bien sûr, c'est un graphique exact. Mais si je regardais cela comme un graphique exact, je regarderais et je dirais, , pourquoi ne pas chercher à se développer ici parce que cela va nous donner le minimum d'efforts et nous donner les meilleures chances. Tu sais, ce parcours de graphique ne s'arrêterait pas ici. Je ferais probablement quelque chose comme ça où il descend juste. Au fil du temps, nous pourrions supprimer cette ligne juste là, mais oui, ensemble, bien que vous puissiez voir le point ici est que nous cherchions cette idée de ce que nous ne voulons pas passer tout ce temps supplémentaire dans mise en œuvre. Cela ne nous apportera pas beaucoup d'avantages plus tard, mais là, il est très important d'au moins passer ce temps dans la phase de mise en œuvre , car cela nous permettra d'économiser de l'argent et cela augmentera notre qualité au fil du temps. Donc, l'idée de tests manuels vs automatiques est importante ici et hors-la-loi. Je vais vraiment forer à la maison. Comment ces se connectent est que beaucoup de fois les tests automatiques sont effectués dans le visage de mise en œuvre parce que nous devons concevoir des logiciels pour il est sur la conception de tests automatiques . On doit passer ce temps à l'avance. Ça va avoir beaucoup de coûts initiaux. Donc, avec les tests manuels, c'est rapide. Ça va être tout de suite. On pourrait juste sauter et le faire. n'y a pas de planification nécessaire avec les tests automatiques, cependant. Il y a tout un tas de planification à l'avance. Nous devons développer différents logiciels avec le passage à travers elle. Nous devons le vérifier et ensuite nous pouvons réellement l'utiliser. Et cela prend le coût initial du temps d'avance. Cependant, à long terme, cela nous fait gagner du temps. Donc, comprendre la distinction entre ceux et comprendre qu'il est important de créer un logiciel, euh, ou de créer un logiciel de test est quelque chose qui est important lorsque vous créez votre stratégie. 46. Tests de boîte noire et blanche: avec des tests. Il y a aussi cette idée de test de boîte noire et de boîte blanche. Et donc, avec cette conférence, je suis ça va être un point de vue supérieur de tout ça. Cela devient très technique très rapide chaque fois que vous parlez de ces choses, en particulier avec les tests de boîte noire, parce que vous allez en fait dans une sorte de preuves mathématiques et vous devez comprendre des choses comme les machines d'état et provoquer des effets, graphique et essentiellement la nomenclature mathématique et des trucs comme ça. Et c'est là que tu aimes un peu avec un diplôme d'informatique. Vous pourriez en fait comprendre certaines de ces choses ou si vous êtes vraiment dans Q A, vous en apprendrez plus à ce sujet, mais je veux juste passer un peu de haut en bas avec quelques mots peut-être si vous voulez rechercher des choses supplémentaires et encore juste vous exposer à elle. Donc la boîte noire qui teste ce que nous avons est que nous avons des entrées sur le côté gauche, donc nous le mettons dans, le mettons dans une boîte noire. Donc c'est une fonction que nous ne savons pas comment ça marche. Tout ce qu'on sait c'est que c'est censé faire quelque chose, et ensuite on obtient une sortie ici et avec boîte noire. Cela signifie encore une fois que nous ne comprenons pas l'intérieur de cela. Et ça, souvent, c'est ce que sont les testeurs, c'est qu'ils vont entrer et qu'ils ne comprennent pas la saleté de l'intérieur. Donc, il y a tests en boîte noire. Maintenant, il peut y avoir aussi des testeurs de boîte blanche. Ils vont juste passer du temps à apprendre les intérieurs du code. Et on va parler de ça. Ici, il y a des tests en boîte blanche, mais avec des tests en boîte noire, nous avons une entrée. Nous avons une sortie. Nous avons mis dans différents commentaires. Nous obtenons une sortie différente et nous vérifions juste pour voir que nous avons ceci à nouveau, cet oracle où nous avons cette entrée sur la gauche, vous savez, nous avons une sorte d'entrée, et il est censé donner une sortie différente sur le côté droit. Et donc ce que nous essayons de faire est de retourner voir, est-ce que ça marche ? Si on combinait différentes choses, ça marche toujours ? Nous avons donc des choses comme les valeurs limites, et c'est là que nous essayons d'entrer des plages hautes et basses. Et si ce passé est supposé, tout le reste passe. Donc, si on peut vous dire, 1 000 000 000 000 0 dans une équation ou 1 000 000 001. Nous supposons que tout entre un et un 1.000.000.000.000 fonctionne probablement aussi bien. Parce que quelle fonction ou quelle équation ne fonctionnerait-elle pas ? C' est ce cas de test très bizarre où les chiffres entre les deux ne fonctionneraient pas. Mais les bords fonctionnent. Donc, nous essayons ce genre de test de limites avec ceci où nous essayons de le briser essentiellement en allant dans des cas de coin. Quelle est la taille du nombre pouvons-nous entrer ? Quel est le nombre d'entrées Comey et cela fonctionne-t-il encore ? Effet de cause, graphique. C' est là que nous testons différentes causes pour nous assurer que différents effets se produisent. Et cela devient à nouveau très, très complexe ou fondamentalement comme créer ces graphiques de valeurs de cause à effet, et vous essayez de voir quel est l'effet final. Donc, vous essayez différentes causes qui sont juste l'entrée, et vous essayez de voir les mêmes effets similaires avec paire sage test est quand nous avons plusieurs paramètres en cours de test et nous essayons de vérifier toutes les conditions ici. Donc on a, tu sais, une forme ou quelque chose comme ça. Et il y a 28 façons différentes de dire oui et non et différentes valeurs et autres choses. Et donc nous essayons de tester en mettant ces paires différentes pour voir si la sortie est ce que nous attendions. La sortie, puis l'état test basé sur Bates vérifie l'entrée pour vérifier les changements d'état et les changements d'état est si nous connaissons les machines d'état. Nous sommes fondamentalement ces machines que le programme a ces différents états, et certains points changent fondamentalement l'état de la machine ici. Donc, par exemple, ah, ah, beaucoup de fois y est testé avec des zéros et des uns. Donc peut-être qu'un zéro va entendre Ah, un va ici, un zéro va ici et peut-être qu'il y a une boucle sur un ici et ainsi de suite. Et c'est juste une sorte de flux de contrôle ici de différents états. Donc, nous essayons de faire, nous essayons de tester pour nous assurer que notre machine d'état que nous dessinons est exacte ici. Que si nous mettons ces intrants et extrants ici, cela va nous amener d'un État à l'autre à l'autre à l'état trois à l'état quatre à l'état 586 ou peu importe que de nombreux États soient dans notre programme ici. C' est donc le test basé sur l'état avec des tests en boîte blanche. Ce que nous avons, c'est que nous avons la capacité de voir à l'intérieur. Nous connaissons le flux de contrôle, Nous connaissons les variables, nous connaissons toutes les données qu'il contient. Et nous vérifions cela dans ce test. Et donc avec Black Box testaient l'utilisation générale du programme ou de tester que si nous l'utilisons comme des utilisateurs normaux, il va fonctionner avec la boîte blanche. Nous testons un peu plus techniques. Nous nous assurons qu'il n'y a pas de fuite de mémoire pour s'assurer que les variables d'air utilisées correctement. Nous nous assurons que le flux de données est correct. Et avec les tests de boîte blanche, nous faisons pour les choses vraiment principales ici est que c'est l'idée de tester le flux de contrôle puis de flux de données. Test et le flux de contrôle est nous ensemble de cas de test, qui couvrent toutes les conditions de branche dans différentes instructions. Donc, si nous avons cette grande déclaration FL ou même sélectionner Blood dit que nous avons, ça commence ici et nous avons la déclaration NFL, et puis celui-ci a il est tombé déclarations, et cela va ici et puis il va comme ça va par ici et comme si c'est un peu difficile de tester tout ça. Donc, ce que nous essayons de faire est que nous allons probablement créer une solution automatique qui va basculer entre ces deux et essayer de tester chaque flux au moins une fois. Donc ça va tomber. Et il va essayer de tester et de s'assurer qu'il passe par chaque flux au moins une fois pour que tout ait été touché une fois. Et puis que nous savons que la sortie attendue est correcte sur chaque flux unique. C' est des tests de flux de contrôle, les tests de flux de données vont couvrir. Toutes les variables concevaient des cas de test pour couvrir les différentes déclarations de décès de variables et leurs utilisations pour s'assurer qu'à aucun moment une rupture de variable ne se produit. Ou, par exemple, si nous développons développé dans certains langages stricts de type où, par exemple, une variable doit être un entier Ah, beaucoup de fois, si nous ne touchons pas cela variable, alors un nouvel air ne s'affichera pas tant que nous ne le toucherons pas et que quelque chose ne va pas. Donc, par exemple, à un moment donné, si nous essayons de mettre une chaîne, ce qui est encore une fois un terme d'informatique pour juste comme un texte ici ? Donc, il est juste une chaîne de caractères ensemble une chaîne. Si nous essayons de mettre une chaîne dans leur, cela pourrait faire exploser tout le programme et tout va planter. Eh bien, si nous ne testons pas toutes les variables et nous assurons que tous les flux de contrôle et toutes les touches de ces variables ne le casse jamais, que nous ne connaissons pas ce bogue tant que quelqu'un ne le fera pas. Et il plante un programme et leur donne une mauvaise expérience utilisateur. C' est donc ce que nous faisons avec le flux de données. Le test est que nous connaissons les intérieurs. On va vérifier tous ces petits points de données et s'assurer qu'ils fonctionnent et sont réglés correctement. C' est donc une boîte noire et des tests de boîte blanche à nouveau. quelque sorte. C' était une vue de haut en bas juste pour vous faire comprendre une partie de la terminologie Si vous êtes plus intéressé par cela, certainement chercher plus d'informations en ligne et ce truc devient assez compliqué, mais c'est très intéressant 47. 6-11: Alors passons en revue certains des problèmes avec les tests ou ces air juste une sorte de choses à garder à l'esprit lorsque vous testez afin que vous ne passez pas de temps à annuler ou à stress sur la phase de test . Et le 1er 1 est que des tests exhaustifs sont impossibles. Ce que cela signifie, c'est que nous avons ici cette courbe de temps passé et de bugs que nous pourrions accomplir, et avec le temps cette courbe devient de moins en moins. Ce qui signifie que ça peut être 100% est juste ici, donc peut-être qu'on peut obtenir, vous savez, 95 % des bugs définitivement éliminés. Mais plus longtemps, plus nous trouvons de bugs, plus le travail et le temps que nous devons consacrer pour faire disparaître le prochain pourcentage de bogues. Et même avec cela ne saura jamais si le programme est sans bug. Il est presque impossible de concevoir un cas de test pour chaque cas d'utilisation possible avec votre programme, surtout si c'est quelque chose de grand. Imaginez Windows ou Mac OS essayant de vous assurer qu'il était 100% sans bug. Cela coûterait des milliards de dollars et des années et des années et des années au moment où ils ont réellement développé un de ceux qu'ils pourraient considérer peut-être 99,9% sans bug. La technologie aurait évolué, et le produit serait inutile. Donc, nous devons garder cela à l'esprit est que nous n'avons pas besoin de nous assurer qu'il est 100% sans bug . Nous avons juste besoin de nous assurer que c'est généralement sans bug. Et c'est aussi quelque chose d'important. Est-ce que cette idée qu'à mesure que le nombre de défauts détectés par DIF augmente , la probabilité de plus de bugs augmente. Imaginez si vous deviez des programmes à la fois faire exactement la même chose. Vous exécutez les mêmes cas de test sur ces deux programmes. Donc vous avez le programme A et vous avez le programme be et le programme A revient avec 10 bogues, et vous pourriez penser, Oh, c'est beaucoup. Il y a quelque chose qui ne va pas avec le programme A. Vous exécutez le même programme ou le même cas de test sur B et a 150 bogues. Maintenant, juste sur ces mêmes cas de test, lequel d'entre eux pensez-vous pourrait avoir encore plus de problèmes plus tard ? Et ce sera probablement parce que la quantité de bogues que nous détectons nous donne la qualité globale du code. Et donc si nous détectons de plus en plus de bogues, il y a la probabilité que toute la base de code ne soit probablement pas très bien écrite. Et il y a probablement Mawr et d'autres insectes là-dedans. Donc avec ça, avec les 10 bogues 1ers 150 bugs allaient probablement trouver au cours du test, vous savez, beaucoup moins de bogues qu'avec un cours de test. Et encore une fois, c'est une probabilité. Donc ce n'est pas garanti. Peut-être que ça finit par avoir 500. Celui-ci reste à 1 50 Ce n'est jamais une chose de garantie, mais c'est une sorte de notion générale à laquelle nous devons penser est que si nous commençons notre phase de test , nous commençons à regarder le code, et il y a un bug après bug après bug après un bug que nous pourrions avoir besoin de commencer à regarder l' architecture de l'application, et quelque chose pourrait être terriblement faux avec la base de code. Et on va faire face à des insectes avec ça pour toujours. Nous devons prendre des décisions sur ce qu'il faut faire à ce sujet. Donc ils commençaient juste à comprendre les choses très importantes qui comprennent chaque fois qu'on parle de tests qu'ils ont obtenus. Celui-ci est, bien sûr, le plus important. Des tests exhaustifs sont impossibles. Nous ne pouvons pas garantir que le programme n'aura pas de bugs. Nous avons juste besoin d'essayer d'en faire sortir le plus grand nombre possible de la manière la plus efficace possible. Notre entreprise essaie toujours de gagner de l'argent, donc nous essayons toujours de sortir ce produit à temps. L' ajout de huit semaines à la date limite des produits n'entraîne généralement pas un résultat favorable pour, vous savez, les employés. Donc on ne veut pas ajouter, tu sais, deux mois l'ont fait aux sourds. temps de tester ce dernier 2% des bogues. On ne veut pas faire ça. Ce ne sera probablement pas la meilleure décision. À un moment donné, nous devons faire l'appel à l'efficacité. Nous devons comprendre que nous voulons faire de bons tests, mais nous ne voulons pas essayer de garantir qu'ils n'ont pas d'argent. C' est juste un effort gaspillé 48. Aperçu du projet: Maintenant que vous avez une bonne compréhension des processus et des façons de concevoir des logiciels, le projet va être une sorte de projet amusant et ouvert. Tu allais concevoir un logiciel ? Donc, je vous ai donné une invite ici que vous pouvez utiliser ou vous pouvez créer le vôtre. Essentiellement, tout ce que je veux que vous fassiez dans le projet est de trouver une sorte d'exigences et spécifications sur ce que vous voulez construire, puis essayez de venir avec une architecture et la conception de ce projet et peut-être même d'examiner comment vous pourriez le déployer et d'autres choses comme ça. Mais dans l'ensemble, je veux juste que vous veniez avec l'idée et ensuite comment vous pourriez trouver les exigences et les spécifications. Soyez créatif avec elle. Cherchez des choses différentes. Essayez de trouver la meilleure façon de le faire. Essayez de voir si vous souhaitez ajouter une fonctionnalité plus tard sur les spécifications supplémentaires requises . Et c'est vraiment juste que le projet est juste de venir avec un projet, un faux projet et de voir comment vous pourriez construire ce morceau de logiciel. La seule chose que je conseille ne rend pas ça trop compliqué. Comme ne pas dire que vous voulez créer le prochain Facebook ou quelque chose comme ça, car cela pourrait avoir une liste d'exigences, vous savez, trois ou quatre pages de long ou même plus. Alors, venez avec quelque chose de simple, comme un distributeur automatique. Ou comme une simple boutique en ligne. Ou peut-être que vous voulez créer, vous savez, Ah, Ah, application iPhone simple, trucs comme ça, sorte que vous pouvez juste travailler avec quelque chose de vraiment simple, venir avec quelques exigences et voir comment vous transition vers la conception et l' architecture de l'APP.