wiki:2011-2012:developpement_-_les_10_commandements [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.
06Jan / 2012
====== Les 10 règles du développeur pragmatique ======


===== Règle 1: Ne pas se répéter =====

  * Respecter le principe **DRY** (**Don't Repeat Yourself**):
  * Chaque élement de connaissance doit disposer d'une représentation unique, non ambigüe et qui fait autorité dans le système
  * Cela permettra de faciliter la maintenance et de diminuer les bugs.

===== Règle 2 : Réparer les fenêtres cassées =====


The concept of Broken Windows come from the criminological theory:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters.

Dans le cadre du développement logiciel, les fenêtres cassées sont les mauvaises conceptions, les décisions inadaptées ou même le mauvais code. Si vous ne les réparez pas le plus tôt possible, le logiciel risque de se dégrader rapidement.

===== Règle 3 : Planter au plus tôt =====


Il vaut mieux interrompre un programme dès que possible. Utiliser des codes de retour (error codes) pour notifier une erreur à un composant appelant n'est pas une bonne idée. Un composant pourrait éventuellement ignorer cette valeur : une erreur pourrait donc se produire et être ignorée.

Un logiciel planté ne ment pas !

===== Rule #4: Use tracer bullets  =====

The idea of tracer bullets is to get things up in production as soon as you can.

We speak also about code that glows in the dark. When you have a new projet in mind, try to get to the point where you can ship something in production. Just make it as simple as possible, don’t try to envision everything in the first place. The first target is to have a simple, consistent package that works, in production. After that, you’ll be able to upgrade that package iteratively.

The tracer bullet is your first package, by reducing its feature set, you’ll focus on the essential: production/packaging/deployment issues. Other features and enhancements will come later on. Cette stratégie présente This strategy has also the benfit of reducing the risk of premature optimizations (which is the root of all evil, as you may already know).

===== Règle 5 : Ecrire du code "prudent" =====


Le code "//prudent//" est du code conforme à la [[http://fr.wikipedia.org/wiki/Loi_de_D%C3%A9m%C3%A9ter|Loi de Demeter]]. Il peut être considéré comme conforme au //Principe de Moindre Connaissance//, comme le décrit Wikipedia :

Il peut être résumé ainsi :

  * chaque unité/module devrait avoir une connaissance limitée des autres unités: only units “closely” related to the current unit.
  * chaque unité/module ne devrait communiquer qu'avec ses amis et pas avec les "//étrangers//".
  * on ne communique qu'avec ses amis proches.

Le respect de la Loi de Demeter améliore la maintenabilité et réduit la duplication de code (à nouveau Règle 1).

===== Règle 6 : Configurer, ne pas coder =====

  * Les détails de configuration polluent le code originel, ils changent fréquemment. 
  * Chaque modification du code constitue un risque pour l'intégrité du système. 
  * Pour éviter ca, les détails de configuration doivent être extraits du code (//codage en dur//) et intégrés dans des fichiers de configuration (**config.txt**, **config.php**) que l'on peut changer sans toucher au code.
  * exemple : extrait du fichier **config/config.php**
<code>
<?php
	$dbhost = "localhost";
	$dbuser = "root";
	$dbpasswd = "azerty";
	$dbname = "mabase";
        ...
?>
</code>


Whenever you come to the point where you put details into your codebase, stop, and extract them out of it. The time you spend now will pay-off ten times in the future.

===== Règle 7 : factoriser dès le début, factoriser souvent =====

Factoriser oui, mais quand ? Quelques situations indiquées :

  * vous avez trouvé des parties dupliquées que vous voulez éliminer (à nouveau, Règle 1 !)
  * vous voulez extraire des détails de configuration du code (Règle 6)
  * vous avez trouvé une façon de généraliser une partie du code.

La factorisation implique une certaine prudence pour éviter les retours en arrière :

  * ne pas factoriser et ajouter des fonctionnalités en même temps
  * s'assurer de tester pour éviter les régressions
  * effectuer des petits pas : une chose à la fois.

===== Règle 7 : Concevoir pour tester =====

If you’re a perfectionist, you might write your tests before the code (it’s called Test-Driven Development) but it’s not mandatory. A matter of taste I’d say. What is important though is that you always keep tests in mind when you write the code. Respecting the Law of Demeter (rule #5) will definitely help, because a good encapsulation always leads to testable code.

If a part of the code is difficult (or impossible) to test, you need to refactor it to smaller components.

===== Règle 9 : si vous trouvez un bug, écrivez un test =====
La bonne approche : quand un bug est détecté en production, la première chose à faire est d'écrire un test qui reproduit le problème. Cela permet de s'assurer de la compréhension du problème avant de penser à sa résolution ; cela constitue un test de non-régression qui permettra de s'assurer que le problème ne se reproduira plus.

===== Règle 10 : Savoir s'arrêter =====

 Les développeurs, comme les peintres, construisent une image d'une partie du monde d'après une représentation. La difficulté majeure est de savoir quand et où s'arrêter. Le logiciel parfait n'existe pas, quels que soient les efforts faits pour le réaliser .