Après un vide intergalactique de quelques mois sur ce blog, dû aux moult péripéties Balloonesques de ces derniers temps, j’ai eu l’envie de faire un gros post bien indigeste mais racoleur inspiré de mes “erreurs” commises dans ma startup et si possible à éviter à l’avenir, du genre, “les 10 erreurs tech à éviter en lean startup” (ok, ce n’est peut-être pas tant racoleur que ça en fin de compte..). Je me suis dit ensuite qu’il serait peut-être plus sympa et léger de distiller ces erreurs à éviter tout au long de cet été, sous forme de saga, a lire au bord de la piscine ou sur le sable chaud d’une plage ensoleillé..

Episode #1: choisissez bien et utilisez des frameworks

Lorsque j’ai commencé ma startup, en mode vraiment vraiment lean (j’entends par là que nous avions 2 mois pour sortir le premier MVP de Balloon et pas une seconde de plus, car vendu déjà à deux clients prestigieux et qu’on n’avait donc pas droit à l’erreur ni au retard), j’ai été tenté “pour aller vite” de coder en natif sous “framework maison” la solution. Mes arguments étaient les suivants:

• On code uniquement ce dont on a besoin, et on ne s’emm**de pas avec du superflu, de la config, de la custom: on maitrise tout et on épouse juste nos besoins business, ça sera mieux pour scaler ensuite et conquérir le monde

• On part sur du PHP5 assez simple, épuré, facile à lire / reprendre par les stagiaires: si on met moins de normes et de config que dans un vrai framework, tout développeur connaissant bien PHP sera opérationnel car n’aura pas à apprendre ou connaitre le framework pour travailler, mais juste le PHP

• Comme c’est moins rigoureux (casse-bonbons) qu’un vrai framework, on pourra toujours essuyer les coups de pression en codant salement mais rapidement ce qui est nécessaire: un peu de modèle dans la vue, un peu de vue dans le modèle, du html en dur par-ci, du javascript en dur par-là: on est flexible et on a pas à réfléchir 10 ans comment régler un souci client au sein d’un framework exigeant

• Je connaissais vaguement les frameworks existants à l’époque, mais aucun réellement. Quelle galère de devoir mettre à jour son framework, et si ça allait tout casser? Au moins je suis tranquille et autonome avec mon code perso. De même, si une faille est trouvée dans le framework, je suis alors vulnérable: je dois le mettre à jour. Et si ça tombe mal, que je n’ai pas le temps à ce moment de le faire, je m’expose?

Grave erreur.. 

• Un bon framework, bien qu’embarquant plein de concepts, patterns, moulinettes et sur-moulinettes lui permettant de se plier à un peu tous les besoins de l’utilisateur, n’est pas beaucoup moins performant qu’un framework maison / léger, au regard du temps de développement économisé au quotidien. Dans l’exemple de Symfony2 que nous utilisons, les différents niveaux de cache nous permettent d’atteindre des temps de calculs très compétitifs en comparaison de notre solution initiale “maison”, tout en divisant par 2 voire 3 tous nos temps de développement / refactoring / amélioration de features.

• Le fait que le framework oblige de se plier à un moule, de coder proprement (namespace, exceptions, injection de dépendance..) et de découpler un maximum son code, est bien plus complexe pour un stagiaire mauvais, mais tellement plus simple et lisible pour tout le monde. Il est quasi imposible de “gerber” son code sur 500 lignes, block illisible et non maintenable sous un bon framework. C’est donc plutôt une excellente chose, vous empêchant de vous reposer sur de mauvais stagiaires pour vous faire du mauvais travail ;) De plus, tout nouveau développeur de votre startup devra se mettre à jour et comprendre votre framework maison avant d’être réellement productif, tandis qu’en épousant un framework répandu qu’il connait déjà, vous vous assurez une prise en main bien plus rapide!

• Bien que plus lent de réfléchir en amont comment bien découper son code, garder les philosophies DRY (Don’t Repeat Yourself) ou SOC (Separation Of Concerns) qu’un bon framework vous impose, plutôt que de galoper à bride rabattue dans un déroulé ignoble procédural de lignes de code, cela sera sur le moyen et surtout long terme un gain de temps phénoménal, et un gage de scalabilité / évolutivité. En effet, tout bien séparer, encapsuler, consigner dans des tests, permet par la suite de modifier et faire évoluer ses features qui sont dès le départ, même si très basiques, organisées comme des grandes dans un modèle rigoureux et solide servant de socle pour tout développement ultérieur.

• Comme vous avez pu le voir sur les trois points précédents, tout ceci n’est possible qu’avec un bon framework. C’est un peu comme les chasseurs: il y a les bon chasseurs, comme il y a aussi les mauvais chasseurs.. Il faut donc pour cela bien se renseigner, en tester plusieurs, se pencher sur ceux qui sont les plus matures mais aussi les plus actifs au niveau de la communauté et les plus rigoureux d’un point de vue conception / concepts. Je pense avoir trouvé un bon compromis avec Symfony2 sous PHP et Backbone en Javascript en ce qui me concerne pour mes projets.

Vous l’aurez compris, utiliser des frameworks au sein de votre startup me semble une nécessité pour gagner du temps sur vos développements et vos nouveaux recrutements, vous astreindre à une rigueur dès les premiers jours qui sera salvatrice plus votre projet prendra de l’ampleur. Attention toutefois, tous les frameworks ne sont pas égaux: choisissez un framework relativement mature (sites importants en production sous ce framework), avec une communauté active (corrections et améliorations permanentes), rigoureux (dur de faire du code spaghetti), performant (évitez les usines à gaz lourdingues) et enfin avec lequel vous vous sentez à l’aise.

Et vous, que pensez-vous des frameworks, lesquels utilisez-vous et dans quels langages? Que leur trouvez-vous de bien, que leur reprochez-vous?