Aller au contenu
Minor Swing with Django

Outils de développement

Environnement de développement intégré

Concrètement, nous pourrions tout à fait nous limiter à Notepad ou Notepad++. Mais à moins d’aimer se fouetter avec un câble USB, nous apprécions la complétion du code, la coloration syntaxique, l’intégration des tests unitaires et d’un debugger, ainsi que deux-trois sucreries qui feront plaisir à n’importe quel développeur.

Si vous manquez d’idées ou si vous ne savez pas par où commencer :

  • Visual Studio Code ou VSCodium, qui disposent tous les d’un énorme écosystème de greffons pour la grande majorité des langages,
  • PyCharm, qui évolue très bien et qui dispose aussi bien d’une version Community que d’une version sur abonnement,
  • Vim avec les greffons Jedi-Vim et nerdtree. L’ebook Vim pour les humains de Vincent Jousse est une source intéressante.

Si vous hésitez, et même si Codium n’est pas le plus léger, il fera correctement son travail (à savoir : faciliter le vôtre), en intégrant suffisament de fonctionnalités qui gâteront les papilles émoustillées du développeur impatient.

Configuration

VSCodium permet de définir certaines clés de configuration globalement ou au niveau d’un projet. Celle qui nous semble critique, indispensable et primordiale est la suppression automatique des espaces en fin de ligne, qui facilite énormément la relecture de commits et la collaboration entre intervenants.

/* fichier placé habituellement dans ~/.config/code/User/settings.json */


{
    [...]
    "files.trimTrailingWhitespace": true,
}

Nous pouvons également noter la possibilité d’installer des greffons (dont un gestionnaire d’interpréteur Python), l’intégration poussée de Git ou l’énorme support de plein de langages de programmation ou de mise en forme: Go, XML, HTML, Java, C#, PHP, LaTeX, …, ainsi que tout l’atirail d’aides à l’utilisation de Docker.

Mode debug

Le débugger intégré vous permettra de spécifier le point d’entrée à utiliser, de placer des points d’arrêt (éventuellement conditionnés par certaines valeurs attribuées à des variables), de lancer une analyse sur les variables et contextes, sur la pile d’appels, … Bref: de savoir où vous en êtes et pourquoi vous êtes là.

Ce débugger fonctionne soit sur le fichier courant (déconseillé), soit via un fichier launch.json que vous pourrez placer dans le répertoire .vscode placé à la racine de votre projet. Pour une application Django, ce fichier contiendra par exemple la configuration suivante :

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python Django",
            "type": "python",
            "request": "launch",
            "program": "${workspaceFolder}/manage.py",
            "args": [
                "runserver"
            ],
            "django": true,
            "justMyCode": true
        }
    ]
}

Les configurations peuvent être multiples, et nous pouvons voir que l’objectif de cette configuration-ci est de démarrer la commande ${workspaceFolder}/manage.py, avec le paramètre runserver, ce qui aura pour effet de démarrer l’exécution du code dans une enveloppe sécurisée et plombée de capteurs en tout genre qui faciliteront énormément votre travail de recherche et d’introspection du code.

Terminal

A priori, les IDE proposés ci-dessus fournissent par défaut ou via des greffons un terminal intégré. Ceci dit, disposer d’un terminal séparé facilite parfois certaines tâches. A nouveau, si vous manquez d’idées :

  • Soit vous utilisez celui qui intégré à VSCodium et qui fera suffisament bien son travail
  • Si vous êtes sous Windows, téléchargez une copie de Cmder ou de Windows Terminal. Les deux proposent une intégration des outils Unix communs (ls, pwd, grep, ssh, git, …) sans aucun effort.
  • Pour tout autre système, vous devriez disposer en natif de ce qu’il faut : Bash est le standard sur la majorité des distributions GNU/Linux, tandis que Zsh équipe nativement macOS (et peut profter d’un écosystème très agréable grâce à la communauté Oh My Zsh).

Gestion des mots de passe

Nous en auront besoin pour gé(né)rer des phrases secrètes pour nos applications. Si vous n’en utilisez pas déjà un, partez sur https://keepassxc.org/[KeepassXC]: il est multi-plateformes, suivi et s’intègre correctement aux différents environnements, tout en restant accessible.

La finalité de cette application va être de centraliser la gestion de vos phrases de passe, pour les accès aux bases de données, services en ligne, etc. Il existe des alternatives, comme Bitwarden ou 1password, qui proposent des services libres, gratuits ou payants.

Gestion des versions

Il existe plusieurs systèmes de gestion de versions. Le plus connu/utilisé à l’heure actuelle est Git, notamment pour sa (très) grande flexibilité et sa rapidité d’exécution. L’adoption massive de Git a d’ailleurs rendu la coopération beaucoup facile sur de nombreux projets : avant Git (et Github, qui a popularisé Git), chaque projet utilisait un système de contrôle de version différent. A présent, savoir contribuer à un projet permet de contribuer à tous les projets cite:[roads_and_bridges(89)].

Il est une aide précieuse pour développer rapidement des preuves de concept, switcher vers une nouvelle fonctionnalité, un bogue à réparer ou une nouvelle release à proposer au téléchargement. Ses deux plus gros défauts concernent sa courbe d’apprentissage pour les nouveaux venus et la complexité des actions qu’il permet de réaliser.

Unit of work

Même pour un développeur solitaire, un système de gestion de versions (quel qu’il soit) reste indispensable, car il permet d’isoler un ensemble de modifications dans une unité de travail, jusqu’à ce que celles-ci forment un tout cohérent :

  • Chaque “branche” correspond à une tâche à réaliser: un bogue à corriger (Hotfix A), une nouvelle fonctionnalité à ajouter ou un “truc à essayer” (Feature A et Feature B).
  • Chaque “commit” correspond à une sauvegarde atomique d’un état ou d’un ensemble de modifications cohérentes entre elles. Il convient donc de s’abstenir de modifier le CSS d’une application et la couche d’accès à la base de données, sous peine de se faire huer par ses relecteurs au prochain stand-up. De cette manière, il est beaucoup plus facile pour le développeur de se concenter sur un sujet en particulier, dans la mesure où celui-ci ne doit pas obligatoirement être clôturé pour appliquer un changement de contexte.

L’historique d’un module est ainsi disponible, sauvé et traçable: qui a réalisé quelle modification à quel moment. Ceci permet notamment de dessiner l’évolution du code et de mettre un surbrillance que certains modules distincts évoluent un peu trop main dans la main (et devraient donc être refactoriser, selon les principes de développement énumérés plus tôt).

Cas pratique: vous développez une nouvelle fonctionnalité qui va révolutionner le monde de demain et d’après-demain, quand, tout à coup (!), vous vous rendez compte que vous avez perdu votre conformité aux normes PCI parce les données des titulaires de cartes ne sont pas isolées correctement.

Il suffit alors de:

  • Sauver le travail en cours (git add . && git commit -m [WIP])
  • Revenir sur la branche principale (git checkout main)
  • Créer un “hotfix” (git checkout -b hotfix/pci-compliance)
  • Solutionner le problème (sans doute un ; en trop ?)
  • Sauver le correctif sur cette branche (git add . && git commit -m "Did it!")
  • Récupérer ce correctif sur la branche principal (git checkout main && git merge hotfix/pci-compliance)
  • Et revenir tranquillou sur votre branche de développement pour fignoler ce générateur de noms de dinosaures rigolos que l’univers vous réclame à cor et à a cri (git checkout features/dinolol)

Il existe plusieurs méthodes pour gérer ces flux d’informations. Les plus connues sont https://www.gitflow.com/[Gitflow] et https://www.reddit.com/r/programming/comments/7mfxo6/a_branching_strategy_simpler_than_gitflow/[Threeflow].

La gestion de versions de fichiers permet de conserver un historique de toutes les modifications enregistrées, associées à un horodatage et une description.

Décrire ses changements

La description d’un changement se fait via la commande git commit. Il est possible de lui passer directement le message associé à ce changement grâce à l’attribut -m, mais c’est une pratique relativement déconseillée : un commit ne doit effectivement pas obligatoirement être décrit sur une seule ligne. Une description plus complète, accompagnée des éventuels tickets ou références de tâches, sera plus complète, plus agréable à lire, et plus facile à revoir pour vos éventuels relecteurs.

De plus, la plupart des plateformes de dépôts présenteront ces informations de manière ergonomique. Par exemple:

La première ligne est reprise comme étant le titre (normalement, sur 50 caractères maximum); le reste est repris comme une description (optionnelle).

<type>[optional scope]: <description>


[optional body]


[optional footer(s)]

Il est possible de suivre les recommandations de Conventional Commits, qui ont pour objectifs de :

  • Générer automatiquement un CHANGELOG
  • Déterminer automatiquement des sauts de versions (en se basant sur les types de commits)
  • Communiquer la nature des changements appliqués au code
  • Déclencher (automatiquement, toujours) des processus de construction ou de publication
  • Rendre l’accès au code plus lisible, en facilitant l’exploration du code au travers de commits mieux structurés.

En bref, cela permet d’éviter ceci :

Ignorer des fichiers ou patterns

Par défaut, Git prendra l’ensemble des fichiers présents dans votre espace. Afin d’éviter certaines erreurs, il est important de configurer correctement Git pour qu’il ignore systématiquement certains fichiers ou chemins. Pour cela, la solution consiste à créer un fichier .gitignore que vous placerez à la racine de votre dépôt.

Si vous ne savez pas quoi y mettre, inspirez-vous du dépôt github/gitignore - qui contient un fichier brut contenant les principales règles pour la majorité des langages.

Bases de données

“The database is really nothing more than a big bucket of bits where we store our data on a long term basis” cite:[clean_architecture(281)].

Django gère plusieurs moteurs de base de données. Certains sont gérés nativement (PostgreSQL, MariaDB, SQLite); et a priori, ces trois-là sont disponibles pour tous les systèmes d’exploitation. D’autres moteurs nécessitent des librairies tierces (Oracle, Microsoft SQL Server).

Il n’est pas obligatoire de disposer d’une application de gestion pour ces moteurs: pour les cas d’utilisation simples, le shell Django pourra largement suffire (nous y reviendrons). Mais pour faciliter la gestion des bases de données elles-même, et si vous n’êtes pas à l’aise avec la ligne de commande, choisissez l’une des applications d’administration ci-dessous en fonction du moteur de base de données que vous souhaitez utiliser :

Bruno

https://www.usebruno.com/[Bruno] est un outil de tests d’API qui gère plusieurs protocoles (REST, SOAP, GraphQL et gRPC), plusieurs environnements et propose un système d’organisation des requêtes. Il est léger, multiplateformes et permet de sauver les différentes requêtes au format texte.

Makefile

Pour gagner un peu de temps, n’hésitez pas à créer un fichier Makefile que vous placerez à la racine du projet. L’exemple ci-dessous permettra, grâce à la commande make coverage, d’arriver au même résultat que ci-dessus :

# Makefile for gwift
#


# User-friendly check for coverage
ifeq ($(shell which coverage >/dev/null 2>&1; echo $$?), 1)
    $(error The 'coverage' command was not found. Make sure you have coverage installed)
endif


.PHONY: help coverage


help:
    @echo "  coverage to run coverage check of the source files."


coverage:
    coverage run --source='.' manage.py test; coverage report; coverage html;
    @echo "Testing of coverage in the sources finished."

Pour conclure, make peu sembler un peu désuet, mais reste extrêmement efficace.

Licence

Choisissez une licence.

Si votre projet n’a pas de licence qui lui est associée, vous pourriez être tenu responsable de manquements ou de bugs collatéraux. En cas de désastre médical ou financier, ce simple fichier peut faire toute la différence. Une issue a par exemple été adressée en 2017 sur la librairie React, et qui aurait pu créer un conflit de revendication de brevet.

Un autre exemple concerne StackOverflow, qui utilisait une licence Creative Commons de type CC-BY-SA pour chaque contenu posté sur sa plateforme. Cette licence est cependante limitante, dans la mesure où elle obligeait que chaque utilisateur cite l’origine du code utilisé. Ceci n’était pas vraiment connu de tous, mais si un utilisateur qui venait à opérer selon des contraintes relativement strictes (en milieu professionnel, par exemple) venait à poser une question sur la plateforme, il aurait été légalement obligé de réattribuer la réponse qu’il aurait pu utiliser. StackOverflow est ainsi passé vers une licence MIT présentant moins de restrictions.

Parmi toutes les licences existant, trois licences d’entre elles sont généralement proposées et utilisées :

  • MIT
  • GPLv3
  • Fair Source, annoncée en 2015, qui propose une solution à la nécessité de proposer une licence gratuite pour une utilisation personnelle ou en petites entreprises, tout en étant payante pour une une utilisation commerciale plus large. Under Fair Source, code is free to view, download, execute, and modify up to a certain number of users in an organization. After that limit is reached, the organization must pay a licencing fee, determined by the published - https://fair.io
  • WTFPL

Mike Perham, qui maintient Sidekiq, a ainsi proposé une forme de dualité entre la mise à disposition du code source et son utilisation :

Remember: Open Source is not Free Software. The source may be viewable on GitHub but that doesn’t mean anyone can use it for any purpose. There’s no reason you can’t make your source code accessible but also charge to use it. As long as you are the owner of the code, you have the right to licence it however you want.

…[The] reality is most smaller OSS project have a single person doing 95% of the work. If this is true, be grateful for unpaid help but don’t feel guilty about keeping 100% of the income.

Conclusions

Pour résumer ce chapitre :

  • Choisissez-vous un environnement de développement qui vous convient,
  • En fonction du langage que vous aurez sélectionné, préférez des outils permettant d’en gérer des versions en parallèle,
  • Prenez un gestionnaire de mot de passe (vous en aurez besoin par la suite pour gérer vos clés et mots de passe),
  • Appréhendez Git - c’est le standard actuel dans l’industrie,
  • Choisissez un moteur de base de données (et si vous ne savez pas lequel, contentez-vous d’SQLite dans un premier temps),
  • Compétez votre ceinture à outils avec tous ceux que vous jugerez bons de retenir,
  • Choisissez une licence d’utilisation.

Pour récapituler les différents outils que nous proposons :

  • IDE : VSCode ou PyCharm,
  • Langage de programmation : Python,
  • Suivi des versions : Git,
  • Automatisation des tâches : Make.