Développement : les bonnes pratiques

Qu'est ce qu'un projet ?

le nommage du projet

  • le projet doit avoir un nom !
  • éviter les assonances ou connotations bizarres ou lourdes à porter (comme pour les prénoms)
  • l'humour de style potache ou pire est à proscrire !
  • si le projet est destiné à être public (qui sait ?), il est recommandé d'éviter les noms communs et déjà utilisés qui risqueraient apparaître en tête dans les recherches Google.

le projet : les éléments de base

  • un projet comporte
    • du code
    • de la documentation
  • il se présente sous forme d'une archive compressée (.zip, tar.gz, .tgz) qui contient
    • des répertoires contenant du code PHP, python, java, ruby, perl, C, C++, …
    • de la documentation
    • un ou des scripts d'installation, des schémas de base de données.

le projet : les éléments de base

  • un projet comporte
    • un fichier lisezmoi.txt : présentation globale du projet et des fichiers contenus (pour les principaux)
    • un fichier changelog.txt : historique des changements et corrections de bug
    • un fichier install.txt : comporte le mode opératoire d'installation
    • un fichier todo.txt : comporte la liste des choses à faire
  • ces fichiers doivent avoir été rédigés avec un éditeur de texte pour être lisibles aisément avec les outils les plus basiques (jeu de caractères ASCI 7 bits)

le nommage des bases de données

  • une base de données est constituée de tables, elles-mêmes constituées d'attributs (colonnes)
  • un nom doit être
    • pertinent
    • signicatif ou descriptif
    • raisonnablement compact
  • Le nom d'un attribut doit être suffisamment pertinent pour que l'on puisse comprendre la nature du type de données représenté.

le nommage : quelques repères

ID identifiant (en général clef auto incrémentée)
NUM ou No numéro
REF référence
CODE code, codage, codification
LIB libellé
ORD ordre
CP code postal
ADR adresse
FAX télécopie
MAIL e-mail
TEL téléphone
GSM téléphone mobile
LOG “login”
PWD “password”
NBR nombre
QTE quantité
POS position
NDX index
MNT montant
TX taux
PCT pourcentage
PUTC prix unitaire toutes taxes
PUHT prix unitaire hors taxes

les schéma de base de données

  • les types de données
    • champ code postal : chaine (varchar)
    • champ téléphone : chaine (varchar)
    • un champ de type numérique ne doit être utilisé que si les données doivent faire l'objet de calculs
    • un champ adresse doit comporter au minimum 2 lignes de 38 caractères (La Poste recommande 4 lignes)

le nommage

  • les principes de nommage doivent être systématiques et ne pas souffrir d'exceptions

le codage

la structuration

  • créer des procédures/functions à taille humaine
  • limiter le nombre de niveaux d'imbrications

la factorisation

  • éviter la copie de bloc pour développer : tout changement ultérieur devra être effectué n fois !!!

quelques principes cardinaux

  • KISS : Keep It Simple Stupid
  • principe de moindre surprise

les tests

  • ils doivent être pensés dès le départ : on ne peut réaliser une application si on ne sait pas tester
  • les outils modernes permettent de plus en plus souvent des tests unitaires

les jeux d'essai

  • il n'est pas possible de tester sans jeu d'essai
  • un n'est pas plusieurs LOL : avoir toujours plusieurs occurrences d'un type d'objet …
  • faire en sorte que le jeu d'essai soit signifiant et adapté au domaine considéré
    • attention à la distance sémantique
      • Dupont <> Leroy
      • Client1 ~ Client2

les différents environnements

  • idéalement :
    • environnement de développement
    • environnement de test
    • environnement de production
  • avec chacun
    • ses programmes source
    • sa base de données :
      • db-appli-dev, db-appli-test, db-appli-prod

l'encodage

  • le standard actuel est l'utf-8 après l'iso 8859-1
  • utiliser un éditeur de texte adapté (capable de gérer l'encodage choisi)
    • par exemple : :set enc=utf-8 avec vim

les commentaires

  • les commentaires doivent être pertinents et informatifs
  • ne pas utiliser de caractères accentués dans les commentaires pour éviter tout problème

la documentation

  • elle a un rôle stratégique : le code n'est pas la documentation
  • indispensable pour l'équipe actuelle de développment ou les futurs développeurs qui prendront la suite

les outils

  • les outils de gestion de version
  • il est fortement recommandé d'utiliser de tels outils pour faciliter la gestion des sources et le travail en équipe
  • git est actuellement le plus utilisé (http://git-scm.com)
    • pour Windows : utiliser le client msysgit