Switching to latex (definitively)
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/push Build is passing
Details
This commit is contained in:
parent
b65a23c66b
commit
e4839e2048
|
|
@ -0,0 +1,10 @@
|
|||
FROM miktex/miktex
|
||||
|
||||
LABEL Description="Docker container from MiKTeX, Ubuntu 20.04, with Pygments" Version="1.0"
|
||||
|
||||
RUN apt update && apt install python3-pip -y && pip install pygments
|
||||
|
||||
WORKDIR /miktex/work
|
||||
|
||||
CMD ["bash"]
|
||||
|
||||
|
|
@ -0,0 +1,185 @@
|
|||
\chapter{Elements d'architecture}
|
||||
|
||||
\begin{quote}
|
||||
If you think good architecture is expensive, try bad architecture
|
||||
|
||||
--- Brian Foote and Joseph Yoder
|
||||
\end{quote}
|
||||
|
||||
Au delà des principes dont il est question plus haut, c'est dans les
|
||||
ressources proposées et les cas démontrés que l'on comprend leur
|
||||
intérêt: plus que de la définition d'une architecture adéquate, c'est
|
||||
surtout dans la facilité de maintenance d'une application que ces
|
||||
principes s'identifient.
|
||||
|
||||
Une bonne architecture va rendre le système facile à lire, facile à
|
||||
développer, facile à maintenir et facile à déployer. L'objectif ultime
|
||||
étant de minimiser le coût de maintenance et de maximiser la
|
||||
productivité des développeurs. Un des autres objectifs d'une bonne
|
||||
architecture consiste également à se garder le plus d'options possibles,
|
||||
et à se concentrer sur les détails (le type de base de données, la
|
||||
conception concrète, le plus tard possible, tout en
|
||||
conservant la politique principale en ligne de mire. Cela permet de
|
||||
délayer les choix techniques à «~plus tard~», ce qui permet également de
|
||||
concrétiser ces choix en ayant le plus d'informations possibles
|
||||
\cite[pp.137-141]{clean_architecture}
|
||||
|
||||
Derrière une bonne architecture, il y a aussi un investissement quant
|
||||
aux ressources qui seront nécessaires à faire évoluer l'application: ne
|
||||
pas investir dès qu'on le peut va juste lentement remplir la case de la
|
||||
dette technique.
|
||||
|
||||
Une architecture ouverte et pouvant être étendue n'a d'intérêt que si le
|
||||
développement est suivi et que les gestionnaires (et architectes)
|
||||
s'engagent à économiser du temps et de la qualité lorsque des
|
||||
changements seront demandés pour l'évolution du projet.
|
||||
|
||||
\section{Politiques et règles métiers}
|
||||
|
||||
\section{Considérations sur les frameworks}
|
||||
|
||||
\begin{quote}
|
||||
Frameworks are tools to be used, not architectures to be conformed to.
|
||||
Your architecture should tell readers about the system, not about the
|
||||
frameworks you used in your system. If you are building a health care
|
||||
system, then when new programmers look at the source repository, their
|
||||
first impression should be, «~oh, this is a health care system~». Those
|
||||
new programmers should be able to learn all the use cases of the system,
|
||||
yet still not know how the system is delivered.
|
||||
|
||||
--- Robert C. Martin Clean Architecture
|
||||
\end{quote}
|
||||
|
||||
Le point soulevé ci-dessous est qu'un framework n'est qu'un outil, et
|
||||
pas une obligation de structuration. L'idée est que le framework doit se
|
||||
conformer à la définition de l'application, et non l'inverse. Dans le
|
||||
cadre de l'utilisation de Django, c'est un point critique à prendre en
|
||||
considération: une fois que vous aurez fait ce choix, vous aurez
|
||||
extrêmement difficile à faire machine arrière:
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Votre modèle métier sera largement couplé avec le type de base de
|
||||
données (relationnelle, indépendamment
|
||||
\item
|
||||
Votre couche de présentation sera surtout disponible au travers d'un
|
||||
navigateur
|
||||
\item
|
||||
Les droits d'accès et permissions seront en grosse partie gérés par le
|
||||
frameworks
|
||||
\item
|
||||
La sécurité dépendra de votre habilité à suivre les versions
|
||||
\item
|
||||
Et les fonctionnalités complémentaires (que vous n'aurez pas voulu/eu
|
||||
le temps de développer) dépendront de la bonne volonté de la
|
||||
communauté
|
||||
\end{itemize}
|
||||
|
||||
Le point à comprendre ici n'est pas que "Django, c'est mal", mais qu'une
|
||||
fois que vous aurez défini la politique, les règles métiers, les données
|
||||
critiques et entités, et que vous aurez fait le choix de développer en
|
||||
âme et conscience votre nouvelle création en utilisant Django, vous
|
||||
serez bon gré mal gré, contraint de continuer avec. Cette décision ne
|
||||
sera pas irrévocable, mais difficile à contourner.
|
||||
|
||||
\begin{quote}
|
||||
At some point in their history most DevOps organizations were hobbled by
|
||||
tightly-coupled, monolithic architectures that while extremely
|
||||
successfull at helping them achieve product/market fit - put them at
|
||||
risk of organizational failure once they had to operate at scale (e.g.
|
||||
eBay's monolithic C++ application in 2001, Amazon's monolithic OBIDOS
|
||||
application in 2001, Twitter's monolithic Rails front-end in 2009, and
|
||||
LinkedIn's monolithic Leo application in 2011). In each of these cases,
|
||||
they were able to re-architect their systems and set the stage not only
|
||||
to survice, but also to thrise and win in the marketplace.
|
||||
|
||||
\cite[182]{devops_handbook}
|
||||
\end{quote}
|
||||
|
||||
Ceci dit, Django compense ses contraintes en proposant énormément de
|
||||
flexibilité et de fonctionnalités \textbf{out-of-the-box}, c'est-à-dire
|
||||
que vous pourrez sans doute avancer vite et bien jusqu'à un point de
|
||||
rupture, puis revoir la conception et réinvestir à ce moment-là, mais en
|
||||
toute connaissance de cause.
|
||||
|
||||
\begin{quote}
|
||||
When any of the external parts of the system become obsolete, such as
|
||||
the database, or the web framework, you can replace those obsolete
|
||||
elements with a minimum of fuss.
|
||||
|
||||
--- Robert C. Martin Clean Architecture
|
||||
\end{quote}
|
||||
|
||||
Avec Django, la difficulté à se passer du framework va consister à
|
||||
basculer vers «~autre chose~» et a remplacer chacune des tentacules qui
|
||||
aura pousser partout dans l'application.
|
||||
|
||||
A noter que les services et les «~architectures orientées services~» ne
|
||||
sont jamais qu'une définition d'implémentation des frontières, dans la
|
||||
mesure où un service n'est jamais qu'une fonction appelée au travers
|
||||
d'un protocole (rest, soap, \ldots\hspace{0pt}). Une application
|
||||
monolotihique sera tout aussi fonctionnelle qu'une application découpée
|
||||
en microservices. \cite[243]{clean_architecture}
|
||||
|
||||
\section{Inversion de dépendances}
|
||||
|
||||
Dans la partie SOLID, nous avons évoqué plusieurs principes de
|
||||
développement. Django est un framework qui évolue, et qui a pu présenter
|
||||
certains problèmes liés à l'un de ces principes.
|
||||
|
||||
Les link:release
|
||||
notes{[}\url{https://docs.djangoproject.com/en/2.0/releases/2.0/}{]} de
|
||||
Django 2.0 date de décembre 2017; parmi ces notes, l'une d'elles cite
|
||||
l'abandon du support d'link:Oracle
|
||||
11.2{[}\url{https://docs.djangoproject.com/en/2.0/releases/2.0/\#dropped-support-for-oracle-11-2}{]}.
|
||||
En substance, cela signifie que le framework se chargeait lui-même de
|
||||
construire certaines parties de requêtes, qui deviennent non
|
||||
fonctionnelles dès lors que l'on met le framework ou le moteur de base
|
||||
de données à jour. Réécrit, cela signifie que:
|
||||
|
||||
\begin{enumerate}
|
||||
\def\labelenumi{\arabic{enumi}.}
|
||||
\item
|
||||
Si vos données sont stockées dans un moteur géré par Oracle 11.2, vous
|
||||
serez limité à une version 1.11 de Django
|
||||
\item
|
||||
Tandis que si votre moteur est géré par une version ultérieure, le
|
||||
framework pourra être mis à jour.
|
||||
\end{enumerate}
|
||||
|
||||
Nous sommes dans un cas concret d'inversion de dépendances ratée: le
|
||||
framework (et encore moins vos politiques et règles métiers) ne
|
||||
devraient pas avoir connaissance du moteur de base de données. Pire, vos
|
||||
politiques et données métiers ne devraient pas avoir connaissance
|
||||
\textbf{de la version} du moteur de base de données.
|
||||
|
||||
En conclusion, le choix d'une version d'un moteur technique (\textbf{la
|
||||
base de données}) a une incidence directe sur les fonctionnalités mises
|
||||
à disposition par votre application, ce qui va à l'encontre des 12
|
||||
facteurs (et des principes de développement).
|
||||
|
||||
Ce point sera rediscuté par la suite, notamment au niveau de l'épinglage
|
||||
des versions, de la reproduction des environnements et de
|
||||
l'interdépendance entre des choix techniques et fonctionnels.
|
||||
|
||||
\section{Conclusions}
|
||||
|
||||
\begin{quote}
|
||||
La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.
|
||||
|
||||
-- Antoine de Saint-Exupéry
|
||||
\end{quote}
|
||||
|
||||
Il est impossible de se projeter dans le futur d'une application: il est impossible d'imaginer les modifications qui seront demandées par les utilisateurs, de se projeter dans l'évolution d'un langage, dans les nécessités d'intégration de certaines librairies ou dans le support-même de certaines fonctionnalités par les navigateurs Web.
|
||||
Ce sont des choses qui viennent avec l'expérience (ou avec la tordure d'esprit \footnote{Si, ça existe}).
|
||||
Cela rejoint le fameux "YAGNI\index{YAGNI}" dont nous parlions plus tôt: il est inutile de vouloir développer absolument toutes les fonctionnalités qui pourraient un jour pouvoir être utilisées ou souhaitées, car cela complexifiera autant le code, que les déploiement, l'utilisabilité ou la compréhension que les utilisateurs pourront avoir de votre application. \cite{rework}
|
||||
|
||||
Il est impossible d'imaginer ou de se projeter dans tous les éléments qui pourraient devoir être modifiés après que votre a
|
||||
En ayant connaissance de toutes les choses qui pourraient être modifiées par la suite,
|
||||
l’idée est de pousser le développement jusqu’au point où un service pourrait être nécessaire.
|
||||
A ce stade, l’architecture nécessitera des modifications, mais aura déjà intégré le fait que
|
||||
cette possibilité existe. Nous n’allons donc pas jusqu’au point où le service doit être créé
|
||||
(même s’il peut ne pas être nécessaire), ni à l’extrême au fait d’ignorer qu’un service
|
||||
pourrait être nécessaire, mais nous aboutissons à une forme de compromis. Une forme
|
||||
de comportement de Descartes, qui ne croit pas en Dieu, mais qui envisage quand même
|
||||
cette possibilité, ce qui lui ouvre le maximum de portes.
|
||||
|
|
@ -0,0 +1,192 @@
|
|||
\chapter{Introduction}
|
||||
|
||||
\begin{quote}
|
||||
The only way to go fast, is to go well
|
||||
|
||||
--- Robert C. Martin
|
||||
\end{quote}
|
||||
|
||||
Nous n'allons pas vous mentir: il existe enormément de tutoriaux très
|
||||
bien réalisés sur "\emph{Comment réaliser une application Django}" et
|
||||
autres "\emph{Déployer votre code en 2 minutes}". Nous nous disions
|
||||
juste que ces tutoriaux restaient relativement haut-niveaux et se
|
||||
limitaient à un contexte donné, sans réellement préparer à la
|
||||
maintenance et au suivi de l'application nouvellement développée.
|
||||
|
||||
L'idée du texte ci-dessous est de jeter les bases d'un bon
|
||||
développement, en survolant l'ensemble des outils permettant de suivre
|
||||
des lignes directrices reconnues, de maintenir une bonne qualité de code
|
||||
au travers des différentes étapes menant jusqu'au déploiement et de
|
||||
s'assurer du maintient correct de la base de code, en permettant à
|
||||
n'importe qui de reprendre ce qui aura déjà été écrit.
|
||||
|
||||
Ces idées ne s'appliquent pas uniquement à Django et à son cadre de
|
||||
travail, ni même au langage Python. Ces deux sujets sont cependant de
|
||||
bons candidats et leur cadre de travail est bien défini, documenté et
|
||||
suffisamment flexible.
|
||||
|
||||
Django se présente comme un \emph{Framework Web pour perfectionnistes
|
||||
ayant des deadlines} \cite{django} et suit ces quelques principes
|
||||
\cite{django_design_philosophies}:
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Faible couplage et forte cohésion, pour que chaque composant dispose
|
||||
de son indépendance, en n'ayant aucune connaissance des autres couches
|
||||
applicatives. Ainsi, le moteur de rendu ne connait absolument rien
|
||||
l'existence du moteur de base de données, tout comme le système de
|
||||
vues ne sait pas quel moteur de rendu est utilisé.
|
||||
\item
|
||||
Plus de fonctionnalités avec moins de code: chaque application Django
|
||||
doit utiliser le moins de code possible
|
||||
\item
|
||||
\emph{Don't repeat yourself}, chaque concept ou morceau de code ne
|
||||
doit être présent qu'à un et un seul endroit de vos dépôts.
|
||||
\item
|
||||
Rapidité du développement, en masquant les aspects fastidieux du
|
||||
développement web actuel
|
||||
\end{itemize}
|
||||
|
||||
Mis côte à côte, le suivi de ces principes permet une bonne stabilité du
|
||||
projet à moyen et long terme.
|
||||
|
||||
Comme nous le verrons par la suite, et sans être parfait, Django offre
|
||||
une énorme flexibilité qui permet de se laisser le maximum d'options
|
||||
ouvertes tout en permettant d'expérimenter facilement plusieurs pistes,
|
||||
jusqu'au moment de prendre une vraie décision. Dans la majorité des cas
|
||||
problématiques pouvant être rencontrés lors du développement d'une
|
||||
application Web, Django proposera une solution pragmatique,
|
||||
compréhensible et facile à mettre en place. En résumé de ce paragraphe,
|
||||
pour tout problème commun, vous disposerez d'une solution logique. Tout
|
||||
pour plaire à n'importe quel directeur IT.
|
||||
|
||||
\textbf{Dans la première partie}, nous verrons comment partir d'un
|
||||
environnement sain, comment le configurer correctement, comment
|
||||
installer Django de manière isolée et comment démarrer un nouveau
|
||||
projet. Nous verrons rapidement comment gérer les dépendances, les
|
||||
versions et comment appliquer et suivre un score de qualité de notre
|
||||
code. Ces quelques points pourront être appliqués pour n'importe quel
|
||||
langage ou cadre de travail. Nous verrons aussi que la configuration
|
||||
proposée par défaut par le framework n'est pas idéale dans la majorité
|
||||
des cas.
|
||||
|
||||
Pour cela, nous présenterons différents outils, la rédaction de tests
|
||||
unitaires et d'intégration pour limiter les régressions, les règles de
|
||||
nomenclature et de contrôle du contenu, comment partir d'un squelette
|
||||
plus complet, ainsi que les bonnes étapes à suivre pour arriver à un
|
||||
déploiement rapide et fonctionnel avec peu d'efforts.
|
||||
|
||||
A la fin de cette partie, vous disposerez d'un code propre et d'un
|
||||
projet fonctionnel, bien qu'encore un peu inutile.
|
||||
|
||||
textbf{Dans la deuxième partie}, nous aborderons les grands principes
|
||||
de modélisation, en suivant les lignes de conduites du cadre de travail.
|
||||
Nous aborderons les concepts clés qui permettent à une application de
|
||||
rester maintenable, les formulaires, leurs validations, comment gérer
|
||||
les données en entrée, les migrations de données et l'administration.
|
||||
|
||||
\textbf{Dans la troisième partie}, nous détaillerons précisément les
|
||||
étapes de déploiement, avec la description et la configuration de
|
||||
l'infrastructure, des exemples concrets de mise à disposition sur deux
|
||||
distributions principales (Debian et CentOS), sur une \emph{*Plateform
|
||||
as a Service*}, ainsi que l'utilisation de Docker et Docker-Compose.
|
||||
|
||||
Nous aborderons également la supervision et la mise à jour d'une
|
||||
application existante, en respectant les bonnes pratiques
|
||||
d'administration système.
|
||||
|
||||
\textbf{Dans la quatrième partie}, nous aborderons les architectures
|
||||
typées \emph{entreprise}, les services et les différentes manières de
|
||||
structurer notre application pour faciliter sa gestion et sa
|
||||
maintenance, tout en décrivant différents types de scénarii, en fonction
|
||||
des consommateurs de données.
|
||||
|
||||
\textbf{Dans la cinquième partie}, nous mettrons ces concepts en
|
||||
pratique en présentant le développement en pratique de deux
|
||||
applications, avec la description de problèmes rencontrés et la solution
|
||||
qui a été choisie: définition des tables, gestion des utilisateurs,
|
||||
\ldots\hspace{0pt} et mise à disposition.
|
||||
|
||||
\subsection{Pour qui ?}
|
||||
|
||||
Avant tout, pour moi. Comme le disait le Pr Richard Feynman: "\emph{Si
|
||||
vous ne savez pas expliquer quelque chose simplement, c'est que vous ne
|
||||
l'avez pas compris}". \footnote{Et comme l'ajoutait Aurélie Jean dans de
|
||||
L'autre côté de la machine: \emph{"Si personne ne vous pose de
|
||||
questions suite à votre explication, c'est que vous n'avez pas été
|
||||
suffisamment clair !"} \cite{other_side}}
|
||||
|
||||
Ce livre s'adresse autant au néophyte qui souhaite se lancer dans le
|
||||
développement Web qu'à l'artisan qui a besoin d'un aide-mémoire et qui
|
||||
ne se rappelle plus toujours du bon ordre des paramètres, ou à l'expert
|
||||
qui souhaiterait avoir un aperçu d'une autre technologie que son domaine
|
||||
privilégié de compétences.
|
||||
|
||||
Beaucoup de concepts présentés peuvent être oubliés ou restés inconnus
|
||||
jusqu'au moment où ils seront réellement nécessaires. A ce moment-là,
|
||||
pour peu que votre mémoire ait déjà entraperçu le terme, il vous sera
|
||||
plus facile d'y revenir et de l'appliquer.
|
||||
|
||||
\subsection{Pour aller plus loin}
|
||||
|
||||
Il existe énormément de ressources, autant spécifiques à Django que plus
|
||||
généralistes. Il ne sera pas possible de toutes les détailler; faites un
|
||||
tour sur
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
\url{https://duckduckgo.com},
|
||||
\item
|
||||
\url{https://stackoverflow.com},
|
||||
\item
|
||||
\url{https://ycombinator.com},
|
||||
\item
|
||||
\url{https://lobste.rs/},
|
||||
\item
|
||||
\url{https://lecourrierduhacker.com/}
|
||||
\item
|
||||
ou \url{https://www.djangoproject.com/}.
|
||||
\end{itemize}
|
||||
|
||||
Restez curieux, ne vous enclavez pas dans une technologie en particulier
|
||||
et gardez une bonne ouverture d'esprit.
|
||||
|
||||
\subsection{Conventions}
|
||||
|
||||
Les notes indiquent des anecdotes.
|
||||
Les conseils indiquent des éléments utiles, mais pas spécialement
|
||||
indispensables.
|
||||
|
||||
Les notes importantes indiquent des éléments à retenir.
|
||||
|
||||
Ces éléments indiquent des points d'attention. Les retenir vous fera
|
||||
gagner du temps en débuggage.
|
||||
|
||||
Les avertissements indiquent un (potentiel) danger ou des éléments
|
||||
pouvant amener des conséquences pas spécialement sympathiques.
|
||||
|
||||
Les morceaux de code source seront présentés de la manière suivante:
|
||||
|
||||
\begin{listing}[htbp]
|
||||
\begin{minted}{Python}
|
||||
# <folder>/<fichier>.<extension>
|
||||
|
||||
def function(param):
|
||||
"""
|
||||
"""
|
||||
callback()
|
||||
\end{minted}
|
||||
\end{listing}
|
||||
|
||||
Chaque extrait de code reprendra
|
||||
|
||||
\begin{itemize}
|
||||
\item l'emplacement du fichier, présenté sous forme de commentaire (ligne 1),
|
||||
\item Des commentaires au niveau des fonctions et méthodes, si cela s'avère nécessaire
|
||||
\item Un surlignage sur les parties importantes ou récemment modifiées
|
||||
\end{itemize}
|
||||
|
||||
La plupart des commandes qui seront présentées dans ce livre le seront
|
||||
depuis un shell sous GNU/Linux. Certaines d'entre elles pourraient
|
||||
devoir être adaptées si vous utilisez un autre système d'exploitation
|
||||
(macOS) ou n'importe quelle autre grosse bouse commerciale.
|
||||
|
|
@ -1,3 +1,31 @@
|
|||
\chapter{Licence}
|
||||
|
||||
Ce travail est licencié sous Attribution-NonCommercial 4.0 International
|
||||
Attribution-NonCommercial 4.0 International
|
||||
|
||||
This license requires that reusers give credit to the creator. It allows
|
||||
reusers to distribute, remix, adapt, and build upon the material in any
|
||||
medium or format, for noncommercial purposes only.
|
||||
|
||||
You are free to:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Share} — copy and redistribute the material in any medium or format
|
||||
\item \textbf{Adapt} — remix, transform, and build upon the material
|
||||
\end{itemize}
|
||||
|
||||
Under the following terms:
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
\textbf{Attribution}: You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
|
||||
\item
|
||||
\textbf{NC}: Only noncommercial use of your work is permitted.
|
||||
Noncommercial means not primarily intended for or directed towards
|
||||
commercial advantage or monetary compensation.
|
||||
\end{itemize}
|
||||
|
||||
\url{https://creativecommons.org/licenses/by-nc/4.0/}
|
||||
|
||||
La seule exception concerne les morceaux de code (non attribués),
|
||||
disponibles sous licence \href{https://mit-license.org/}{MIT}.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
\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{Complexité cyclomatique}
|
||||
|
||||
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 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}
|
||||
\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}
|
||||
\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}
|
||||
\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{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.
|
||||
|
||||
\subsection{Lisibilité du code}
|
||||
|
||||
Il est important de noter que refactoriser un bloc pour en extraire une méthode n'améliorera pas la complexité cyclomatique globale de
|
||||
l'application.
|
||||
Nous visons ici une amélioration \textbf{locale}.
|
||||
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
\chapter{Poésie de la programmation}
|
||||
|
||||
\begin{quote}
|
||||
The primary cost of maintenance is in spelunking and risk
|
||||
\cite[139]{clean_architecture}
|
||||
|
||||
--- Robert C. Martin
|
||||
\end{quote}
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
\chapter{Remerciements}
|
||||
|
||||
198
sources/main.tex
198
sources/main.tex
|
|
@ -4,6 +4,9 @@
|
|||
\usepackage{csquotes}
|
||||
\usepackage{hyperref}
|
||||
\usepackage{setspace}
|
||||
\usepackage{listing}
|
||||
\usepackage{minted}
|
||||
|
||||
\onehalfspacing
|
||||
|
||||
\makeindex
|
||||
|
|
@ -21,195 +24,21 @@
|
|||
|
||||
\include{chapters/licence.tex}
|
||||
|
||||
|
||||
\chapter{Introduction}
|
||||
|
||||
\begin{quote}
|
||||
The only way to go fast, is to go well
|
||||
|
||||
--- Robert C. Martin
|
||||
\end{quote}
|
||||
|
||||
Nous n'allons pas vous mentir: il existe enormément de tutoriaux très
|
||||
bien réalisés sur "\emph{Comment réaliser une application Django}" et
|
||||
autres "\emph{Déployer votre code en 2 minutes}". Nous nous disions
|
||||
juste que ces tutoriaux restaient relativement haut-niveaux et se
|
||||
limitaient à un contexte donné, sans réellement préparer à la
|
||||
maintenance et au suivi de l'application nouvellement développée.
|
||||
|
||||
L'idée du texte ci-dessous est de jeter les bases d'un bon
|
||||
développement, en survolant l'ensemble des outils permettant de suivre
|
||||
des lignes directrices reconnues, de maintenir une bonne qualité de code
|
||||
au travers des différentes étapes menant jusqu'au déploiement et de
|
||||
s'assurer du maintient correct de la base de code, en permettant à
|
||||
n'importe qui de reprendre ce qui aura déjà été écrit.
|
||||
|
||||
Ces idées ne s'appliquent pas uniquement à Django et à son cadre de
|
||||
travail, ni même au langage Python. Ces deux sujets sont cependant de
|
||||
bons candidats et leur cadre de travail est bien défini, documenté et
|
||||
suffisamment flexible.
|
||||
|
||||
Django se présente comme un \emph{Framework Web pour perfectionnistes
|
||||
ayant des deadlines} cite:{[}django{]} et suit ces quelques principes
|
||||
cite:{[}django\_design\_philosophies{]}:
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
Faible couplage et forte cohésion, pour que chaque composant dispose
|
||||
de son indépendance, en n'ayant aucune connaissance des autres couches
|
||||
applicatives. Ainsi, le moteur de rendu ne connait absolument rien
|
||||
l'existence du moteur de base de données, tout comme le système de
|
||||
vues ne sait pas quel moteur de rendu est utilisé.
|
||||
\item
|
||||
Plus de fonctionnalités avec moins de code: chaque application Django
|
||||
doit utiliser le moins de code possible
|
||||
\item
|
||||
\emph{Don't repeat yourself}, chaque concept ou morceau de code ne
|
||||
doit être présent qu'à un et un seul endroit de vos dépôts.
|
||||
\item
|
||||
Rapidité du développement, en masquant les aspects fastidieux du
|
||||
développement web actuel
|
||||
\end{itemize}
|
||||
|
||||
Mis côte à côte, le suivi de ces principes permet une bonne stabilité du
|
||||
projet à moyen et long terme.
|
||||
|
||||
Comme nous le verrons par la suite, et sans être parfait, Django offre
|
||||
une énorme flexibilité qui permet de se laisser le maximum d'options
|
||||
ouvertes tout en permettant d'expérimenter facilement plusieurs pistes,
|
||||
jusqu'au moment de prendre une vraie décision. Dans la majorité des cas
|
||||
problématiques pouvant être rencontrés lors du développement d'une
|
||||
application Web, Django proposera une solution pragmatique,
|
||||
compréhensible et facile à mettre en place. En résumé de ce paragraphe,
|
||||
pour tout problème commun, vous disposerez d'une solution logique. Tout
|
||||
pour plaire à n'importe quel directeur IT.
|
||||
|
||||
\textbf{Dans la première partie}, nous verrons comment partir d'un
|
||||
environnement sain, comment le configurer correctement, comment
|
||||
installer Django de manière isolée et comment démarrer un nouveau
|
||||
projet. Nous verrons rapidement comment gérer les dépendances, les
|
||||
versions et comment appliquer et suivre un score de qualité de notre
|
||||
code. Ces quelques points pourront être appliqués pour n'importe quel
|
||||
langage ou cadre de travail. Nous verrons aussi que la configuration
|
||||
proposée par défaut par le framework n'est pas idéale dans la majorité
|
||||
des cas.
|
||||
|
||||
Pour cela, nous présenterons différents outils, la rédaction de tests
|
||||
unitaires et d'intégration pour limiter les régressions, les règles de
|
||||
nomenclature et de contrôle du contenu, comment partir d'un squelette
|
||||
plus complet, ainsi que les bonnes étapes à suivre pour arriver à un
|
||||
déploiement rapide et fonctionnel avec peu d'efforts.
|
||||
|
||||
A la fin de cette partie, vous disposerez d'un code propre et d'un
|
||||
projet fonctionnel, bien qu'encore un peu inutile.
|
||||
|
||||
\textbf{Dans la deuxième partie}, nous aborderons les grands principes
|
||||
de modélisation, en suivant les lignes de conduites du cadre de travail.
|
||||
Nous aborderons les concepts clés qui permettent à une application de
|
||||
rester maintenable, les formulaires, leurs validations, comment gérer
|
||||
les données en entrée, les migrations de données et l'administration.
|
||||
|
||||
\textbf{Dans la troisième partie}, nous détaillerons précisément les
|
||||
étapes de déploiement, avec la description et la configuration de
|
||||
l'infrastructure, des exemples concrets de mise à disposition sur deux
|
||||
distributions principales (Debian et CentOS), sur une \emph{*Plateform
|
||||
as a Service*}, ainsi que l'utilisation de Docker et Docker-Compose.
|
||||
|
||||
Nous aborderons également la supervision et la mise à jour d'une
|
||||
application existante, en respectant les bonnes pratiques
|
||||
d'administration système.
|
||||
|
||||
\textbf{Dans la quatrième partie}, nous aborderons les architectures
|
||||
typées \emph{entreprise}, les services et les différentes manières de
|
||||
structurer notre application pour faciliter sa gestion et sa
|
||||
maintenance, tout en décrivant différents types de scénarii, en fonction
|
||||
des consommateurs de données.
|
||||
|
||||
\textbf{Dans la cinquième partie}, nous mettrons ces concepts en
|
||||
pratique en présentant le développement en pratique de deux
|
||||
applications, avec la description de problèmes rencontrés et la solution
|
||||
qui a été choisie: définition des tables, gestion des utilisateurs,
|
||||
\ldots\hspace{0pt} et mise à disposition.
|
||||
|
||||
\hypertarget{_pour_qui}{%
|
||||
\subsection{Pour qui ?}\label{_pour_qui}}
|
||||
|
||||
Avant tout, pour moi. Comme le disait le Pr Richard Feynman: "\emph{Si
|
||||
vous ne savez pas expliquer quelque chose simplement, c'est que vous ne
|
||||
l'avez pas compris}". \footnote{Et comme l'ajoutait Aurélie Jean dans de
|
||||
L'autre côté de la machine: \emph{"Si personne ne vous pose de
|
||||
questions suite à votre explication, c'est que vous n'avez pas été
|
||||
suffisamment clair !"} cite:{[}other\_side}{]}
|
||||
|
||||
Ce livre s'adresse autant au néophyte qui souhaite se lancer dans le
|
||||
développement Web qu'à l'artisan qui a besoin d'un aide-mémoire et qui
|
||||
ne se rappelle plus toujours du bon ordre des paramètres, ou à l'expert
|
||||
qui souhaiterait avoir un aperçu d'une autre technologie que son domaine
|
||||
privilégié de compétences.
|
||||
|
||||
Beaucoup de concepts présentés peuvent être oubliés ou restés inconnus
|
||||
jusqu'au moment où ils seront réellement nécessaires. A ce moment-là,
|
||||
pour peu que votre mémoire ait déjà entraperçu le terme, il vous sera
|
||||
plus facile d'y revenir et de l'appliquer.
|
||||
|
||||
\hypertarget{_pour_aller_plus_loin}{%
|
||||
\subsection{Pour aller plus loin}\label{_pour_aller_plus_loin}}
|
||||
|
||||
Il existe énormément de ressources, autant spécifiques à Django que plus
|
||||
généralistes. Il ne sera pas possible de toutes les détailler; faites un
|
||||
tour sur
|
||||
|
||||
\begin{itemize}
|
||||
\item
|
||||
\url{https://duckduckgo.com},
|
||||
\item
|
||||
\url{https://stackoverflow.com},
|
||||
\item
|
||||
\url{https://ycombinator.com},
|
||||
\item
|
||||
\url{https://lobste.rs/},
|
||||
\item
|
||||
\url{https://lecourrierduhacker.com/}
|
||||
\item
|
||||
ou \url{https://www.djangoproject.com/}.
|
||||
\end{itemize}
|
||||
|
||||
Restez curieux, ne vous enclavez pas dans une technologie en particulier
|
||||
et gardez une bonne ouverture d'esprit.
|
||||
|
||||
\hypertarget{_conventions}{%
|
||||
\subsection{Conventions}\label{_conventions}}
|
||||
|
||||
Les notes indiquent des anecdotes.
|
||||
|
||||
Les conseils indiquent des éléments utiles, mais pas spécialement
|
||||
indispensables.
|
||||
|
||||
Les notes importantes indiquent des éléments à retenir.
|
||||
|
||||
Ces éléments indiquent des points d'attention. Les retenir vous fera
|
||||
gagner du temps en débuggage.
|
||||
|
||||
Les avertissements indiquent un (potentiel) danger ou des éléments
|
||||
pouvant amener des conséquences pas spécialement sympathiques.
|
||||
|
||||
Les morceaux de code source seront présentés de la manière suivante:
|
||||
|
||||
\chapter{Remerciements}
|
||||
|
||||
\include{chapters/introduction.tex}
|
||||
|
||||
\tableofcontents
|
||||
\listoffigures
|
||||
\listoftables
|
||||
|
||||
\mainmatter
|
||||
\part{Environnement et méthodes de travail}
|
||||
|
||||
\chapter{Poésie de la programmation}
|
||||
Text
|
||||
\chapter{Fiabilité, évolutivité et maintenabilité}
|
||||
\include{parts/environment.tex}
|
||||
|
||||
\chapter{Eléments d'architecture}
|
||||
\include{chapters/programming-poetry.tex}
|
||||
|
||||
\include{chapters/maintenability.tex}
|
||||
|
||||
\include{chapters/architecture.tex}
|
||||
|
||||
\chapter{Le langage Python}
|
||||
|
||||
|
|
@ -286,8 +115,13 @@ Text
|
|||
|
||||
\backmatter
|
||||
|
||||
\part{Ressources}
|
||||
|
||||
\printindex
|
||||
|
||||
\bibliography{bibiography.bib}
|
||||
\bibliography{references}
|
||||
\bibliographystyle{plainnat}
|
||||
|
||||
\include{chapters/thanks.tex}
|
||||
|
||||
\end{document}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,85 @@
|
|||
\part{Environnement et méthodes de travail}
|
||||
|
||||
\begin{quote}
|
||||
Make it work, make it right, make it fast
|
||||
|
||||
--- Kent Beck
|
||||
\end{quote}
|
||||
|
||||
En fonction de vos connaissances et compétences, la création d'une
|
||||
nouvelle application est uneé tape relativement facile à mettre en
|
||||
place. Le code qui permet de faire tourner cette application peut ne pas
|
||||
être élégant, voire buggé jusqu'à la moëlle, il pourra fonctionner et
|
||||
faire "preuve de concept".
|
||||
|
||||
Les problèmes arriveront lorsqu'une nouvelle demande sera introduite,
|
||||
lorsqu'un bug sera découvert et devra être corrigé ou lorsqu'une
|
||||
dépendance cessera de fonctionner ou d'être disponible. Or, une
|
||||
application qui n'évolue pas, meurt. Tout application est donc destinée,
|
||||
soit à être modifiée, corrigée et suivie, soit à déperrir et à être
|
||||
délaissée par ses utilisateurs. Et c'est juste cette maintenance qui est
|
||||
difficile.
|
||||
|
||||
L'application des principes présentés et agrégés ci-dessous permet
|
||||
surtout de préparer correctement tout ce qui pourra arriver, sans aller
|
||||
jusqu'au « \textbf{You Ain't Gonna Need It} » (ou \textbf{YAGNI\index{YAGNI}}), qui
|
||||
consiste à surcharger tout développement avec des fonctionnalités non
|
||||
demandées, juste « au cas ou ». Pour paraphraser une partie de
|
||||
l'introduction du livre \emph{Clean Architecture}
|
||||
\cite{clean_architecture}:
|
||||
|
||||
\begin{quote}
|
||||
Getting software right is hard: it takes knowledge and skills that most
|
||||
young programmers don't take the time to develop. It requires a level of
|
||||
discipline and dedication that most programmers never dreamed they'd
|
||||
need. Mostly, it takes a passion for the craft and the desire to be a
|
||||
professional.
|
||||
|
||||
--- Robert C. Martin Clean Architecture
|
||||
\end{quote}
|
||||
|
||||
Le développement d'un logiciel nécessite une rigueur d'exécution et des
|
||||
connaissances précises dans des domaines extrêmement variés. Il
|
||||
nécessite également des intentions, des (bonnes) décisions et énormément
|
||||
d'attention. Indépendamment de l'architecture que vous aurez choisie,
|
||||
des technologies que vous aurez patiemment évaluées et mises en place,
|
||||
une architecture et une solution peuvent être cassées en un instant, en
|
||||
même temps que tout ce que vous aurez construit, dès que vous en aurez
|
||||
détourné le regard.
|
||||
|
||||
Un des objectifs ici est de placer les barrières et les gardes-fous (ou
|
||||
plutôt, les "\textbf{garde-vous}"), afin de péréniser au maximum les
|
||||
acquis, stabiliser les bases de tous les environnements (du
|
||||
développement à la production) qui accueilliront notre application et
|
||||
fiabiliser ainsi chaque étape de communication.
|
||||
|
||||
Dans cette partie-ci, nous parlerons de \textbf{méthodes de travail},
|
||||
avec comme objectif d'éviter que l'application ne tourne que sur notre
|
||||
machine et que chaque déploiement ne soit une plaie à gérer. Chaque mise
|
||||
à jour doit être réalisable de la manière la plus simple possible, et
|
||||
chaque étape doit être rendue la plus automatisée/automatisable
|
||||
possible. Dans son plus simple élément, une application pourrait être
|
||||
mise à jour simplement en envoyant son code sur un dépôt centralisé: ce
|
||||
déclencheur doit démarrer une chaîne de vérification
|
||||
d'utilisabilité/fonctionnalités/débuggabilité/sécurité, pour
|
||||
immédiatement la mettre à disposition de nouveaux utilisateurs si toute
|
||||
la chaîne indique que tout est OK. D'autres mécanismes fonctionnent
|
||||
également, mais au plus les actions nécessitent d'actions humaines,
|
||||
voire d'intervenants humains, au plus la probabilité qu'un problème
|
||||
survienne est grande.
|
||||
|
||||
Dans une version plus manuelle, cela pourrait se résumer à ces trois
|
||||
étapes (la dernière étant formellement facultative):
|
||||
|
||||
\begin{enumerate}
|
||||
\def\labelenumi{\arabic{enumi}.}
|
||||
\item
|
||||
Démarrer un script,
|
||||
\item
|
||||
Prévoir un rollback si cela plante (et si cela a planté, préparer un
|
||||
post-mortem de l'incident pour qu'il ne se produise plus)
|
||||
\item
|
||||
Se préparer une tisane en regardant nos flux RSS (pour peu que cette
|
||||
technologie existe encore\ldots\hspace{0pt}).
|
||||
\end{enumerate}
|
||||
|
||||
|
|
@ -0,0 +1,127 @@
|
|||
@book{clean_architecture,
|
||||
title = {Clean Architecture, A Craftman's Guide to Software Structure and Design},
|
||||
author = {Robert C. Martin},
|
||||
publisher = {Pearson},
|
||||
isbn = {978-0-13-449416-6},
|
||||
year = {2018},
|
||||
type = {Book}
|
||||
}
|
||||
@book{
|
||||
other_side,
|
||||
author = {Aurélie Jean},
|
||||
title = {De l'autre côté de la machine},
|
||||
year = {2020},
|
||||
publisher = {Editions de l'Observatoire},
|
||||
}
|
||||
@book{clean_code,
|
||||
title = {Clean Code, a Handbook of Agile Software Craftmanship},
|
||||
author = {Robert C. Martin},
|
||||
publisher = {Pearson},
|
||||
editor = {Addison-Wesley},
|
||||
year = {2009},
|
||||
type = {Book}
|
||||
}
|
||||
@book{expert_python,
|
||||
title = {Expert Python Programming},
|
||||
author = {Jaworski, Michal and Ziadé, Tarek},
|
||||
publisher = {Packt Publishing},
|
||||
year = {2021},
|
||||
edition = {4th edition},
|
||||
type = {Book}
|
||||
}
|
||||
@book{devops_handbook,
|
||||
title = {The DevOps Handbook, How to create World-class Agility, Reliability and Security in Technology Organizations},
|
||||
author = {Gene Kim and Jez Humble and Patrick Debois and John Willis},
|
||||
publisher = {IT Revolution},
|
||||
year = {2016},
|
||||
type = {Book}
|
||||
}
|
||||
@book{boring_stuff,
|
||||
title = {Automate the Boring Stuff with Python},
|
||||
booktitle = {Practical Programming For Total Beginners},
|
||||
author = {Al Sweigart},
|
||||
year = {2020},
|
||||
editor = {No Starch Press},
|
||||
publisher = {William Pollock},
|
||||
edition = {2nd edition}
|
||||
}
|
||||
@book{maintainable_software,
|
||||
title = {Building Maintainable Software},
|
||||
booktitle = {Ten Guidelines for Future-Proof Code},
|
||||
author = {Joost Visser},
|
||||
year = {2016},
|
||||
edition = {C-Sharp Edition, first edition},
|
||||
publisher = {O'Reilly Media, Inc.},
|
||||
isbn = {978-1-491-95452-2},
|
||||
url = {http://shop.oreilly.com/product/0636920049555.do}
|
||||
}
|
||||
@book{two_scoops_of_django,
|
||||
author = {Daniel Roy and Andrey Greenfeld},
|
||||
title = {Two Scoops of Django},
|
||||
year = {2021},
|
||||
}
|
||||
@book{django_design_patterns,
|
||||
year = {2015},
|
||||
publisher = {Packt Publishing}
|
||||
}
|
||||
@book{unix_philosophy,
|
||||
author = {Eric S. Raymond},
|
||||
year = {2004},
|
||||
title = {Basics of the Unix Philosophy, The Art of Unix Programming},
|
||||
publisher = {Addison-Wesley Professional},
|
||||
isbn = {0-13-142901-9},
|
||||
}
|
||||
@book{data_intensive,
|
||||
title = {Designing Data Intensive Applications},
|
||||
booktitle = {The Big Ideas Behind Reliable, Scalable and Maintainable Systems},
|
||||
year = {2017},
|
||||
author = {Martin Kleppmann},
|
||||
publisher = {O'Reilly},
|
||||
isbn = {978-1-449-37332-0},
|
||||
release = {Fifteenth release - 2021-03-26}
|
||||
}
|
||||
@book{rework,
|
||||
title = {Rework},
|
||||
author = {David Heinemeier Hansson and Jason Fried},
|
||||
year = {2010},
|
||||
isbn = {0307463745},
|
||||
publisher = {Currency}
|
||||
}
|
||||
@misc{
|
||||
django,
|
||||
title = {The web framework for perfectionists with deadlines},
|
||||
url = {https://www.djangoproject.com/}
|
||||
}
|
||||
@misc{
|
||||
django_design_philosophies,
|
||||
title = {Design Philosophies},
|
||||
url = {https://docs.djangoproject.com/en/dev/misc/design-philosophies/}
|
||||
}
|
||||
@misc{
|
||||
consider_sqlite,
|
||||
title = {Consider SQLite},
|
||||
year = {2021},
|
||||
url = {https://blog.wesleyac.com/posts/consider-sqlite}
|
||||
}
|
||||
@misc{agiliq_admin,
|
||||
title = {Django Admin Cookbook, How to do things with Django admin},
|
||||
year = {2018},
|
||||
url = {https://books.agiliq.com/projects/django-admin-cookbook/en/latest/}
|
||||
}
|
||||
@misc{agiliq_multi_tenant,
|
||||
title = {Building Multi Tenant Applications with Django},
|
||||
year = {2018},
|
||||
url = {https://books.agiliq.com/projects/django-multi-tenant/en/latest/},
|
||||
}
|
||||
@misc{simple_is_better_than_complex,
|
||||
author = {Vitor Freitas},
|
||||
title = {A Complete Beginner's Guide to Django},
|
||||
year = {2017},
|
||||
note = {Last visited in 2021},
|
||||
url = {https://simpleisbetterthancomplex.com/series/beginners-guide/1.11/}
|
||||
}
|
||||
@misc{gnu_linux_mag_hs_104,
|
||||
title = {Les cinq règles pour écrire du code maintenable},
|
||||
year = {2019},
|
||||
url = {https://boutique.ed-diamond.com/les-hors-series/1402-gnulinux-magazine-hs-104.html}
|
||||
}
|
||||
Loading…
Reference in New Issue