Développement : les bonnes pratiques

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.

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.

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)

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é.

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 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)

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

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

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

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

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

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

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 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