Sans être attaché à une école particulière, il est sain d'avoir des préoccupations stratégiques. L'urgence peut faire paraitre couteux certains efforts de qualités, mais nous restons convaincus des bienfaits de l'emploi de méthodes quelles qu'elles soient, l'efficacité résidant dans la permanence une fois le choix réalisé.

Il serait bien sûr stérile de prendre position pour une régle de nommage donnée ou bien une taille d'indentation du code.

Mais rester pratique n'interdit pas une exigence de qualité permanente.

Les méthodes agiles en général se veulent pratiques et ne s'accomoderont donc pas d'un dogmatisme trop féroce: nous préférons en retenir les éléments qui nous semble les plus profitables en espérant ne pas être iconoclastes

L'Extreme-Programming par exemple peut paraitre … extrème. Et de fait il est difficile d'en suivre tous les préceptes exhaustivement. Mais l'ensemble de ses recommandations sont réellement intéressantes. Nous les employons dès que possible dans nos projets.

C'est cette famille de méthodes et notre expérience du développement qui nous incitent à adopter les différentes règles de pratique.

À chaque fois que cela est possible nous proposons de travailler selon le schéma en spirale avec une première livraison d'un prototype le plus rapidement posssible. Cette technique a deux vertus :

• du point du vue du commanditaire c'est l'assurance de réaliser le plus tôt possible le bien fondé de certaines idées et de permettre des changements de trajectoire.

• du point de vue du technicien, c'est un bon moyen d'avoir une vision globale du chantier, d'intégrer l'ensemble des pièces du puzzle assez tôt pour identifier les éventuels points durs dès le début du projet.

Les outils de la famille xUnit se révèlent très pratiques à l'usage. Différents environnements de développement comme le célèble Eclipse les intègrent naturellement.

On peut préférer une technique à une autre mais ça n'est pas l'essentiel.

L'essentiel est la discipline de l'écriture du test avant le code lui même. Écrire des tests après le code n'est pas couteux, ou bien fastidieux, c'est tout simplement impossible. Si je veux pratiquer le développement par les tests j'écris mon test avant.

Mais pourquoi ?

Le test est l'assurance que mon code fonctionne correctement.

Mais si le test est faux ?

J'en écris d'autres à l'apparition de nouveaux bugs, le test est l'assurance de la non régression.

Mais écrire des tests ça prend du temps !

Écrire les commentaires aussi, et écrire le code aussi prend du temps. En fait, c'est simplement le temps nécessaire à la réalisation de la tâche. Mais en réalité

• le test facilite grandement le débogage en cas de faille, et fait gagner du temps lors de cette phase.
• le test rassure le codeur et le met dans une position plus aisée, plus confortable, plus libre où il donne le meilleur de lui même assuré qu'il est que le test

Alors les tests sont la Panacée !

Non,

• les tests unitaires ne garantissent pas une couverture totale du code.
• les tests peuvent donner une fausse impression de qualité.
• les tests unitaires ne sont pas la solution idéale qui va magiquement transformer du mauvais code en perfection ultime.

Programmer par les tests est une démarche où l'on applique raisonnablement un outil d'aide à la programmation pour la satisfaction de toutes les parties.

Nous ne prétendons pas être des architectes logiciels établissant une fois pour toute les plans parfaits d'un système dès la phase de conception. Le développement logiciel est une activité éminemment évolutive et il semble dangeureux de figer les contours d'un projet une fois pour toutes.

Une bonne conception n'est pas une construction théorique, mais une conception intelligente n'émergera pas naturellement non plus d'un projet mené dans l'urgence.

Souvent, la bonne architecture se révèle à l'usage, lorsque le projet prend forme.

Il sera alors temps de

• retoucher le code que l'on a écrit,
• de faire évoluer fonctions et classes,
• de travailler à un meilleur découplage,
• d'identifier des interfaces et encapsuler du code.

L'ensemble de ce processus qui est dynamique et présent tout le long de la vie du projet est le remaniement refactoring, et est grandement facilité par la mise en place de batteries de tests unitaires.

C'est du remaniement que finalement émerge une bonne conception, adaptée au projet en cours.

Nous voulons bien fournir une vraie documentation papier … mais si comme précisé plus haut la vie d'une projet est active, alors l'état d'une documentation se révèle très rapidement obsolète, c'est à dire au mieux inutile quand cela n'est pas erronné.

Notons qu'il en est de même pour tout document de conception.

Pour autant, il existe des solution visant à palier cet inconvénient, et le plus souvent nous recommandons la génération automatique de la documentation à partir du code.

L'expression 'le code est la documentation', volontairement provocatrice, devient juste

• si l'on s'attache à coder proprement selon des standards homogènes
• si l'on est assidu dans ses commentaires et prompte à les maintenir en accord avec les évolutions du code.

Pourquoi réinventer la roue quand l'univers libre propose un foisonnement de librairies offrant pour chaque langage toutes les fonctionnalités que l'on peut désirer ?

L'usage d'une librairie permet de souvent de bénéficier d'un produit de qualité, largement testé et maintenu par une communauté active. C'est l'un des nombreux avantages des logiciels libres: la réutilisabilité.

Ce principe suppose une bonne veille technologique et rend les logiciels dépendants de composants tierces. Lorsque les librairies sont libres en

Le premier mainteneur d'un programme est souvent son auteur lui même. Même quand on relit son propre code cela s'apparente à une redécouverte surtout si d'autres projets sont venus s'intercaler. C'est donc une bonne habitude d'adopter des règles d'écriture qui vont favoriser la lecture du code et partant sa maintenabilité.

Ces principes touchent à la mise en forme du code , au nommage des variables et fonctions, et aux commentaires.

D'une façon générale, on se met dans la position d'écrire pour être lu par un autre: le programmeur en sera lui même le premier bénéficiaire.