De part ma fonction, il m’arrive souvent d’avoir à intervenir sur des applications déjà en développement. Lors de la présentation technique j’entends de plus en plus d’architecte me dire avoir utilisé tel ou tel framework comme PureMVC ou Cairngorm en Flex, ou encore Spring MVC et Struts pour le partie Java.
En soit ça ne me pause aucun problème puisque se sont presque tous de bon framework.
Mais là où ça coince c’est quand je demande pourquoi, et que l’on me répond « parceque c’est bien » ou « parceque ça ce fait beaucoup » ou encore « on ne sait pas bien, celui qui a décidé ça n’est plus là« .
Je trouve ça incroyable et le plus fort c’est que ça arrive très souvent.
Mon point de vue sur l’utilisation d’un framework est le suivant. Ne s’en servir que si on en a besoin. Ça à l’air con comme ça, mais beaucoup de projet prennent le problème à l’envers et imposent l’utilisation de framework avant d’en avoir besoin.
C’est la même chose avec les pattern. Combien de fois j’ai vu un développeur me présenter fièrement le dernier pattern qu’il venait d’utiliser et incapable de me dire la raison de son choix, à part un « parce que c’est cool, ça le fait grave«   .
Et bien non, un pattern est une solution à un problème, pas une mode ni un effet de style. De la même façon, un framework est là pour répondre à un besoin induit par l’application. Le fait d’imposer un framework a souvent un effet pervers, celui d’augmenter l’entropie du projet et le rendre impossible à maintenir.

Un comble…