Table des matières
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 |
| 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
: 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