Services...
continuous-integration/drone/push Build is passing Details

This commit is contained in:
Fred Pauchet 2022-06-03 21:10:05 +02:00
parent 09a1cd0506
commit 224ed5a0c2
6 changed files with 26 additions and 1 deletions

5
annexes/snippets.tex Normal file
View File

@ -0,0 +1,5 @@
\appendix{Snippets}
\section{Nettoyage de chaînes de caractères}
Basically, NFC is how you normalize text that's meant to be displayed to a user on the web, and NFKC is how you normalize text that's used to for searching and guaranteeing uniqueness. \cite{django_for_startup_founders}

View File

@ -2,7 +2,7 @@
\url{https://news.ycombinator.com/item?id=30221016\&utm_term=comment} vs
Django Rest Framework
Django Rest Framework vs Marshmallow
Expliquer pourquoi une API est intéressante/primordiale/la première chose à réaliser/le cadet de nos soucis:

View File

@ -1,5 +1,9 @@
\chapter{Intégration continue / Déploiement Continu}
\begin{quote}
New code should never go live without first being audited for correctness and security. \cite{django_for_startup_founders}
\end{quote}
https://circleci.com/pricing/
github actions

View File

@ -638,6 +638,19 @@ Par défaut, le gestionnaire est accessible au travers de la propriété
filtres bien spécifiques.
\end{enumerate}
\section{Services}
Une des recommandations que l'on peut lire pour django consiste à créer des \texttt{fat models}.
Le soucis, c'est que l'on arrive rapidement à créer des classes de plusieurs centaines de lignes, qui dialoguent directement avec la base de données.
Un des patterns proposé par GoF est d'avoir des \texttt{repositories}, qui consistent à isoler l'accès à la base de données en utilisant des DTO.
Le soucis (que nous avons déjà vu avec Django) est que l'ORM est de type ActiveRecords, et donc à l'opposé de ces DTO (qui doivent être bêtes comme chou):
\begin{quote}
The "Fat Models" recommendation is one of the most destructive in my opinion: https://django-best-practices.readthedocs.io/en/latest/appli..., along with Django Rest Framework "Model Serializers". A JSON serializer that talks directly to the database is just madness.
-- \url{https://news.ycombinator.com/item?id=23322880}
\end{quote}
\section{Refactoring et héritages}
On constate que plusieurs classes possèdent les mêmes propriétés \texttt{created\_at} et \texttt{updated\_at}, initialisées aux mêmes valeurs.

View File

@ -99,6 +99,7 @@
\include{annexes/grafana.tex}
\include{annexes/sonar.tex}
\include{annexes/snippets.tex}
\chapter{Fly.io}

View File

@ -13,6 +13,8 @@ Les problèmes arriveront lorsqu'une nouvelle demande sera introduite, lorsqu'un
Or, une application qui n'évolue pas, meurt.
Toute 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.
Selon certaines études académiques et industrielles \cite[]{django_for_startup_founders}, 60 à 80\% du coût associé à n'importe quelle ligne de code correspond à de la maintenance de la ligne initialement écrite.
Ceci est dû à des bogues, à des modifications de fonctionnalités, à des dépendances qui évoluent, qui ne sont plus maintenues ou qui doivent être remplacées.
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}: