Complete references after reviewing each page
continuous-integration/drone/push Build is failing
Details
continuous-integration/drone/push Build is failing
Details
This commit is contained in:
parent
059d7c1f99
commit
c28d0b4cdb
|
|
@ -7,9 +7,14 @@ Cédric Declerfayt <jaguarondi27@gmail.com>; Fred Pauchet <fred@grimbox.be>
|
|||
:chapter-label: Chapitre
|
||||
:preface-title: Préface
|
||||
:bibtex-file: source/references.bib
|
||||
:bibtex-order: alphabetical
|
||||
:bibtex-throw: true
|
||||
:source-highlighter: rouge
|
||||
:icons: font
|
||||
|
||||
"The only way to go fast, is to go well"
|
||||
-- Robert C. Martin
|
||||
|
||||
Nous n'allons pas vous mentir: il existe enormément de tutoriaux très bien réalisés sur "_Comment réaliser une application Django_" et autres "_Déployer votre code en 2 minutes_".
|
||||
Nous nous disions juste que ces tutoriaux restaient relativement haut-niveaux et se limitaient à un contexte donné, et ne préparaient pas réellement à la maintenance et au suivi d'une application.
|
||||
|
||||
|
|
@ -46,7 +51,23 @@ Nous aborderons les concepts clés qui permettent à une application de rester m
|
|||
|
||||
*Dans la quatrième partie*, nous mettrons ces concepts en pratique en présentant le développement de deux "vraies" applications: définition des tables, gestion des utilisateurs, ... et mise à disposition!
|
||||
|
||||
Et tout ça à un seul et même endroit.footnote:[Avec même un peu d'https://www.xkcd.com[XKCD]] et de Calvin & Hobbes dedans.
|
||||
footnote:[Avec même un peu d'https://www.xkcd.com[XKCD] et de Calvin & Hobbes dedans]
|
||||
|
||||
*Qui cela peut intéresser*
|
||||
|
||||
|
||||
*Ce que ce livre couvre*
|
||||
|
||||
|
||||
*Pour aller plus loin*
|
||||
|
||||
|
||||
*Conventions*
|
||||
|
||||
|
||||
*Let's keep in touch*
|
||||
|
||||
|
||||
|
||||
Bonne lecture.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ L’application des principes présentés et agrégés ci-dessous permet surtout
|
|||
sans aller jusqu’au « *You Ain't Gonna Need It* » (ou *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 _Clean Architecture_ cite:[clean_architecture]:
|
||||
|
||||
[quote, Robert C. Martin, Clean Architecture]
|
||||
[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.
|
||||
|
|
@ -34,11 +34,14 @@ 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 "*garde-vous*"), afin de péréniser au maximum les acquis, stabiliser les bases de tous les environnements (du développement à la production) qui pourraient accueillir notre application et fiabiliser les étapes de communication.
|
||||
|
||||
Dans cette partie, nous allons parler de *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:
|
||||
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émarrer un script,
|
||||
. 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)
|
||||
. se préparer une tisane en regardant nos flux RSS (si cette technologie existe encore...).
|
||||
Dans une version plus manuelle, cela pourrait se résumer à ces trois étapes (la dernière étant formellement facultative):
|
||||
|
||||
. Démarrer un script,
|
||||
. 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)
|
||||
. Se préparer une tisane en regardant nos flux RSS (pour peu que cette technologie existe encore...).
|
||||
|
||||
NOTE: 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)
|
||||
|
|
|
|||
|
|
@ -1,17 +1,17 @@
|
|||
== Python
|
||||
|
||||
Le langage https://www.python.org/[Python] est un https://docs.python.org/3/faq/general.html#what-is-python[langage de programmation] interprété, interactif, orienté objet (souvent), fonctionnel (parfois), open source, multi-plateformes, flexible, facile à apprendre et difficile à maîtriser.
|
||||
Le langage https://www.python.org/[Python] est un https://docs.python.org/3/faq/general.html#what-is-python[langage de programmation] interprété, interactif, amusant, orienté objet (souvent), fonctionnel (parfois), open source, multi-plateformes, flexible, facile à apprendre et difficile à maîtriser.
|
||||
|
||||
.https://xkcd.com/353/
|
||||
image::images/xkcd-353-python.png[]
|
||||
|
||||
A première vue, certains concepts restent difficiles à aborder: l'indentation définit l'étendue d'un bloc (classe, fonction, méthode, boucle, condition, ...), il n'y a pas de typage fort des variables et le compilateur n'est pas là pour assurer le filet de sécurité avant la mise en production (puisqu'il n'y a pas de compilateur 😛).
|
||||
A première vue, et suivants les autres langages que vous connaitriez ou auriez déjà abordé, certains concepts restent difficiles à aborder: l'indentation définit l'étendue d'un bloc (classe, fonction, méthode, boucle, condition, ...), il n'y a pas de typage fort des variables et le compilateur n'est pas là pour assurer le filet de sécurité avant la mise en production (puisqu'il n'y a pas de compilateur 😛).
|
||||
Et malgré ces quelques points, Python reste un langage généraliste accessible et "bon partout", et de pouvoir se reposer sur un écosystème stable et fonctionnel.
|
||||
|
||||
Il fonctionne avec un système d'améliorations basées sur des propositions: les PEP, ou "**Python Enhancement Proposal**".
|
||||
Chacune d'entre elles doit être approuvée par le http://fr.wikipedia.org/wiki/Benevolent_Dictator_for_Life[Benevolent Dictator For Life].
|
||||
|
||||
Si vous avez besoin d'un aide-mémoire ou d'une liste exhaustive des types et structures de données du langage, référez-vous au lien suivant: https://gto76.github.io/python-cheatsheet/[Python Cheat Sheet].
|
||||
|
||||
|
||||
NOTE: Le langage Python utilise un typage dynamique appelé https://fr.wikipedia.org/wiki/Duck_typing[*duck typing*]: "_When I see a bird that quacks like a duck, walks like a duck, has feathers and webbed feet and associates with ducks — I’m certainly going to assume that he is a duck_"
|
||||
Source: http://en.wikipedia.org/wiki/Duck_test[Wikipedia].
|
||||
|
|
@ -19,7 +19,20 @@ Source: http://en.wikipedia.org/wiki/Duck_test[Wikipedia].
|
|||
Les morceaux de code que vous trouverez ci-dessous seront développés pour Python3.9+ et Django 3.2+.
|
||||
Ils nécessiteront peut-être quelques adaptations pour fonctionner sur une version antérieure.
|
||||
|
||||
==== The Zen of Python
|
||||
|
||||
|
||||
=== Eléments de langage
|
||||
|
||||
En fonction de votre niveau d'apprentissage du langage, plusieurs ressources pourraient vous aider:
|
||||
|
||||
* *Pour les débutants*, https://automatetheboringstuff.com/[Automate the Boring Stuff with Python] cite:[boring_stuff], aka. _Practical Programming for Total Beginners_
|
||||
* *Pour un (gros) niveau au dessus* et pour un état de l'art du langage, nous ne pouvons que vous recommander le livre Expert Python Programming cite:[expert_python], qui aborde énormément d'aspects du langage en détails (mais pas toujours en profondeur): les différents types d'interpréteurs, les éléments de langage avancés, différents outils de productivité, métaprogrammation, optimisation de code, programmation orientée évènements, multithreading et concurrence, tests, ...
|
||||
A ce jour, c'est le concentré de sujets liés au langage le plus intéressant qui ait pu arriver entre nos mains.
|
||||
|
||||
En parallèle, si vous avez besoin d'un aide-mémoire ou d'une liste exhaustive des types et structures de données du langage, référez-vous au lien suivant: https://gto76.github.io/python-cheatsheet/[Python Cheat Sheet].
|
||||
|
||||
|
||||
=== The Zen of Python
|
||||
|
||||
[source,python]
|
||||
----
|
||||
|
|
@ -52,7 +65,7 @@ Namespaces are one honking great idea -- let's do more of those!
|
|||
----
|
||||
|
||||
|
||||
==== PEP8 - Style Guide for Python Code
|
||||
=== PEP8 - Style Guide for Python Code
|
||||
|
||||
La première PEP qui va nous intéresser est la https://www.python.org/dev/peps/pep-0008/[PEP 8 -- Style Guide for Python Code]. Elle spécifie comment du code Python doit être organisé ou formaté, quelles sont les conventions pour l’indentation, le nommage des variables et des classes, ...
|
||||
En bref, elle décrit comment écrire du code proprement, afin que d’autres développeurs puissent le reprendre facilement, ou simplement que votre base de code ne dérive lentement vers un seuil de non-maintenabilité.
|
||||
|
|
@ -78,7 +91,7 @@ $ pep8 . --statistics -qq
|
|||
Si vous ne voulez pas être dérangé sur votre manière de coder, et que vous voulez juste avoir un retour sur une analyse de votre code, essayez `pyflakes`: cette librairie analysera vos sources à la recherche de sources d'erreurs possibles (imports inutilisés, méthodes inconnues, etc.).
|
||||
|
||||
|
||||
==== PEP257 - Docstring Conventions
|
||||
=== PEP257 - Docstring Conventions
|
||||
|
||||
Python étant un langage interprété fortement typé, il est plus que conseillé, au même titre que les tests unitaires que nous verrons plus bas, de documenter son code.
|
||||
Cela impose une certaine rigueur, mais améliore énormément la qualité (et la reprise) du code par une tierce personne.
|
||||
|
|
@ -256,7 +269,7 @@ TODO: Voir si la sortie de pylint est obligatoirement 0 s'il y a un warning
|
|||
TODO: parler de `pylint --errors-only`
|
||||
|
||||
|
||||
==== Formatage de code
|
||||
=== Formatage de code
|
||||
|
||||
Nous avons parlé ci-dessous de style de codage pour Python (PEP8), de style de rédaction pour la documentation (PEP257), d'un _linter_ pour nous indiquer quels morceaux de code doivent absolument être revus, ...
|
||||
Reste que ces tâches sont [line-through]#parfois# (très) souvent fastidieuses: écrire un code propre et systématiquement cohérent est une tâche ardue.
|
||||
|
|
@ -277,12 +290,12 @@ Traduit rapidement à partir de la langue de Batman: "_En utilisant Black, vous
|
|||
Mais la partie réellement intéressante concerne le fait que "_Tout code qui sera passé par Black aura la même forme, indépendamment du project sur lequel vous serez en train de travailler. L'étape de formatage deviendra transparente, et vous pourrez vous concentrer sur le contenu_".
|
||||
|
||||
|
||||
==== Complexité cyclomatique
|
||||
=== Complexité cyclomatique
|
||||
|
||||
A nouveau, un greffon pour `flake8` existe et donnera une estimation de la complexité de McCabe pour les fonctions trop complexes. Installez-le avec `pip install mccabe`, et activez-le avec le paramètre `--max-complexity`. Toute fonction dans la complexité est supérieure à cette valeur sera considérée comme trop complexe.
|
||||
|
||||
|
||||
==== Typage statique - https://www.python.org/dev/peps/pep-0585/[PEP585]
|
||||
=== Typage statique - https://www.python.org/dev/peps/pep-0585/[PEP585]
|
||||
|
||||
Nous vous disions ci-dessus que Python était un langage dynamique interprété.
|
||||
Concrètement, cela signifie que des erreurs pouvant être détectées à la compilation avec d'autres langages, ne le sont pas avec Python.
|
||||
|
|
|
|||
|
|
@ -1,26 +1,24 @@
|
|||
== Construire des applications
|
||||
== Architecture
|
||||
|
||||
[quote, Robert C. Martin, Clean Architecture, Chapitre 15, What is architecture ?, page 137]
|
||||
A software system that is hard to develop is not likely to have a long and healthy lifetime
|
||||
|
||||
=== Bien structurées
|
||||
|
||||
include::clean_architecture.adoc[]
|
||||
|
||||
=== Evolutives
|
||||
=== Evolutions
|
||||
|
||||
include::12-factors.adoc[]
|
||||
|
||||
=== Maintenables
|
||||
=== Maintenabilité
|
||||
|
||||
include::maintainable-applications.adoc[]
|
||||
include::mccabe.adoc[]
|
||||
|
||||
=== Robustes, flexibles
|
||||
=== Robustesse et flexibilité
|
||||
|
||||
include::solid.adoc[]
|
||||
|
||||
=== Et testées
|
||||
=== Intégrées
|
||||
|
||||
[quote, Robert C. Martin, Clean Architecture, page 203, Inner circle are policies, page 250, Chapitre 28 - The Boundaries]
|
||||
Tests are part of the system.
|
||||
|
|
|
|||
|
|
@ -12,23 +12,17 @@ plus que de la définition d’une architecture adéquate, c’est surtout dans
|
|||
d’une application que ces principes s’identifient.
|
||||
|
||||
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.
|
||||
à faire évoluer l’application: ne pas investir dès qu’on le peut va juste lentement remplir la case de la dette technique.
|
||||
|
||||
Good architecture makes the system easy to understand, easy to develop, easy to maintain and easy to deploy.
|
||||
The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity.
|
||||
-- Robert C. Martin, Clean Architecture, Chapitre 15, what is architecture ?, page 137
|
||||
|
||||
L’objectif d'une bonne architecture est également de garder le plus d’options possibles,
|
||||
de se concentrer sur les détails (le type de base de données, la conception concrète, ...),
|
||||
Une bonne architecture va également 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.
|
||||
-- Robert C. Martin, Clean Architecture, page 141 - What is architecture ?
|
||||
en ayant le plus d’informations possibles cite:[clean_architecture(137-141)]
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
==== Politiques et règles métiers
|
||||
|
||||
|
|
@ -63,8 +57,7 @@ votre nouvelle création en utilisant Django, vous serez bon gré mal gré, cont
|
|||
Cette décision ne sera pas irrévocable, mais difficile à contourner.
|
||||
|
||||
> 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
|
||||
> The DevOps Handbook, Part III - The Principles of Flow - Architect for low-risk release (page 182)
|
||||
> 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:[devops_handbook(182)]
|
||||
|
||||
Ceci dit, Django compense ses contraintes en proposant énormément de flexibilité et de fonctionnalités
|
||||
*out-of-the-box*, c'est-à-dire que vous pourrez sans doute avancer vite et bien jusqu'à un point de rupture,
|
||||
|
|
|
|||
|
|
@ -1,19 +1,14 @@
|
|||
=== Développements
|
||||
|
||||
[quote]
|
||||
----
|
||||
The primary cost of maintenance is in spelunking and risk
|
||||
-- Robert C. Martin, Clean Architecture, page 139
|
||||
----
|
||||
|
||||
=== Maintenance
|
||||
|
||||
[quote, Robert C. Martin]
|
||||
The primary cost of maintenance is in spelunking and risk cite:[clean_architecture(139)]
|
||||
|
||||
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é,
|
||||
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 🙃
|
||||
|
||||
Avec cette approche, les composants sont déjà découplés au niveau du code source, ce qui pourrait s’avérer suffisant
|
||||
|
|
@ -25,10 +20,7 @@ En terme de découpe, les composants peuvent l’être aux niveaux suivants:
|
|||
@ déploiement, au travers de dll, jar, linked libraries, … voire au travers de threads ou de processus locaux.
|
||||
@ services
|
||||
|
||||
|
||||
Pour cette section, nous nous basons sur un résumé de l'ebook **Building Maintenable Software** disponible chez http://shop.oreilly.com/product/0636920049555.do[O'Reilly].
|
||||
|
||||
Ce livre répartit un ensemble de conseils parmi quatre niveaux de composants:
|
||||
Cette section se base sur deux ressources principales cite:[maintainable_software], qui répartit un ensemble de conseils parmi quatre niveaux de composants:
|
||||
|
||||
* Les méthodes et fonctions
|
||||
* Les classes
|
||||
|
|
@ -57,5 +49,3 @@ Ces conseils sont valables pour n'importe quel langage.
|
|||
|
||||
* *Conserver une densité de code faible*: il n'est évidemment pas possible d'implémenter n'importe quelle nouvelle fonctionnalité en moins de 20 lignes de code; l'idée ici est que la réécriture du projet ne prenne pas plus de 20 hommes/mois. Pour cela, il faut (activement) passer du temps à réduire la taille du code existant: soit en faisant du refactoring (intensif?), soit en utilisant des librairies existantes, soit en explosant un système existant en plusieurs sous-systèmes communiquant entre eux. Mais surtout, en évitant de copier/coller bêtement du code existant.
|
||||
* *Automatiser les tests*, *ajouter un environnement d'intégration continue dès le début du projet* et *vérifier par des outils les points ci-dessus*.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,3 +7,45 @@
|
|||
year = {2018},
|
||||
type = {Book}
|
||||
}
|
||||
@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, & 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# Edition, first edition},
|
||||
publisher = {O'Reilly Media, Inc.},
|
||||
isbn = {978-1-491-95452-2},
|
||||
url = {http://shop.oreilly.com/product/0636920049555.do}
|
||||
}
|
||||
Loading…
Reference in New Issue