Ne codez pas de la me*de sous prétexte que c’est le proto / MVP de votre startup

Dans mon précédent billet, Utilisez des frameworks, je préconise l’utilisation de frameworks au sein de sa solution au plus tôt dans la vie de la startup. Cela n’aura pas échappé à l’oeil aguerri de mon ancien padawan @lucascerdan qui m’a justement aidé l’an dernier à passer du MVP de Balloon en solution plus mature sous framework maison, puis sous Symfony2.

En effet, si je préconise l’utilisation de frameworks au plus tôt, c’est parce que justement je ne l’ai pas fait initialement pour des raisons inhérentes au contexte de la création de Balloon (longtemps sans coder, aventure startup non prévue / anticipée), mais aussi pour de bien mauvaises raisons, à qui aujourd’hui j’ai envie de tordre le cou..

Continue reading

Post léger d’été #1: utilisez des frameworks (et choisissez-les bien)

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: Continue reading

Mettez des tests dans vos développements (ils vous le rendront bien)

S’il y a bien quelque chose de chronophage et de littéralement barbant, c’est bien le debug de sa solution.. Qui n’a jamais connu les interminables sessions de correction à droite, puis à gauche, puis re à droite, etc..

Tout simplement, chaque nouvelle ligne de code peut porter préjudice à la solution actuelle (avoir du beau code découplé et modulaire limite toutefois la casse) et entrainer des régressions deci delà. La solution? Pour chaque bloc de code (fonction, module) écrit dans votre projet, écrivez un ou plusieurs tests (unitaires et/ou fonctionnels) associés. A chaque fois. Continue reading