Il s'agit d'une reprise gratuite et très brève du nouveau livre de Robert Martin (Uncle Bob) «Clean Architecture», sorti en 2018.
Présentation
L'architecture logicielle est un peu comme l'architecture du bâtiment. Les bâtiments ont également une structure fractale: les bâtiments sont constitués de compartiments, les compartiments sont constitués de pièces, les pièces sont constituées de murs, les murs sont en briques. Les programmes, en revanche, sont constitués de modules, qui se composent de packages, qui se composent de classes, qui se composent de fonctions, etc. Cependant, la diversité des structures des programmes est beaucoup plus large que celle des bâtiments, de sorte que l'oncle Bob considère l'architecture logicielle «plus architecturale» que l'architecture du bâtiment.
De plus, l'architecture du bâtiment est plus facile à visualiser dans la tête que le logiciel, car nous voyons des bâtiments tous les jours, et l'architecture des programmes nous est cachée à l'intérieur du code source. L'architecture logicielle ne ressemble à rien.
D'autre part, l'architecture logicielle doit également se souvenir des limitations physiques, car les programmes s'exécutent sur du matériel réel avec des performances, une mémoire, une bande passante réseau limitées, etc.
Qu'est-ce qu'une bonne architecture? Il s'agit d'une architecture qui répond aux besoins des utilisateurs, des propriétaires d'entreprise et des programmeurs, non seulement à l'heure actuelle,
mais aussi au fil du temps .
"Si vous pensez qu'une bonne architecture coûte cher, essayez mal."
"La seule façon d'aller vite est de bien aller."
Préface
Oncle Bob écrit du code depuis plus de 50 ans. Il a écrit une grande variété de programmes: grands, petits, GUI, console, web, etc. Et je suis arrivé à la conclusion que les règles d'architecture sont les mêmes partout! Et même sur 50 ans, ils n'ont pas changé malgré l'augmentation gigantesque de la productivité du fer.
Les langages de programmation sont également devenus bien meilleurs, mais les constructions de base sont restées les mêmes: if, assignation, boucles, etc. Si vous mettez un programmeur du milieu du siècle dernier pour un MacBook moderne, au début, cela devient fou, mais ensuite il sera normal d'écrire du code Java dans l'Idea.
Mais plus d'un demi-siècle a acquis beaucoup d'expérience, ce qui n'était pas encore le cas il y a 50 ans. Les règles ont été formulées, auxquelles ce livre est dédié.
Présentation
La rédaction d'un programme de travail est facile. Il est difficile d'
écrire le programme correctement . Cela nécessite des connaissances, de l'expérience et des compétences, dont le développement demande beaucoup de temps et de discipline.
Une fois le programme correctement exécuté, il est facile à entretenir et à y apporter des modifications. Le pourcentage de défauts est très faible. Il n'a pas besoin de hordes de programmeurs, de tonnes de documents avec des exigences et de trackers sophistiqués.
Cela semble utopique, mais l'oncle Bob a réussi à travailler sur de tels projets. Mais malheureusement, dans la plupart des cas, nous devons travailler dans une conception terrible.
Qu'est-ce que le design et l'architecture?
Supposons que le design et l'architecture sont une seule et même chose.
L'architecture n'est pas seulement le niveau supérieur, ce sont les détails de niveau supérieur et de bas niveau dans leur ensemble. L'un sans l'autre n'existe pas.
Le but de l'architecture logicielle est de
minimiser les ressources humaines nécessaires pour construire et maintenir le système requis.
Si les efforts sont petits et le
restent tout au long de la vie , le design est bon. Si les efforts augmentent avec chaque version, la conception est mauvaise.
À titre d'exemple, l'oncle Bob montre un graphique d'un projet réel, dans lequel le nombre d'employés a augmenté de 50 fois, mais le nombre de lignes de code n'a augmenté que de 2,3 fois (3M -> 7M). Un graphique plus effrayant est une augmentation du coût d'une seule ligne de code d'environ 40 fois. C'est-à-dire la productivité est passée de 100% à presque zéro. Les programmeurs travaillent dur au mieux, mais essentiellement rien ne peut être fait. Et maintenant, le pire: si dans la première version, nous devions payer plusieurs centaines de milliers de dollars par mois aux employés, alors finalement ce chiffre est devenu 20 millions de dollars par mois!
Ensuite, l'oncle Bob rappelle la parabole du lièvre et de la tortue. Dans ce document, la tortue a remporté la course parce que le lièvre était trop sûr de lui, s'est couché et a dormi pendant toute la course.
La même chose avec le développement: le programmeur s'amuse avec la confiance qu'il sera en mesure de déployer rapidement le produit et de rétablir l'ordre plus tard. Cependant, le problème est qu'après la sortie, il doit faire la prochaine fonctionnalité, sinon il sera à la traîne des concurrents sur le marché. Au final, dans quelques mois, sa productivité tombera tout simplement à zéro et il perdra.
Il donne ensuite un exemple d'expérience menée par un certain Jason Gorman, où il écrit plusieurs fois un programme simple. Et il s'avère qu'avec TDD la première fois est plus rapide que même la troisième fois sans TDD. Autrement dit, si vous écrivez correctement, le résultat est plus rapide.
Le développeur doit
être responsable du désordre qu'il introduit dans le projet. La qualité de l'architecture doit être prise au sérieux. Mais pour cela, vous devez savoir ce qu'est une bonne architecture.
Une histoire sur deux valeurs
Il y a deux valeurs - le comportement et l'architecture.
Le comportement signifie que le programme répond aux exigences fonctionnelles et apporte ainsi de l'argent aux propriétaires d'entreprise. Le problème est que de nombreux programmeurs pensent que c'est leur travail.
La deuxième valeur est la qualité à laquelle le programme reste dans un état maintenu. Autrement dit, il est facile de changer. La complexité des changements devrait être proportionnelle à l'échelle de ces changements, mais pas à leur forme. L'architecture ne doit pas privilégier certaines formes par rapport à d'autres, sinon les demandes des propriétaires seront de plus en plus difficiles à mettre en œuvre à chaque fois.
Quoi de plus important - comportement ou architecture? Les gestionnaires estiment qu'il est plus important que le système fonctionne. Mais les programmeurs devraient considérer le contraire, que l'architecture est plus importante.
La matrice d'Eisenhower dit qu'important et non urgent a une priorité plus élevée que urgent et sans importance. Et l'architecture est toujours importante contrairement au comportement, elle est donc plus prioritaire.
Le programmeur doit se battre pour l'architecture. Un programmeur est également membre de l'entreprise. L'architecture est sa responsabilité.
À suivre ...