Pour changer des RIA (Rich Internet Applications), voici une utilisation plus ludique de Flash !
http://ece4co.vis.ne.jp/sw/2007/05/post_16.html
Voici un lien mirroir qui fonctionne : http://media.fizzlebot.com/hoshisaga.php
Le but : trouver l’étoile sur chaque tableau avec la souris uniquement.
Prévoyez un peu de temps devant vous, car une fois entamé, on veut terminer les 36 tableaux 🙂
Le principe de la dette technique est fondamental en ingénierie logicielle.
Lorsque vous ajoutez une fonctionnalité, vous avez toujours un choix :
La métaphore de la dette technique nous explique qu’une solution à court terme crée une dette technique dans notre programme. Et comme pour une dette monétaire, plus la dette grandit et plus les intérêts deviennent important.
Vous avez sûrement déjà connu des programmes ayant subi évolutions après évolutions et se retrouvant dans un état où la moindre modification risque de tout saboter. A ce niveau, la dette technique est trop grande et le logiciel est dans une « banqueroute » informatique… Seule solution : tout reprendre à zéro.
Pourtant la mise en place d’une pratique saine d’architecture et de suivi technique peut empêcher ces situations malheureuses. Il suffit de tenir compte du facteur Dette !
Par exemple, l’expert technique ou l’architecte du projet doit être capable de choisir des solutions aux évolutions en pensant à la possible future dette qu’il est en train de créer. Surtout, il faudra de temps en temps décider de réduire cette dette en refactorisant le code ou en passant du temps à nettoyer certaines parties archaïques.
C’est à ce prix que l’on pourra assurer des programmes qui vivent longtemps, longtemps…
Référence : La « bible » Martin Fowlers – http://www.martinfowler.com/bliki/TechnicalDebt.html
Commentaires récents