06Jan / 2012
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.
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 !
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).
Le code “prudent” est du code conforme à la 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 :
Le respect de la Loi de Demeter améliore la maintenabilité et réduit la duplication de code (à nouveau Règle 1).
<?php
$dbhost = "localhost";
$dbuser = "root";
$dbpasswd = "azerty";
$dbname = "mabase";
...
?>
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.
Factoriser oui, mais quand ? Quelques situations indiquées :
La factorisation implique une certaine prudence pour éviter les retours en arrière :
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.
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.
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 .