Environnements et good practices

De nombreux types d’environnements sont possibles mais on retrouve couramment :

Développement
Pour le développement local sur la machine d’un développeur. C’est l’environnement le plus simple, par exemple, on n’y active généralement pas de cache, pas d’accès un service d’API externe, etc.. et en mode “DEBUG” activé.

Test
Un environnement spécial pour lancer les tâches qualité par exemple lorsque le déploiement est automatisé (via un système deCI/CD) pour bloquer une release qui inclurait des régressions.
Il est aussi souvent inclus dans l’environnement de développement pour qu’un développeur puisse contrôler son travail localement avant de livrer.

Pré-production
Qui intervient entre le développement local et la production pour présenter des preuves de concept et tester en interne des évolutions.

Recette
Il sert à pratiquer du test fonctionnel par une équipe pouvant représenter un ou plusieurs utilisateurs finaux.
Son plus grand intérêt est de temporiser l’état de la pré-production qui peut valider des concepts en interne qui ne sont pas finalement souhaitables, il sert donc de tampon.
C’est utile pour une équipe externe de validation qui suit son propre cahier des charges sinon la pré-production sera suffisante.

Production
C’est la finalité pour publier un projet.
Développement et Production sont les environnements naturels d’un projet et Pré-production est un atout pour éviter les régressions et les pertes de données en production.

Style de programmation

Le style de programmation ou “code style” est un ensemble de conventions pour définir des règles communes à tous les développeurs sur le code qu’ils produisent dans un même projet.

PEP8
Python a défini la PEP8 comme norme de référence, elle décrit les règles de base pour produire un code lisible et accessible sans brider l’ingéniosité du développeur. Lorsque la PEP8 a été absorbée par un développeur, il pourra plus aisément se confronter à l’usage de Flake8 qui est un outil implémentant l’intégralité de la norme pour sonder son code et lui retourner tous les manquements aux règles qu’il devra corriger car Flake ne modifie jamais le code lui-même.

Flake8
Lorsqu’un outil comme Flake a été intégré aux tâches qualité, les règles de la norme s’imposent assez rapidement et avec un peu d’expérience, un développeur écrira naturellement la quasi totalité de son code en les respectant.

Pair programming & review de code

Tests unitaires

Le principe des tests unitaires est de valider du code par du code dans une procédure automatisée qu’il suffit d’éxecuter par une commande unique pour effectuer un contrôle qualité d’une plateforme.
Tout projet nécessite d’être testé et le test humain est le plus naturel mais aussi le moins sûr car plus un projet est conséquent plus il nécessite de tester des scénarios différents pour chaque fonctionnalité et comportement. Les tests humains mobilisent du temps et des moyens sans garantir pour autant une qualité fiable.
C’est pourquoi il est indispensable qu’un projet ait une couverture de tests automatisés, pour le backend via des tests unitaires et pour le frontend via des tests fonctionnels.

Pytest est l’outil de référence pour exécuter des tests unitaires et les rédiger naturellement par une approche de programmation fonctionnelle.

CI CD automatisé avec déploiement des branches / feature branches