D’abord, l’article part du principe qu’on va iterer sur le MVP pour arriver au produit fini, en gardant le framework. Mais qu’est-ce qu’un framework ? Dans le cadre de cet article je prends le terme comme désignant un framework Web “lourd”, “tout en un” type Django ou Rails, par opposition à des frameworks légers comme Flask ou Sinatra.

Une caractéristique de ces frameworks lourds est qu’ils encouragent à mon sens la conception d’applications monolithiques (ie. pas modulaires) dont l’architecture est cadrée par le framework. Par exemple, ils comprennent un ORM type ActiveRecord, s’appuient sur le pattern MVC, etc. Or, à mon sens, l’architecture d’une “application” (ou plutot du système) d’une startup devrait découler des besoins métier.

Au moment du MVP on ne connait en général pas suffisamment ces besoins pour faire les bons choix architecturaux, puisque le but est justement de comprendre “le métier”. Ce n’était pas forcément le cas de Balloon qui avait a priori vendu son MVP à des clients avant de commencer à coder ! Donc, on fait comme on peut et on aboutit forcément à un design bancal.

Dans cette phase-là je suis d’accord sur l’utilisation d’un framework s’il permet d’accélerer le time to market, mais *pas* pour la qualité du produit. Je considère presque qu’il *faut* coder de manière inmaintenable, pour s’obliger à jeter le MVP et repartir sur des bases saines.

Ensuite, avec une vision plus claire du résultat attendu, on peut passer à l’architecture. Si certaines parties du design correspondent à l’utilisation d’un framework (léger, en général…) autant ne pas s’en priver. On peut même utiliser *plusieurs* frameworks pour des briques différentes du produit (par exemple https://github.com/intridea/grape/ pour une API). Mais certaines parties ne rentreront peut-être pas dans le moule d’un framework et je n’essaierai pas de les y forcer.

Bon après, tout dépend de la conception de ce à quoi ressemble le “produit” d’une startup techno / Web. Quand on en parle comme d’une “application” on pense en général monolithique, et framework. Mais force est de constater que les startups qui grossissent, pour des raisons variées (flexibilité, scalabilité, maintenabilité…), évoluent en général vers du SOA.

Après, sur la qualité du code, il y a un autre débat sur “jeter le prototype ou pas”, mais en tous cas, il faut refactorer souvent quoi qu’il arrive. Et découpler si possible.

Après, il est clair que le temps de refactoring est extrêmement important au fil de l’évolution de notre connaissance du framework et des besoins du produit.
L’idéal est d’isoler les features les plus importantes et de se concentrer dessus afin de ne pas se disperser !