C’est l’été, il fait beau, les oiseaux chantent, ça sent bon la fin du mois de mai !
Oui, cela fait aussi peut-être un an que je n’ai rien posté ici, j’ai décidé (pour combien de temps ?) de reprendre les choses en main. Aujourd’hui, je vous propose une petite réflexion et 7 conseils tirés de mon expérience personnelle pour bien plomber votre startup niveau techno. Allons-y gaiement:
1 – N’utilisez pas de framework
Je pense que ce point est de loin le plus essentiel. Les frameworks, c’est bien trop hype et sur-évalué. Cela ne sert strictement à rien d’embarquer des milliers de lignes de code dans son projet, et encore plus des milliers de lignes de codes d’inconnus ! De plus, ces frameworks vont vous faire perdre votre précieux temps à coder propre et bien, alors qu’en deux trois coups de cuillère à pot, quelques variables globales et boucles imbriqués bien placés, vous pouvez sortir la vue web qui va bien ! D’ailleurs, c’est sûr que vous coderez mieux avec vos petits doigts boudinés ce que des inconnus ont érigé en plusieurs mois.
2 – N’utilisez pas git (et à fortiori, Github)
Quelle perte de temps que de devoir apprendre des commandes obscures dans votre terminal (heu, c’est quoi un terminal d’abord ?), brancher, forker, rebaser à tout va, plutôt que de vous concentrer à ce qui compte vraiment, votre code, au sein de votre IDE ! De toutes façons, vous êtes en startup, à deux ou trois, débrouillards, vous pouvez bien vous envoyer les fichiers modifiés par email, c’est bien plus pratique ! En plus, en se débrouillant bien, vous n’aurez même pas à travailler en même temps sur les mêmes fichiers. Github, c’est vraiment pour les bobos hipsters du code qui veulent se faire mousser ! FTP FTW sur mon serveur !
3 – Ne perdez pas de temps à écrire des tests
Vous aussi vous avez entendu parler de ces gens qui passent bien 20-25% de leur temps à écrire des tests ?! Parfois même avant d’entamer leur code ? Dingue, non ? Il y en a qui n’ont vraiment que ça à faire. Autant aller travailler dans une SSII s’ils ont autant de temps à perdre ! Allez, zou, un peu de code, une bonne feuille Excel avec quelques tests fonctionnels à refiler à ses stagiaires, et c’est parti, ça marche super bien !
4 – Ne vous souciez pas de la sécurité
La sécurité, c’est pour Facebook ou la NASA. En startup, on en a pas besoin. Qui irait se soucier de nous et nous chercher des noises ? Il est important de ne pas se soucier de la sécurité pour avancer en codant vite. J’ai vu ce tweet circuler hier, qui parlait d’injections SQL en PHP. C’est un mythe ça, ça n’arrive jamais “en vrai”. Imaginez tous ces gens (qui d’ailleurs sont tombés dans le panneau du conseil n°2), s’ils devaient (suivez mon conseil n°1) coder leur ORM ou préparer / sanitizer leurs requêtes. Ils n’avanceraient jamais !
5 – N’utilisez pas de scripts de déploiement
Pour les mauvais élèves du conseil n°2, faites directement un git fetch en prod. Et à la rigueur exécutez quelques scripts / commandes sur la PROD. Mais je ne vous félicite pas ! La vraie solution miracle, c’est le FTP. FTP FTW sur mon serveur. Tellement plus facile de filer les accès à toute votre startup pour aller éditer en live et rapidement ce qui ne va pas sur votre serveur. C’est aussi facile d’envoyer que quelques fichiers remplacer les existants pour fixer vos bugs ou améliorer vos features. En plus, ça marche sur tous les serveurs le FTP, même les hébergements mutualisés ! :)
6 – Ne mettez pas de cache, alignez plutôt des serveurs / instances
Comme pour n°4, le caching, c’est pour Facebook ou Twitter. Franchement, pourquoi s’embêter et se casser la tête à réfléchir à de complexes stratégies de cache alors que ça coute presque plus rien les serveurs ? Commencez avec un petit Kimsufi (2Go de RAM), et si ça ne passe plus, prenez plus gros. Toujours plus gros. En plus, si vous avez bien suivi le conseil n°5, d’un coup de FTP, le tour est joué pour passer sur le nouveau serveur !
7 – Ne travaillez qu’avec des stagiaires ou des agences
Enfin, si vous arrivez à respecter tous les conseils précédents, faites vous ce cadeau: ne prenez que des stagiaires ou des agences à la rigueur. Mais ne perdez pas de l’argent à payer cher des développeurs qui se prennent pour des rockstars du code, qui ne comprennent rien au business, et qui vont vous faire perdre du temps à configurer des environnements de travail, retoucher des alignements et fixer des virgules ! Hop hop hop, ni une, ni deux, un cahier des charges, un feuille de recette (conseil n°3), un accès FTP à votre serveur de dev (ou prod?) (conseil n°5), et roulez jeunesse !
Voila, c’est tout. Je crois qu’avec ça, vous allez être parés désormais pour bien bien looser dans votre startup, et pouvoir dormir sur vos deux oreilles ou boire des coups avec vos associés en shippant rapidement du garbage tout en contentant vos clients ou utilisateurs à court (voire très court) terme.
Disclamer: ce billet n’est pas une fiction. Je suis moi-même passé par une bonne partie de ces points, et pu constater les autres au sein de startups de connaissances. Malgré le ton léger, ce billet est bien entendu à comprendre à l’envers (sinon, je vais avoir toute la profession et les associations sur le dos), et je vous encourage à partager vos expériences à ce sujet dans les commentaires.
Enfin, ceci doit probablement être mon premier billet depuis de longs mois (années ?) d’inactivité, veuillez m’excuser pour cette absence. Et si par ailleurs, vous avez des idées de sujets à traiter que je pourrais éventuellement couvrir, n’hésitez pas à m’en faire part dans les commentaires ou par email. Merci ! :)
Welcome back ;)
Welcome back aussi :)
Globalement d’accord avec le post, sauf peut-être le point 6 qui mériterait quelques détails.
Personnellement je ne suis pas friand des applications qui dépendent du cache pour avoir des perfs correctes, surtout si ça cache des requêtes qui prennent un temps fou quand il est invalidé.
Avant d’aller coller un Varnish devant l’applicatif, ça peut être utile de regarder si certaines pages ne pourraient pas être servies statiquement et certaines requêtes optimisées.
Sinon c’est globalement de bons conseils, surtout le 7. Ce n’est pas parce que les grands comptes en France font n’importe quoi avec l’externalisation que les startups doivent faire pareil ;)
Meh, pour le point 2 : merger c’est pas bien aussi. Na.
J’attends aussi avec impatience un post sur le coté administratif de la start up. Conseil #1: Levez les fonds avant d’avoir un produit?
Pas totalement d’accord avec le 2 (il n’est pas indispensable d’utiliser git/github – il est juste indispensable d’utiliser un VCS avec un repo centralisé) (NB: j’utilise git et github, et je le recommande)
Pas d’accord avec le fait d’ériger le cache comme une règle absolue : le cache est un outil qui répond à certaines problématiques, et toutes les problématiques ne se résolvent pas avec un cache. Tous les sites n’ont pas forcément non plus comme ambition de générer suffisamment de trafic pour qu’un cache soit nécessaire.
J’aurais ajouté à la liste “utilisez l’outil adapté à votre problématique”, pas parce que c’est à la mode, pas parce que X l’utilise. Node.js, mongodb, etc. ne sont pas adaptés à toutes les problématiques.
un gros +1 pour le reste
Haha +1 sur tout :-)
Manque juste “Ne vous jetez pas sur les technos à la mode”, genre “mySQL c’est out, on doit absolument faire notre app avec MongoDB” alors qu’on prévoit un site transactionnel…
Pingback: 7 conseils pour plomber techniquement votre startup web | Tour de France de la création d'entreprise
Réflexion personnelle depuis début 2015 au sujet de l’utilisation d’un framework pour un produit.
Je suis passé par les mêmes phases que toi pour finir directeur technique dans une agence de com, avant de revenir aux startups. Je rejoins entièrement ta vision sur les bonnes pratiques que ce soit technique, organisationnel, ou autre, après tout dépend des contextes évidemment, il faut adapter les méthodes à l’environnement.
Concernant le point 1 de cet article, je commence à emettre des réserves. Après avoir pas mal travaillé sur Zend 1 puis 2, puis Symfony 2, je constate que nous utilisons globalement qu’une très petite partie de ces 2 frameworks à moins de s’y investir corps et âme. Il y a quelques mois encore j’étais à 100% sur ces frameworks, et un jour j’ai donné un coup de main à un ami qui devait réaliser un site sans framework ou cms (pour son apprentissage du langage). Du coup on a refait un MVC maison (basé sur la logique Zend 1) ou 100% du code était utilisé.
Depuis j’ai entamé un lent désintéressement des frameworks pour les raisons suivante :
- nous les exploitons généralement assez mal, ou alors il faut s’investir tellement qu’il n’est pas possible de bien le faire sur plusieurs frameworks. Petite parenthèse, ça m’amuse toujours de voir passer des offres d’emploi du type “cherche expert drupal, ezpublish, wordpress, symfony2, …”
- les app utilisent de plus en plus de js/ajax, et côté serveur on se contente de faire se services ou à part vérifier l’intégrité des données + les différentes opérations de sécurité, il n’y a plus grand chose à faire
Du coup, bien que je trouve les frameworks indispensable, ils ne sont pas (plus) si indispensables au vu des nouvelles pratiques. Inutile de déployer les forces armées et les machines de guerre pour sécuriser une place de marché destinée à uniquement gérer les IO.
Hello,
Merci pour ton commentaire !
En effet il y a de moins en moins de “fullstack” et des pans entiers de frameworks ne “servent plus à rien”. Nous avons bien évolué avec Symfony2, nous utilisions un petit peu tout. Mais désormais, nous avons deux applications SPA Backbone et Ember, et n’utilisons Symfony2 plus que comme moteur d’API. Et même pour ce job bien spécifique, l’apport du framework est inestimable !
C’est un challenge pour ces frameworks, et on voit de plus en plus de projets / extensions / bundles pour Symfony2, RoR, Node, etc.. qui visent à faire uniquement de l’API tout en utilisant les composants indispensables de ces frameworks pour le faire.