Hobbestigrou

Just another python and perl developer

Bonne pratique de développement.

documentation sphinx tests langage

14 sep. 2015 | hobbestigrou | comments

Introduction

J'aime écrire du code, je ne me vois pas faire autre chose un jour et j'espère pouvoir toujours continuer. Certaines personnes pensent qu'il est vraiment difficile d'être développeur. Je pense que c'est un métier simple et accessible et que tout le monde peut l'être. En revanche, il n'est pas facile, il y a un investissement à fournir et il faut un peu de passion.

Documentation

Quelque soit le langage c'est une des choses les plus importante1. Un projet bien documenté permet aux personnes intéressées par le projet de commencer à regarder comment il fonctionne sans avoir besoin de toute de suite se plonger dans la lecture du code. De plus dans un premier temps c'est plus agréable à lire et peut donner des détails ou astuces. Autre avantage ça permet de donner une visibilité au projet. Utile aussi pour le développeur du projet après une pause, permet de plus facilement retravailler dessus. Je recommande de commencer au moins en partie par la documentation, ce qui permet de structurer et clarifier ses idées. En Python, je recommande d'utiliser le projet sphinx, pour Perl le format pod est très bien et il sera directement affiché sur la page du module. Pour tout autre langage sphinx ou pandoc, l'avantage de sphinx est la publication sur la plateforme readthedocs. Une documentation à jour et bien maintenu est donc importante.

Test

Encore une fois ce n'est pas dépendant du langage2. Un projet bien testé est important. Permet de faciliter l'ajout de nouvelles fonctionnalités, d'amélioration du code, sans avoir une goute de sueur glissant le long du front. Un projet bien testé garantit la non régréssion. C'est aussi un bon exemple d'utilisation dans le cas d'une biblothèque par exemple. Idéalement, il faut écrire le test avant le code, essayer d'être le plus complet possible et prévoir tous les cas. En revanche, il faut essayer de ne pas en écrire trop et faire du test qui doit être testé par le module déjà lorsque il y a une dépendance. Lorsque qu'il faut tester une méthode qui utilise une API qui fait de l'écriture ou des méthodes dynamiques, utiliser mock mais éviter autant que possible.

Code

La partie principale arrive. Respecter les recommandations et conventions du langage en Python par exemple il existe la pep 8 que je recommande de lire. Avoir des fonctions ou méthodes qui ne fassent qu'une chose et qui soient limitées en nombre de lignes. Limiter aussi le nombre de lignes pour une classe, et éviter d'avoir une classe qui fasse plusieurs choses. Limiter la taille d'un fichier à mille lignes c'est bien, ne pas hésiter à découper le code. Rester simple que ce soit pour l'implémentation ou l'architecture il est important de rester simple, un code lisible et clair sera toujours mieux qu'un code très compressé et obscure qui ne fait gagner qu'un très peu. Toujours penser que le code est fait pour évoluer et que certainement d'autres développeurs vont travailler sur le projet. En général lorsque je commence à m'intéresser et utiliser un projet, je commence par lire entièrement la documentation et le code pour me faire une idée de ce qu'il est possible de faire et de l'implémentation. Ensuite je lis regulièrement les choses dont j'ai besoin sur le moment, je pense que c'est une bonne pratique et ça permet d'avoir un éventail assez complet et je pense que lire le code est un bon complément.

Faire de la veille

L'informatique évolue rapidement, beaucoup de choses voient le jour. Il ne faut pas foncer tête baissée sur la dernière nouveauté, mais en revanche il est important de voir ce qui se fait, ne pas hésiter à regarder et tester un nouveau projet pour faire son idée. Lire le code du projet qui nous intéresse, de pas oublier qu'écrire du code est aussi beaucoup de pastiche et il ne faut pas hésiter à s'inspirer.

Poser des questions

Ce n'est pas grave d'être lent et ne pas assimiler un nouveau concept. Il ne faut pas avoir peur de poser des questions et ne pas rester bloqué. Je pose beaucoup de questions, souvent trop, mais je pense que c'est utile pour tout le monde. En revanche, avant de poser une question ou de chercher sur internet, je recommande de d'abord lire la documentation ainsi que le code.

Conclusion

J'ai présenté ce que j'essaie de respecter au quotidien qui sont des recommandations reconnues et respectées par beaucoup, je n'ai rien inventé. Je pense que respecter les différentes étapes permet de gagner du temps sur le long terme et d'être plus serein.


  1. Dit DDD pour Documentation Driven Development 

  2. Dit TDD pour Test driven development 

comments powered by Disqus