sv:developpement_-_les_bonnes_pratiques [SIO Wiki]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
~~SLIDESHOW~~
====== 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** : **K**eep **I**t **S**imple **S**tupid
  * 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**