851 lines
42 KiB
TeX
851 lines
42 KiB
TeX
\chapter{Fiabilité, évolutivité et maintenabilité}
|
|
|
|
\begin{quote}
|
|
The primary cost of maintenance is in spelunking and risk
|
|
\cite[139]{clean_architecture}
|
|
|
|
--- Robert C. Martin
|
|
\end{quote}
|
|
|
|
\section{Poésie de la programmation}
|
|
|
|
\begin{quote}
|
|
La poésie est "l'art d'évoquer et de suggérer les sensations, les impressions, les émotions les plus vives par l'union intense des sons, des rythmes, des harmonies, en particulier par les vers."
|
|
|
|
-- https://www.larousse.fr/dictionnaires/francais/po%C3%A9sie/61960
|
|
\end{quote}
|
|
|
|
Sans aller jusqu'à demander de développer vos algorithmes sur douze pieds, la programmation reste un art régit par un ensemble de bonnes pratiques, par des règles à respecter et par la nécessité de travailler avec d'autres personnes qui ont \sout{parfois} souvent une expérience, des compétences ou une approche différente.
|
|
|
|
\section{12 facteurs}
|
|
|
|
Pour la méthode de travail et de développement, nous allons nous baser
|
|
sur les \href{https://12factor.net/fr/}{The Twelve-factor App} - ou plus
|
|
simplement les \textbf{12 facteurs}.
|
|
Suivre ces concepts permet de:
|
|
|
|
\begin{enumerate}
|
|
\item
|
|
\textbf{Faciliter la mise en place de phases d'automatisation}; plus
|
|
concrètement, de faciliter les mises à jour applicatives, simplifier
|
|
la gestion de l'hôte qui héberge l'application ou les services,
|
|
diminuer la divergence entre les différents environnements d'exécution et offrir la possibilité d'intégrer le
|
|
projet dans un processus
|
|
d'\href{https://en.wikipedia.org/wiki/Continuous_integration}{intégration
|
|
continue} ou
|
|
\href{https://en.wikipedia.org/wiki/Continuous_deployment}{déploiement
|
|
continu}
|
|
\item
|
|
\textbf{Faciliter l'intégration de nouveaux développeurs dans l'équipe ou de
|
|
personnes souhaitant rejoindre le projet}, dans la mesure où la construction d'un nouvel environnement sera grandement facilitée.
|
|
\item
|
|
\textbf{Minimiser les divergences entre les différents environnemens}
|
|
sur lesquels un projet pourrait être déployé, pour éviter de découvrir un bogue sur l'environnement de production qui serait impossible à reproduire ailleurs, simplement parce qu'un des composants varierait
|
|
\item
|
|
\textbf{Augmenter l'agilité générale du projet}, en permettant une
|
|
meilleure évolutivité architecturale et une meilleure mise à l'échelle.
|
|
\end{enumerate}
|
|
|
|
En pratique, les points ci-dessus permettront de gagner un temps précieux à la construction d'un nouvel environnement - qu'il soit sur la machine du petit nouveau dans l'équipe, sur un serveur Azure/Heroku/Digital Ocean ou votre nouveau
|
|
Raspberry Pi Zéro planqué à la cave - et vous feront gagner un temps
|
|
précieux.
|
|
|
|
Pour reprendre plus spécifiquement les différentes idées derrière
|
|
cette méthode, nous avons:
|
|
|
|
\subsection{Une base de code unique, suivie par un contrôle de versions}
|
|
|
|
Chaque déploiement de l'application, et quel que soit l'environnement ciblé, se basera sur une source unique, afin de minimiser les différences que l'on pourrait trouver entre deux environnements d'un même projet.
|
|
Git est reconnu dans l'industrie comme standard des systèmes de contrôles de versions, malgré une courbe d'apprentissage assez ardue.
|
|
Comme dépôt, nous pourrons par exemple utiliser GitHub, Gitea ou Gitlab, suivant que vous ayez besoin d'une plateforme centralisée, propriétaire, payante ou auto-hébergée. \index{Git} \index{Github} \index{Gitlab} \index{Gitea}
|
|
|
|
\includegraphics{images/diagrams/12-factors-1.png}
|
|
|
|
Comme l'explique Eran Messeri, ingénieur dans le groupe Google Developer
|
|
Infrastructure: "Un des avantages d'utiliser un dépôt unique de sources,
|
|
est qu'il permet un accès facile et rapide à la forme la plus à jour du
|
|
code, sans aucun besoin de coordination. \cite[pp. 288-298]{devops_handbook}.
|
|
Ce cépôt n'est pas uniquement destiné à hébergé le code source, mais
|
|
également à d'autres artefacts et autres formes de connaissance:
|
|
|
|
\begin{itemize}
|
|
\item
|
|
Standards de configuration (Chef recipes, Puppet manifests, ...
|
|
\item
|
|
Outils de déploiement
|
|
\item
|
|
Standards de tests, y compris tout ce qui touche à la sécurité
|
|
\item
|
|
Outils de déploiement de pipeline
|
|
\item
|
|
Outils d'analyse et de monitoring
|
|
\item
|
|
Tutoriaux
|
|
\end{itemize}
|
|
|
|
\subsection{Déclarez explicitement et isolez les dépendances du projet}
|
|
|
|
Chaque installation ou configuration doit toujours être faite de la même
|
|
manière, et doit pouvoir être répétée quel que soit l'environnement
|
|
cible.
|
|
Ceci permet d'éviter que l'application n'utilise une dépendance qui ne soit
|
|
déjà installée sur un des sytèmes de développement, et qu'elle soit
|
|
difficile, voire impossible, à répercuter sur un autre environnement.
|
|
Dans le cas de Python, cela pourra être fait au travers de
|
|
\href{https://pypi.org/project/pip/}{PIP - Package Installer for Python}
|
|
ou \href{https://python-poetry.org/}{Poetry}.
|
|
La majorité des langages moderners proposent des mécanismes similaires (\href{https://rubygems.org/}{Gem} pour Ruby, \href{https://www.npmjs.com/}{NPM} pour NodeJS, ...)
|
|
|
|
Dans tous les cas, chaque application doit disposer d'un environnement sain, qui lui est assigné. Vu le peu de ressources que cela coûte, il ne faut pas s'en priver.
|
|
|
|
Chaque dépendance devra déclarer et épingler dans un fichier la version nécessaire.
|
|
Lors de la création d'un nouvel environnement vierge, il suffira d'utiliser ce
|
|
fichier comme paramètre afin d'installer les prérequis au bon
|
|
fonctionnement de notre application.
|
|
Ceci autorise une reproductibilité quasi parfaite de l'environnement.
|
|
|
|
Il est important de bien "épingler" les versions liées aux dépendances
|
|
de l'application. Cela peut éviter des effets de bord comme une nouvelle
|
|
version d'une librairie dans laquelle un bug aurait pu avoir été
|
|
introduit. Parce qu'il arrive que ce genre de problème apparaisse, et
|
|
lorsque ce sera le cas, ce sera systématiquement au mauvais moment \footnote{Le paquet PyLint dépend par exemple d'Astroid; \href{https://github.com/PyCQA/pylint-django/issues/343}{en janvier 2022}, ce dernier a été mis à jour sans respecter le principe de versions sémantiques et introduisant une régression. PyLint spécifiait que sa dépendance avec Astroid devait respecter une version ~2.9. Lors de sa mise à jour en 2.9.1, Astroid a introduit un changement majeur, qui faisait planter Pylint. L'épinglage explicite aurait pu éviter ceci.}
|
|
|
|
\subsection{Sauver la configuration directement au niveau de l'environnement}
|
|
|
|
Il faut éviter d'avoir à recompiler/redéployer l'application simplement parce
|
|
que:
|
|
|
|
\begin{enumerate}
|
|
\item
|
|
l'adresse du serveur de messagerie a été modifiée,
|
|
\item
|
|
un protocole a changé en cours de route
|
|
\item
|
|
la base de données a été déplacée
|
|
\item
|
|
...
|
|
\end{enumerate}
|
|
|
|
En pratique, toute information susceptible d'évoluer ou de changer (un seuil, une ressource externe, un couple utilisateur/mot de passe, ...) doit se trouver dans un fichier ou dans une variable d'environnement, et doit être facilement modifiable.
|
|
|
|
Ceci permet de paramétrer facilement un environnement (par exemple, un container), simplement en modifiant une variable de configuration qui spécifierait la base de données sur laquelle l'application devra se connecter.
|
|
|
|
Toute clé de configuration (nom du serveur de base de données, adresse d'un service Web externe, clé d'API pour l'interrogation d'une ressource, ...) sera définie directement au niveau de l'hôte - à aucun moment, nous ne devons trouver un mot de passe en clair dans le dépôt source ou une valeur susceptible d'évoluer, écrite en dur dans le code. \footnote{Ainsi, nous pourrions faire une \href{https://github.com/search?q=filenamefilename:.env DB_USERNAME&type=Code}{recherche sur Github} pour retrouver certaines variables d'environnement qui auraient été laissées en dur dans le code source de certains projets. Le \href{https://github.com/techgaun/github-dorks}{dépôt suivant} liste quelques idées de variables à rechercher...}.
|
|
|
|
Au moment de développer une nouvelle fonctionnalité, réfléchissez si
|
|
l'un des paramètres utilisés risquerait de subir une modification ou s'il concerne un principe de sécurité: ce composant peut concerner une nouvelle chaîne de connexion, un point de terminaison nécessaire à télécharger des données officielles ou un chemin vers un répertoire partagé pour y déposer un fichier.
|
|
|
|
Le risque est de se retrouver avec une liste colossale de paramètres; pensez à leur assigner une variable par défaut.
|
|
Par exemple, Gitea expose \href{https://docs.gitea.io/en-us/config-cheat-sheet/}{la liste suivante de paramètres}; il serait impossible de tous les configurer un à un avant de pouvoir démarrer une instance.
|
|
|
|
\subsection{Traiter les ressources externes comme des ressources
|
|
attachées}
|
|
|
|
Nous parlons de bases de données, de services de mise en cache, d'API
|
|
externes, ... L'application doit être capable d'effectuer
|
|
des changements au niveau de ces ressources sans que son code ne soit
|
|
modifié. Nous parlons alors de \textbf{ressources attachées}, dont la
|
|
présence est nécessaire au bon fonctionnement de l'application, mais
|
|
pour lesquelles le \textbf{type} n'est pas obligatoirement défini.
|
|
|
|
Nous voulons par exemple "une base de données" et "une mémoire cache",
|
|
et pas "une base MariaDB et une instance Memcached". De cette manière,
|
|
les ressources peuvent être attachées et détachées d'un déploiement à la
|
|
volée.
|
|
|
|
Si une base de données ne fonctionne pas correctement (problème matériel
|
|
?), l'administrateur pourrait simplement restaurer un nouveau serveur à
|
|
partir d'une précédente sauvegarde, et l'attacher à l'application sans
|
|
que le code source ne soit modifié. une solution consiste à passer
|
|
toutes ces informations (nom du serveur et type de base de données, clé
|
|
d'authentification, ... directement \emph{via} des
|
|
variables d'environnement.
|
|
|
|
\includegraphics{images/12factors/attached-resources.png}
|
|
|
|
Nous serons ravis de pouvoir simplement modifier une chaîne
|
|
\texttt{sqlite:////tmp/my-tmp-sqlite.db} en
|
|
\texttt{psql://user:pass@127.0.0.1:8458/db} lorsque ce sera nécessaire,
|
|
sans avoir à recompiler ou redéployer les modifications.
|
|
Ces ressources sont donc spécifiés grâce à des variables d'environnement, et chacune d'entre elles dispose également d'un \textbf{type}, afin de profiter d'une correspondance dynamique entre un moteur d'exécution et une information de configuration.
|
|
|
|
\subsection{Séparer proprement les phases de construction, de mise à
|
|
disposition et d'exécution}
|
|
|
|
\begin{enumerate}
|
|
\item
|
|
La \textbf{construction} (\emph{build}) convertit un code source en un
|
|
ensemble de fichiers exécutables, associé à une version et à une
|
|
transaction dans le système de gestion de sources.
|
|
\item
|
|
La \textbf{mise à disposition} (\emph{release}) associe cet ensemble à
|
|
une configuration prête à être exécutée,
|
|
\item
|
|
tandis que la phase d'\textbf{exécution} (\emph{run}) démarre les
|
|
processus nécessaires au bon fonctionnement de l'application.
|
|
\end{enumerate}
|
|
|
|
\includegraphics{images/12factors/release.png}
|
|
|
|
Parmi les solutions possibles, nous pourrions nous pourrions nous baser
|
|
sur les \emph{releases} de Gitea, sur un serveur d'artefacts (\href{https://fr.wikipedia.org/wiki/Capistrano_(logiciel)}{Capistrano}), voire directement au niveau de forge logicielle (Gitea, Github, Gitlab, ...).
|
|
|
|
\subsection{Les processus d'exécution ne doivent rien connaître ou
|
|
conserver de l'état de l'application}
|
|
|
|
Toute information stockée en mémoire ou sur disque ne doit pas altérer
|
|
le comportement futur de l'application, par exemple après un redémarrage
|
|
non souhaité.
|
|
Dit autrement, l'exécution de l'application ne doit pas dépendre de la présence d'une information stockée en mémoire ou sur disque.
|
|
|
|
Pratiquement, si l'application devait rencontrer un problème, il est nécessaire qu'elle puisse redémarrer rapidement, éventuellement en étant déployée sur un autre serveur - par exemple suite à un problème matériel.
|
|
Toute information stockée physiquement sur le premier hôte durant son exécution sur le premier hôte, puisqu'elle pourra avoir été entretemps perdue.
|
|
Lors d'une initialisation ou réinitialisation, la solution consiste donc à jouer sur les variables d'environnement (cf. \#3) et sur les informations que l'on pourra trouver au niveau des ressources attachées (cf \#4), et faire en sorte que les informations et données primordiales puissent être récupérées ou reconstruites.
|
|
|
|
Il serait également difficile d'appliquer une mise à l'échelle de l'application, en ajoutant un nouveau serveur d'exécution, si une donnée indispensable à son fonctionnement devait se trouver sur la seule machine où elle est actuellement exécutée.
|
|
|
|
\subsection{Autoriser la liaison d'un port de l'application à un port
|
|
du système hôte}
|
|
|
|
Les applications 12-factors sont auto-contenues et peuvent fonctionner
|
|
en autonomie totale. Elles doivent être joignables grâce à un mécanisme
|
|
de ponts, où l'hôte qui s'occupe de l'exécution effectue lui-même la
|
|
redirection vers l'un des ports ouverts par l'application, typiquement,
|
|
en HTTP ou via un autre protocole.
|
|
|
|
\includegraphics{images/diagrams/12-factors-7.png}
|
|
|
|
L'applicatoin fonctionne de manière autonome et expose un port (ici, le 8000).
|
|
Le serveur (= l'hôte) choisit d'appliquer une correspondance entre "son" port 443 et le port offert par l'application (8000).
|
|
|
|
\subsection{Faites confiance aux processus systèmes pour l'exécution
|
|
de l'application}
|
|
|
|
Comme décrit plus haut (cf. \#6), l'application doit utiliser des
|
|
processus \emph{stateless} (sans état). Nous pouvons créer et utiliser
|
|
des processus supplémentaires pour tenir plus facilement une lourde
|
|
charge, ou dédier des processus particuliers pour certaines tâches:
|
|
requêtes HTTP \emph{via} des processus Web; \emph{long-running} jobs
|
|
pour des processus asynchrones, \ldots\hspace{0pt} Si cela existe sur l'hôte hébergeant l'application, ne vous fatiguez pas: utilisez le.
|
|
|
|
\includegraphics{images/12factors/process-types.png}
|
|
|
|
\subsection{Améliorer la robustesse de l'application grâce à des
|
|
arrêts élégants et à des démarrages rapides}
|
|
|
|
Par "arrêt élégant", nous voulons surtout éviter le fameux
|
|
\texttt{kill\ -9\ \textless{}pid\textgreater{}} (ou équivalent), ou tout autre arrêt brutal d'un processus qui nécessiterait une intervention urgente du
|
|
superviseur.
|
|
En prévoyant une manière élégante d'envoyer un signal de terminaison,
|
|
|
|
\begin{enumerate}
|
|
\item Les requêtes en cours peuvent se terminer au mieux,
|
|
\item Le démarrage rapide de nouveaux processus améliorera la balance d'un processus en cours d'extinction vers des processus tout frais, en autorisant l'exécution parallèle d'anciens et de nouveaux "types" de processus
|
|
\end{enumerate}
|
|
|
|
L'intégration de ces mécanismes dès les premières étapes de
|
|
développement limitera les perturbations et facilitera la prise en
|
|
compte d'arrêts inopinés (problème matériel, redémarrage du système
|
|
hôte, etc.).
|
|
|
|
\includegraphics{images/12factors/process-type-chronology.png}
|
|
|
|
\subsection{Conserver les différents environnements aussi similaires
|
|
que possible, et limiter les divergences entre un environnement de
|
|
développement et de production}
|
|
|
|
L'exemple donné est un développeur qui utilise macOS, NGinx et SQLite,
|
|
tandis que l'environnement de production tourne sur une CentOS avec
|
|
Apache2 et PostgreSQL.
|
|
Faire en sorte que tous les environnements soient les plus similaires possibles limite les divergences entre environnements, facilite les déploiements et limite la casse et la découverte de modules non compatibles, au plus proche de la phase de développement, selon le principe de la corde d'Andon \cite[p. 140]{devops_handbook} \index{Andon} \footnote{Pour donner un exemple tout bête, SQLite utilise un
|
|
\href{https://www.sqlite.org/datatype3.html}{mécanisme de stockage
|
|
dynamique}, associée à la valeur plutôt qu'au schéma, \emph{via} un
|
|
système d'affinités. Un autre moteur de base de données définira un
|
|
schéma statique et rigide, où la valeur sera déterminée par son
|
|
contenant. Un champ \texttt{URLField} proposé par Django a une longeur
|
|
maximale par défaut de
|
|
\href{https://docs.djangoproject.com/en/3.1/ref/forms/fields/\#django.forms.URLField}{200
|
|
caractères}. Si vous faites vos développements sous SQLite et que vous
|
|
rencontrez une URL de plus de 200 caractères, votre développement sera
|
|
passera parfaitement bien, mais plantera en production (ou en
|
|
\emph{staging}, si vous faites les choses un peu mieux) parce que les
|
|
données seront tronquées, et que cela ne plaira pas à la base de données.
|
|
|
|
Conserver des environements similaires limite ce genre de désagréments.}
|
|
|
|
\subsection{Gérer les journeaux d'évènements comme des flux}
|
|
|
|
Une application ne doit jamais se soucier de l'endroit où les évènements qui la concerne seront écrits, mais se doit simplement de les envoyer sur la sortie \texttt{stdout}.
|
|
De cette manière, que nous soyons en développement sur le poste d'un développeur avec une sortie console ou sur une machine de production avec un envoi vers une instance \href{https://www.graylog.org/}{Greylog} ou \href{https://sentry.io/welcome/}{Sentry}, le routage des journaux sera réalisé en fonction de sa nécessité et de sa criticité, et non pas parce que le développeur l'a spécifié en dur dans son code.
|
|
|
|
Cette phase est critique, dans la mesure où les journaux d'exécution sont la seule manière pour une application de communiquer son état vers l'extérieur: recevoir une erreur interne de serveur est une chose; pouvoir obtenir un minimum d'informations, voire un contexte de plantage complet en est une autre.
|
|
La différence entre ces deux points vous fera, au mieux, gagner plusieurs heures sur l'identification ou la résolution d'un problème.
|
|
|
|
\subsection{Isoler les tâches administratives}
|
|
|
|
Evitez qu'une migration ne puisse être démarrée depuis une URL de
|
|
l'application, ou qu'un envoi massif de notifications ne soit accessible
|
|
pour n'importe quel utilisateur: les tâches administratives ne doivent
|
|
être accessibles qu'à un administrateur. Les applications 12facteurs
|
|
favorisent les langages qui mettent un environnement REPL (pour
|
|
\emph{Read}, \emph{Eval}, \emph{Print} et \emph{Loop}) \index{REPL} à disposition (au
|
|
hasard: \href{https://pythonprogramminglanguage.com/repl/}{Python} ou
|
|
\href{https://kotlinlang.org/}{Kotlin}), ce qui facilite les étapes de
|
|
maintenance.
|
|
|
|
\subsection{Conclusions}
|
|
|
|
Une application devient nettement plus maintenable dès lors que l'équipe
|
|
de développement suit de près les différentes étapes de sa conception,
|
|
de la demande jusqu'à son aboutissement en production.
|
|
\cite[pp. 293-294]{devops_handbook}.
|
|
Au fur et à mesure que le code est délibérément construit pour être maintenable, l'équipe gagne en rapidité, en qualité et en fiabilité de déploiement, ce qui facilite les tâches opérationnelles:
|
|
|
|
\begin{enumerate}
|
|
\item
|
|
Activation d'une télémétrie suffisante dans les applications et les
|
|
environnements
|
|
\item
|
|
Conservation précise des dépendances nécessaires
|
|
\item
|
|
Résilience des services et plantage élégant (i.e. \textbf{sans finir
|
|
sur un SEGFAULT avec l'OS dans les choux et un écran bleu})
|
|
\item
|
|
Compatibilité entre les différentes versions (n+1, \ldots\hspace{0pt})
|
|
\item
|
|
Gestion de l'espace de stockage associé à un environnement (pour
|
|
éviter d'avoir un environnement de production qui fait 157
|
|
Tera-octets)
|
|
\item
|
|
Activation de la recherche dans les logs
|
|
\item
|
|
Traces des requêtes provenant des utilisateurs, indépendamment des
|
|
services utilisés
|
|
\item
|
|
Centralisation de la configuration (\textbf{via} ZooKeeper, par
|
|
exemple)
|
|
\end{enumerate}
|
|
|
|
\section{Robustesse et flexibilité du code source}
|
|
|
|
\begin{quote}
|
|
Un code mal pensé entraîne nécessairement une perte d'énergie et de temps.
|
|
Il est plus simple de réfléchir, au moment de la conception du programme, à une architecture permettant une meilleure maintenabilité que de devoir corriger un code "sale" \emph{a posteriori}.
|
|
C'est pour aider les développeurs à rester dans le droit chemin que les principes SOLID ont été énumérés. \cite{gnu_linux_mag_hs_104}
|
|
\end{quote}
|
|
|
|
Les principes SOLID, introduit par Robert C. Martin dans les années 2000 pour orienter le développement de modules, sont les suivants:
|
|
|
|
\begin{enumerate}
|
|
\item
|
|
\textbf{SRP} - Single responsibility principle - Principe de Responsabilité Unique
|
|
\item
|
|
\textbf{OCP} - Open-closed principle
|
|
\item
|
|
\textbf{LSP} - Liskov Substitution
|
|
\item
|
|
\textbf{ISP} - Interface ségrégation principle
|
|
\item
|
|
\textbf{DIP} - Dependency Inversion Principle
|
|
\end{enumerate}
|
|
|
|
Des équivalents à ces directives existent au niveau des composants, puis au niveau architectural:
|
|
|
|
\begin{enumerate}
|
|
\item
|
|
Reuse/release équivalence principle,
|
|
\item
|
|
\textbf{CCP} - Common Closure Principle,
|
|
\item
|
|
\textbf{CRP} - Common Reuse Principle.
|
|
\end{enumerate}
|
|
|
|
\includegraphics{images/arch-comp-modules.png}
|
|
|
|
\subsection{Single Responsility Principle}
|
|
|
|
Le principe de responsabilité unique conseille de disposer de concepts ou domaines d'activité qui ne s'occupent chacun que d'une et une seule
|
|
chose.
|
|
Ceci rejoint (un peu) la \href{https://en.wikipedia.org/wiki/Unix_philosophy}{Philosophie Unix}, documentée par Doug McIlroy et qui demande de "\emph{faire une seule chose, mais de le faire bien}" \cite{unix_philosophy}.
|
|
|
|
Selon ce principe, une classe ou un élément de programmation ne doit donc pas avoir plus d'une seule raison de changer.
|
|
|
|
Plutôt que de centraliser le maximum de code à un seul endroit ou dans une seule classe par convenance ou commodité \footnote{Aussi appelé
|
|
\emph{God-Like object}}, le principe de responsabilité unique suggère que chaque classe soit responsable d'un et un seul concept.
|
|
|
|
Une manière de voir les choses consiste à différencier les acteurs ou les intervenants: imaginez disposer d'une classe représentant des données de membres du personnel; ces données pourraient être demandées par trois acteurs:
|
|
|
|
\begin{enumerate}
|
|
\item Le CFO (Chief Financial Officer)
|
|
\item Le CTO (Chief Technical Officer)
|
|
\item Le COO (Chief Operating Officer)
|
|
\end{enumerate}
|
|
|
|
Chacun d'entre eux aura besoin de données et d'informations relatives à ces membres du personnel, et provenant donc d'une même source de données centralisée.
|
|
Mais chacun d'entre eux également besoin d'une représentation différente ou de traitements distincts. \cite{clean_architecture}
|
|
|
|
Nous sommes d'accord qu'il s'agit à chaque fois de données liées aux employés; celles-ci vont cependant un cran plus loin et pourraient nécessiter des ajustements spécifiques en fonction de l'acteur concerné et de la manière dont il souhaite disposer des données.
|
|
Dès que possible, identifiez les différents acteurs et demandeurs, en vue de prévoir les modifications qui pourraient être demandées par l'un d'entre eux.
|
|
|
|
Dans le cas d'un élément de code centralisé, une modification induite par un des acteurs pourrait ainsi avoir un impact sur les données utilisées par les autres.
|
|
|
|
Vous trouverez ci-dessous une classe \texttt{Document}, dont chaque instance est représentée par trois propriétés: son titre, son contenu et sa date de publication.
|
|
Une méthode \texttt{render} permet également de proposer (très grossièrement) un type de sortie et un format de contenu: \texttt{XML} ou \texttt{Markdown}.
|
|
|
|
\begin{listing}[H]
|
|
\begin{minted}[tabsize=4]{Python}
|
|
class Document:
|
|
def __init__(self, title, content, published_at):
|
|
self.title = title
|
|
self.content = content
|
|
self.published_at = published_at
|
|
|
|
def render(self, format_type):
|
|
if format_type == "XML":
|
|
return """<?xml version = "1.0"?>
|
|
<document>
|
|
<title>{}</title>
|
|
<content>{}</content>
|
|
<publication_date>{}</publication_date>
|
|
</document>""".format(
|
|
self.title,
|
|
self.content,
|
|
self.published_at.isoformat()
|
|
)
|
|
|
|
if format_type == "Markdown":
|
|
import markdown
|
|
return markdown.markdown(self.content)
|
|
|
|
raise ValueError(
|
|
"Format type '{}' is not known".format(format_type)
|
|
)
|
|
\end{minted}
|
|
\caption{Un convertisseur de document un peu bateau}
|
|
\end{listing}
|
|
|
|
|
|
Lorsque nous devrons ajouter un nouveau rendu (Atom, OpenXML, ...), il sera nécessaire de modifier la classe \texttt{Document}.
|
|
Ceci n'est:
|
|
|
|
\begin{enumerate}
|
|
\item Ni intuitif: \emph{ce n'est pas le document qui doit savoir dans quels formats il peut être converti}
|
|
\item Ni conseillé: \emph{lorsque nous aurons quinze formats différents à gérer, il sera nécessaire d'avoir autant de conditions dans cette méthode}
|
|
\end{enumerate}
|
|
|
|
En suivant le principe de responsabilité unique, une bonne pratique consiste à créer une nouvelle classe de rendu pour chaque type de format à gérer:
|
|
|
|
\begin{listing}[H]
|
|
\begin{minted}[tabsize=4]{Python}
|
|
class Document:
|
|
def __init__(self, title, content, published_at):
|
|
self.title = title
|
|
self.content = content
|
|
self.published_at = published_at
|
|
|
|
class DocumentRenderer:
|
|
def render(self, document):
|
|
if format_type == "XML":
|
|
return """<?xml version = "1.0"?>
|
|
<document>
|
|
<title>{}</title>
|
|
<content>{}</content>
|
|
<publication_date>{}</publication_date>
|
|
</document>""".format(
|
|
self.title,
|
|
self.content,
|
|
self.published_at.isoformat()
|
|
)
|
|
|
|
if format_type == "Markdown":
|
|
import markdown
|
|
return markdown.markdown(self.content)
|
|
|
|
raise ValueError("Format type '{}' is not known".format(format_type))
|
|
\end{minted}
|
|
\caption{Isolation du rendu d'un document par rapport à sa modélisation}
|
|
\end{listing}
|
|
|
|
|
|
A présent, lorsque nous devrons ajouter un nouveau format de prise en charge, il nous suffira de modifier la classe \texttt{DocumentRenderer}, sans que la classe \texttt{Document} ne soit impactée.
|
|
En même temps, le jour où une instance de type \texttt{Document} sera liée à un champ \texttt{author}, rien ne dit que le rendu devra en tenir compte; nous modifierons donc notre classe pour y ajouter le nouveau champ sans que cela n'impacte nos différentes manières d'effectuer un rendu.
|
|
|
|
Un autre exemple consiterait à faire communiquer une méthode avec une base de données: ce ne sera pas à cette méthode à gérer l'inscription d'une exception à un emplacement spécifique (emplacement sur un disque, ...): cette action doit être prise en compte par une autre classe (ou un autre concept ou composant), qui s'occupera de définir elle-même l'emplacement où l'évènement sera enregistré, que ce soit dans une base de données, une instance Graylog ou un fichier.
|
|
Cette manière de structurer le code permet de centraliser la configuration d'un type d'évènement à un seul endroit, ce qui augmente ainsi la testabilité globale du projet.
|
|
|
|
L'équivalent du principe de responsabilité unique au niveau des composants sera le \texttt{Common Closure Principle} \index{CCP}.
|
|
Au niveau architectural, cet équivalent correspondra aux frontières.
|
|
|
|
\subsection{Open-Closed}
|
|
|
|
\begin{quote}
|
|
For software systems to be easy to change, they must be designed to allow the behavior to change by adding new code instead of changing existing code.
|
|
\end{quote}
|
|
|
|
L'objectif est de rendre le système facile à étendre, en limitant l'impact qu'une modification puisse avoir.
|
|
|
|
Reprendre notre exemple de modélisation de documents parle de lui-même:
|
|
|
|
\begin{enumerate}
|
|
\item Des données que nous avons converties dans un format spécifique pourraient à présent devoir être présentées dans une page web.
|
|
\item Et demain, ce sera dans un document PDF.
|
|
\item Et après demain, dans un tableur Excel.
|
|
\end{enumerate}
|
|
|
|
La source de ces données reste la même (au travers d'une couche de présentation): c'est leur mise en forme qui diffère à chaque fois.
|
|
L'application n'a pas à connaître les détails d'implémentation: elle doit juste permettre une forme d'extension, sans avoir à appliquer quelconque modification en son cœur.
|
|
|
|
Un des principes essentiels en programmation orientée objets concerne l'héritage de classes et la surcharge de méthodes: plutôt que de partir sur une série de comparaisons comme nous l'avons initisée plus tôt pour définir le comportement d'une instance, il est parfois préférable de définir une nouvelle sous-classe, qui surcharge une méthode bien précise.
|
|
Pour prendre un nouvel exemple, nous pourrions ainsi définir trois classes:
|
|
|
|
\begin{itemize}
|
|
\item
|
|
Une classe \texttt{Customer}, pour laquelle la méthode \texttt{GetDiscount} ne renvoit rien;
|
|
\item
|
|
Une classe \texttt{SilverCustomer}, pour laquelle la méthode revoit une réduction de 10\%;
|
|
\item
|
|
Une classe \texttt{GoldCustomer}, pour laquelle la même méthode renvoit une réduction de 20\%.
|
|
\end{itemize}
|
|
|
|
Si nous devions rencontrer un nouveau type de client, il nous suffira de créer une nouvelle sous-classe, implémentant la réduction que nous souhaitons lui offrir.
|
|
Ceci évite d'avoir à gérer un ensemble conséquent de conditions dans la méthode initiale, en fonction d'une variable ou d'un paramètre - ici, le type de client.
|
|
|
|
Nous passerions ainsi de ceci:
|
|
|
|
\begin{listing}[H]
|
|
\begin{minted}{Python}
|
|
class Customer():
|
|
def __init__(self, customer_type: str):
|
|
self.customer_type = customer_type
|
|
|
|
def get_discount(customer: Customer) -> int:
|
|
if customer.customer_type == "Silver":
|
|
return 10
|
|
elif customer.customer_type == "Gold":
|
|
return 20
|
|
return 0
|
|
|
|
>>> jack = Customer("Silver")
|
|
>>> jack.get_discount()
|
|
10
|
|
\end{minted}
|
|
\end{listing}
|
|
|
|
A ceci:
|
|
|
|
\begin{listing}[H]
|
|
\begin{minted}{Python}
|
|
class Customer():
|
|
def get_discount(self) -> int:
|
|
return 0
|
|
|
|
class SilverCustomer(Customer):
|
|
def get_discount(self) -> int:
|
|
return 10
|
|
|
|
class GoldCustomer(Customer):
|
|
def get_discount(self) -> int:
|
|
return 20
|
|
|
|
>>> jack = SilverCustomer()
|
|
>>> jack.get_discount()
|
|
10
|
|
\end{minted}
|
|
\end{listing}
|
|
|
|
En anglais, dans le texte : "\emph{Putting in simple words, the ``Customer'' class is now closed for any new modification but it's open for extensions when new customer types are added to the project.}".
|
|
|
|
\textbf{En résumé}: nous fermons la classe \texttt{Customer} à toute modification, mais nous ouvrons la possibilité de créer de nouvelles extensions en ajoutant de nouveaux types héritant de \texttt{Customer}.
|
|
|
|
De cette manière, nous simplifions également la maintenance de la méthode \texttt{get\_discount}, dans la mesure où elle dépend directement du type dans lequel elle est implémentée.
|
|
|
|
Nous pouvons également appliquer ceci à notre exemple sur les rendus de document, où le code suivant:
|
|
|
|
\begin{listing}[H]
|
|
\begin{minted}[tabsize=4]{Python}
|
|
class Document:
|
|
def __init__(self, title, content, published_at):
|
|
self.title = title
|
|
self.content = content
|
|
self.published_at = published_at
|
|
|
|
def render(self, format_type):
|
|
if format_type == "XML":
|
|
return """<?xml version = "1.0"?>
|
|
<document>
|
|
<title>{}</title>
|
|
<content>{}</content>
|
|
<publication_date>{}</publication_date>
|
|
</document>""".format(
|
|
self.title,
|
|
self.content,
|
|
self.published_at.isoformat()
|
|
)
|
|
|
|
if format_type == "Markdown":
|
|
import markdown
|
|
return markdown.markdown(self.content)
|
|
|
|
raise ValueError(
|
|
"Format type '{}' is not known".format(format_type)
|
|
)
|
|
\end{minted}
|
|
\end{listing}
|
|
|
|
devient le suivant:
|
|
|
|
\begin{listing}[H]
|
|
\begin{minted}[tabsize=4]{Python}
|
|
class Renderer:
|
|
def render(self, document):
|
|
raise NotImplementedError
|
|
|
|
class XmlRenderer(Renderer):
|
|
def render(self, document)
|
|
return """<?xml version = "1.0"?>
|
|
<document>
|
|
<title>{}</title>
|
|
<content>{}</content>
|
|
<publication_date>{}</publication_date>
|
|
</document>""".format(
|
|
document.title,
|
|
document.content,
|
|
document.published_at.isoformat()
|
|
)
|
|
|
|
class MarkdownRenderer(Renderer):
|
|
def render(self, document):
|
|
import markdown
|
|
return markdown.markdown(document.content)
|
|
\end{minted}
|
|
\caption{Notre convertisseur suit le principe Open-Closed}
|
|
\end{listing}
|
|
|
|
Lorsque nous ajouterons notre nouveau type de rendu, nous ajouterons simplement une nouvelle classe de rendu qui héritera de \texttt{Renderer}.
|
|
|
|
\subsection{Liskov Substitution}
|
|
|
|
|
|
Dans Clean Architecture, ce chapitre ci (le 9) est sans doute celui qui est le moins complet.
|
|
Je suis d'accord avec les exemples donnés, dans la mesure où la définition concrète d'une classe doit dépendre d'une interface correctement définie (et que donc, faire hériter un carré d'un rectangle, n'est pas adéquat dans le mesure où cela induit l'utilisateur en erreur), mais il y est aussi question de la définition d'un style architectural pour une interface REST, mais sans donner de solution...
|
|
|
|
Le principe de substitution fait qu'une classe héritant d'une autre classe doit se comporter de la même manière que cette dernière.
|
|
Il n'est pas question que la sous-classe n'implémente pas certaines méthodes, alors que celles-ci sont disponibles sa classe parente.
|
|
|
|
\begin{quote}
|
|
{[}\ldots\hspace{0pt}{]} if S is a subtype of T, then objects of type T in a computer program may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T), without altering any of the desirable properties of that program (correctness, task performed, etc.).
|
|
|
|
--- \href{http://en.wikipedia.org/wiki/Liskov_substitution_principle}{Wikipédia}.
|
|
\end{quote}
|
|
|
|
\begin{quote}
|
|
Let q(x) be a property provable about objects x of type T.
|
|
Then q(y) should be provable for objects y of type S, where S is a subtype of T.
|
|
|
|
--- \href{http://en.wikipedia.org/wiki/Liskov_substitution_principle}{Wikipédia aussi}
|
|
\end{quote}
|
|
|
|
Ce n'est donc pas parce qu'une classe \textbf{a besoin d'une méthode définie dans une autre classe} qu'elle doit forcément en hériter.
|
|
Cela bousillerait le principe de substitution, dans la mesure où une instance de cette classe pourra toujours être considérée comme étant du type de son parent.
|
|
|
|
Petit exemple pratique: si nous définissons une méthode \texttt{make\_some\_noise} et une méthode \texttt{eat} sur une classe \texttt{Duck}, et qu'une réflexion avancée (et sans doute un peu alcoolisée) nous dit que "\emph{Puisqu'un \texttt{Lion} fait aussi du bruit, faisons le hériter de notre classe `Canard`"}, nous allons nous retrouver avec ceci:
|
|
|
|
\begin{listing}[H]
|
|
\begin{minted}[tabsize=4]{Python}
|
|
class Duck:
|
|
def make_some_noise(self):
|
|
print("Kwak")
|
|
|
|
def eat(self, thing):
|
|
if thing in ("plant", "insect", "seed", "seaweed", "fish"):
|
|
return "Yummy!"
|
|
raise IndigestionError("Arrrh")
|
|
|
|
class Lion(Duck):
|
|
def make_some_noise(self):
|
|
print("Roaaar!")
|
|
\end{minted}
|
|
\caption{Un lion et un canard sont sur un bateau...}
|
|
\end{listing}
|
|
|
|
|
|
|
|
Le principe de substitution de Liskov suggère qu'une classe doit toujours pouvoir être considérée comme une instance de sa classe parent, et \textbf{doit pouvoir s'y substituer}.
|
|
Dans notre exemple, cela signifie que nous pourrons tout à fait accepter qu'un lion se comporte comme un canard et adore manger des plantes, insectes, graines, algues et du poisson. Miam !
|
|
Nous vous laissons tester la structure ci-dessus en glissant une antilope dans la boite à goûter du lion, ce qui nous donnera quelques trucs bizarres (et un lion atteint de botulisme).
|
|
|
|
Pour revenir à nos exemples de rendus de documents, nous aurions pu faire hériter notre \texttt{MarkdownRenderer} de la classe \texttt{XmlRenderer}:
|
|
|
|
\begin{listing}[H]
|
|
\begin{minted}[tabsize=4]{Python}
|
|
class XmlRenderer:
|
|
def render(self, document)
|
|
return """<?xml version = "1.0"?>
|
|
<document>
|
|
<title>{}</title>
|
|
<content>{}</content>
|
|
<publication_date>{}</publication_date>
|
|
</document>""".format(
|
|
document.title,
|
|
document.content,
|
|
document.published_at.isoformat()
|
|
)
|
|
|
|
class MarkdownRenderer(XmlRenderer):
|
|
def render(self, document):
|
|
import markdown
|
|
return markdown.markdown(document.content)
|
|
\end{minted}
|
|
\caption{Le convertisseur Markdown hérite d'un convertisseur XML...}
|
|
\end{listing}
|
|
|
|
|
|
Si nous décidons à un moment d'ajouter une méthode d'entête au niveau de notre classe de rendu XML, notre rendu en Markdown héritera irrémédiablement de cette même méthode:
|
|
|
|
\begin{listing}[H]
|
|
\begin{minted}[tabsize=4]{Python}
|
|
class XmlRenderer:
|
|
def header(self):
|
|
return """<?xml version = "1.0"?>""
|
|
|
|
def render(self, document)
|
|
return """{}
|
|
<document>
|
|
<title>{}</title>
|
|
<content>{}</content>
|
|
<publication_date>{}</publication_date>
|
|
</document>""".format(
|
|
self.header(),
|
|
document.title,
|
|
document.content,
|
|
document.published_at.isoformat()
|
|
)
|
|
|
|
class MarkdownRenderer(XmlRenderer):
|
|
def render(self, document):
|
|
import markdown
|
|
return markdown.markdown(document.content)
|
|
\end{minted}
|
|
\caption{... et il a mal à l'entête}
|
|
\end{listing}
|
|
|
|
Le code ci-dessus ne porte pas à conséquence \footnote{Pas immédiatement, en tout cas...}, mais dès que nous invoquerons la méthode \texttt{header()} sur une instance de type \texttt{MarkdownRenderer}, nous obtiendrons un bloc de déclaration XML (\texttt{\textless{}?xml\ version\ =\ "1.0"?\textgreater{}}) pour un fichier Markdown, ce qui n'aura aucun sens.
|
|
|
|
\section{Tests unitaires et d'intégration}
|
|
|
|
\begin{quote}
|
|
Tests are part of the system.
|
|
You can think of tests as the outermost circle in the architecture.
|
|
Nothing within in the system depends on the tests, and the tests always depend inward on the components of the system.
|
|
|
|
-- Robert C. Martin, Clean Architecture
|
|
\end{quote}
|
|
|
|
\section{Complexité cyclomatique\index{McCabe}}
|
|
|
|
La \href{https://fr.wikipedia.org/wiki/Nombre_cyclomatique}{complexité cyclomatique} (ou complexité de McCabe) peut s'apparenter à mesure de difficulté de compréhension du code, en fonction du nombre d'embranchements trouvés dans une même section.
|
|
Quand le cycle d'exécution du code rencontre une condition, cette condition peut être évalue à VRAI ou à FAUX.
|
|
L'exécution du code dispose donc de deux embranchements, correspondant chacun à un résultat de cette condition.
|
|
|
|
Le code suivant \autoref{cyclomatic-simple-code} a une complexité cyclomatique 1; il s'agit du cas le plus simple que nous pouvons implémenter: l'exécution du code rentre dans la fonction (il y a un seul embranchement), et aucun bloc conditionnel n'est présent sur son chemin.
|
|
La complexité reste de 1.
|
|
|
|
\begin{listing}[!hbpt]
|
|
\begin{minted}{Python}
|
|
from datetime import date
|
|
|
|
def print_current_date():
|
|
print(date.today())
|
|
\end{minted}
|
|
\caption{Une version ultra-simple de l'affichage du jour de la semaine}
|
|
\label{cyclomatic-simple-code}
|
|
\end{listing}
|
|
|
|
Si nous complexifions cette fonction en vérifiant (par exemple) le jour de la semaine, nous aurons notre embranchement initial (l'impression à l'écran de la date du jour), mais également un second embranchement qui vérifiera si cette date correspond à un lundi:
|
|
|
|
\begin{listing}[!h]
|
|
\begin{minted}{Python}
|
|
from datetime import date
|
|
|
|
def print_current_date_if_monday():
|
|
if date.today().weekday() == 0:
|
|
print("Aujourd'hui, c'est lundi!")
|
|
print(date.today())
|
|
\end{minted}
|
|
\caption{Ajout d'une fonctionnalité essentielle et totalement indispensable}
|
|
\end{listing}
|
|
|
|
La complexité cyclomatique d'un bloc est évaluée sur base du nombre d'embranchements possibles; par défaut, sa valeur est de 1.
|
|
Si nous rencontrons une condition, elle passera à 2, etc.
|
|
Cette complexité est liée à deux concepts:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{La lisibilité du code}: au plus la complexité cyclomatique sera élevée, au plus le code sera compliqué à comprendre en première instance. Il sera composé de plusieurs conditions, éventuellement imbriquées, il débordera probablement de la hauteur que votre écran sera capable d'afficher
|
|
\item \textbf{Les tests unitaires}: pour nous assurer d'une couverture de code correcte, il sera nécessaire de couvrir tous les embranchements présentés. Connaître la complexité permet de savoir combien de tests devront être écrits pour assurer une couverture complète de tous les cas pouvant se présenter.
|
|
\end{itemize}
|
|
|
|
\subsection{Lisibilité du code}
|
|
|
|
Il est important de noter que refactoriser un bloc, par exemple en extrayant une méthode, n'améliore pas la complexité cyclomatique globale de l'application.
|
|
L'amélioration que nous visons ici est une amélioration \textbf{locale}, qui facilite la lecture d'un bloc spécifique, et pas d'un programme complet.
|
|
|
|
"Améliorons" notre code ci-dessous, pour lui ajouter la possibilité de gérer les autres jours de la semaine:
|
|
|
|
\begin{listing}[!ht]
|
|
\begin{minted}{Python}
|
|
from datetime import date
|
|
|
|
def print_current_date():
|
|
if date.today().weekday() == 0:
|
|
print("Lundi")
|
|
elif date.today().weekday() == 1:
|
|
print("Mardi")
|
|
elif date.today().weekday() == 2:
|
|
print("Mercredi")
|
|
elif date.today().weekday() == 3:
|
|
print("Jeudi")
|
|
elif date.today().weekday() == 4:
|
|
print("Vendredi")
|
|
elif date.today().weekday() == 5:
|
|
print("Samedi")
|
|
elif date.today().weekday() == 6:
|
|
print("Dimanche")
|
|
print(date.today())
|
|
\end{minted}
|
|
\caption{Un code un peu nul avec une complexité cyclomatique qui l'est tout autant}
|
|
\label{Impression du jour de la semaine, version naïve}
|
|
\end{listing}
|
|
|
|
La complexité de ce code est évaluée à 8, même si la complexité effective ne sera que de 7.
|
|
Extraire une méthode à partir de ce bloc pourra réduire la complexité de la fonction \mintinline{python}{print_current_date} n'améliorera rien et ne fera que déplacer le problème.
|
|
Une solution serait de passer par un dictionnaire, de façon à ramener la complexité à 1:
|
|
|
|
\begin{listing}[!ht]
|
|
\begin{minted}{python}
|
|
from datetime import date
|
|
|
|
def print_current_date():
|
|
DAYS_OF_WEEK = {
|
|
0: "Lundi",
|
|
1: "Mardi",
|
|
2: "Mercredi",
|
|
3: "Jeudi",
|
|
4: "Vendredi",
|
|
5: "Samedi",
|
|
6: "Dimanche"
|
|
}
|
|
|
|
print(DAYS_OF_WEEK.get(date.today().weekday()))
|
|
print(date.today())
|
|
\end{minted}
|
|
\caption{La même version, avec une complexité réduite à 1}
|
|
\end{listing}
|
|
|
|
|
|
\subsection{Tests unitaires}
|
|
|
|
Le nombre de tests unitaires nécessaires à la couverture d'un bloc fonctionnel est au minimum égal à la complexité cyclomatique de ce bloc.
|
|
Une possibilité pour améliorer la maintenance du code est de faire baisser ce nombre, et de le conserver sous un certain seuil.
|
|
Certains recommandent de le garder sous une complexité de 10; d'autres de 5.
|
|
|