L’architecture parfaite existe-t-elle ?

Depuis quelques mois, je travaille sur une application iPhone dont l’objectif est de contrôler son spa à distance. Le tout s’opère par réseau sans fil. L’interface permet un contrôle sur tous les accessoires, comme les pompes, les lumières, la température, etc. Plus de détails viendront lorsque cette application sera rendue publique.

Contrôler un device via son mobile est une utilisation qui est à mon avis peu exploitée à l’heure actuelle. En fait, on peut contrôler pas mal n’importe quel type d’appareil avec un téléphone intelligent. En autant qu’il existe une manière de communiquer entre les deux, tout est possible ! Et, s’il n’y en a pas from scratch, on peut toujours la créer !

Quelques imprévus en cours de route

Toutefois, qui dit possibilité dit également complexité. En effet, concevoir une telle application n’est pas si simple. En fait, ça dépend jusqu’où on veut étirer la sauce, de même que des contraintes technologiques rencontrées. Je ne suis pas particulièrement un partisan du développement qui s’échelonne sur des mois sans qu’on puisse livrer quoi que ce soit d’utilisable, par du vrai monde.

Le problème, c’est que parfois on n’a pas trop le choix. Par exemple, la partie communication entre le iPhone et le spa est un morceau de R&D qui nécessite d’y investir beaucoup de temps avant d’avoir quelque chose d’opérationnel. L’architecture choisie au départ peut être appelée à changer à la découverte de comportements imprévus. Après tout, on invente cette communication. On peut s’attendre à un peu n’importe quoi.

Change nothing… until it hurts

Les messages consistent en de simples requêtes HTTP standard où nous traitons le XML qui nous est retourné. Rien de très complexe jusqu’ici.

Nous avons toutefois dû implanter en cours de route une queue pour gérer le synchronisme et les doublons dans les requêtes. Sans être un énorme changement en soi, ceci nous a permis de faire le point sur d’autres aspects de l’application, comme par exemple sur la nécessité d’implanter l’observer pattern.

Tout ça pour dire que, ces quelques changements forment désormais un maillon indispensable de notre communication avec le spa. Je n’entrerai pas dans les détails ici car ce n’est pas le but de ce billet.

Par contre, cette expérience m’a appris beaucoup de choses. D’une part, dans un projet R&D, il faut s’attendre à devoir composer avec des imprévus qui peuvent remettre en question nos assises et nos prémisses. D’autre part, minimiser le nombre de features par livraison est une approche agile qui a fait ses preuves, peu importe le projet.

Vous est-il déjà arrivé d’avoir à faire de gros changements en cours de projet ? Si c’est le cas, j’aimerais savoir par curiosité, quel type de projet était-ce ?