Rendez-vous 9 : Pourquoi nous avons supprimé le code qui a mis 9 ans à être construit
Publié: 2017-02-17Ce blog explique pourquoi et comment nous avons pu mettre au rebut notre code vieux de 9 ans et commencé à penser à neuf.
Chapitre un : Nomination en devenir
Entre 2004 et 2006, nous avions l'habitude de développer des sites Web sur WordPress pour l'industrie de la santé et du bien-être. Il y avait un plugin WordPress pour presque tous les besoins - à l'exception d'un plugin de planification. Nous avons reçu tellement de demandes pour un plugin de planification que nous ne pouvions pas suivre !
Donc, nous avons écrit notre propre script . Un script qui nous permettrait de gagner du temps en n'ayant pas à reconstruire le même code encore et encore. L'un des premiers défis auxquels nous avons été confrontés était que chaque secteur vertical avait des exigences spécifiques. Nous avons donc créé des règles de planification pour généraliser notre script pour différentes verticales.
Bientôt, la demande de planification a augmenté et Appointy a été lancé pour la première fois en janvier 2008 avec un concept «faites-le vous-même».
Malheureusement, dans notre zèle pour plaire à chaque client, nous avons continué à ajouter des fonctionnalités et Appointy est devenu écrasant. Et puis, les mêmes clients ont commencé à se plaindre. Nous avons réalisé que nous nous éloignons du concept Do-it-Yourself. Nous sommes donc retournés à la planche à dessin avec l'idée de faire à nouveau simple tout en gardant la fonctionnalité.
Cela nous a coûté une année entière. Mais nous avons appris une leçon importante.
Appointy est une entreprise en démarrage (n'a jamais levé de fonds externes) et a dû gagner de l'argent auprès des clients pour survivre . Nous pensons que la meilleure façon de gagner de l'argent est de résoudre d'abord le problème de quelqu'un, puis de demander un prix équitable. Plus nous pouvons aider nos clients, plus nous grandirons.
Nous avons commencé à améliorer notre processus d'intégration et d'assistance. Mais nous avons vite réalisé que chaque entreprise est unique par nature et a besoin de quelque chose de différent. Cela signifiait simplement que nous devions non seulement renforcer notre équipe de support, mais également que nous devions recruter plus de programmeurs. Nous avions besoin d'un moyen d'évoluer verticalement dans tous les départements.
Nous avons commencé à embaucher plus de programmeurs. Après quelques mois, lors d'une réunion scrum, un nouveau membre de l'équipe a partagé qu'il était heureux que quelque chose qu'il avait écrit soit en ligne sur notre site de production. Pour lui, c'était définitivement un exploit. Cependant, je n'étais pas content. J'ai réalisé qu'il y avait quelque chose qui n'allait pas dans notre configuration s'il faut des mois aux nouveaux programmeurs pour devenir productifs.
Il était temps de sortir du confort et de prendre des décisions audacieuses. Nous ne pouvions tout simplement pas évoluer aussi rapidement que nous le souhaitions à ce rythme !
Chapitre 2 : Une décision difficile mais excellente
Le lendemain, j'ai parlé à quelques gars seniors et j'ai essayé de comprendre le problème. Le problème est venu de l'architecture que nous avons créée il y a 9 ans. La technologie change chaque année et donc techniquement, nous avions presque 9 ans de retard .
Recommandé pour vous:
Je ne savais pas comment dire à mon équipe de changer tout le code qu'ils écrivaient depuis 9 ans. Je ne voulais pas avoir l'air fou et j'ai d'abord décidé de franchir le pas moi-même. Après tout, j'étais moi-même programmeur (et plutôt bon en plus !

J'écris toujours un objectif avant de commencer toute nouvelle tâche. Voici donc mon objectif : créer une architecture modulaire avec une courbe d'apprentissage de moins d'une semaine et développer une application extrêmement rapide. Si Google peut récupérer les bons résultats à partir de trillions de lignes en moins d'une seconde, pourquoi ne peut-il pas faire appel à Appointy ?
Je suis tombé sur un terme RxJS sur Angular.io. J'ai suivi le sujet pendant quelques heures et j'ai vraiment aimé l'idée de diffuser les données en continu. Le concept était simple : regarderiez-vous une vidéo sur Youtube si vous deviez attendre 5 minutes à chaque fois que vous vouliez la regarder ?
J'ai décidé d'essayer, mais la réalité était que je ne pouvais pas le faire moi-même. J'aurais besoin de l'aide des seniors.
Le lendemain, j'ai juste expliqué le concept de streaming à mon équipe et j'ai essayé de susciter l'intérêt. Pendant les jours suivants, j'ai continué le processus jusqu'à ce que nos rock stars (qui sont maintenant de bien meilleurs programmeurs que moi) prennent le rythme. La première graine du changement a été semée .
En quelques jours, nous avons pu implémenter tout le concept de streaming dans le code existant d'Apointy. Comme prévu, cela fonctionnait bien, mais n'était pas génial. Nous devions faire plus.
Chapitre 3 : Le suspense se déroule
Il restait encore deux problèmes à résoudre
- Interface utilisateur et expérience utilisateur (UX/UI).
- Vitesse de chargement.
1,5 mois s'étaient déjà écoulés et nous avions seulement acquis des connaissances . Aucune action pour le moment. Je n'ai pas pu demander aux seniors de travailler sur UX/UI et ils sauraient que nous essayions de supprimer l'ancien code et je ne savais pas ce qui se serait passé alors.
J'ai donc décidé de travailler avec l'un des stagiaires que nous avions embauchés. Ce nouveau stagiaire avait une approche différente du codage . Il voulait être rapide, plus rapide que n'importe qui d'autre. Il m'a aidé à mettre en place des outils afin que je puisse vérifier les changements en direct et lui faire part de ses commentaires instantanément. Nous avons tous les deux commencé à venir tôt à 6 heures du matin et au moment où notre bureau commencerait, nous aurions déjà mis quelques heures de travail. Le nouveau produit a commencé à prendre forme.
Après quelques jours, j'ai réalisé que tout fonctionnait très bien. Nous étions sur la bonne voie et il était temps de parler à toute l'équipe. Maintenant, j'avais une preuve de concept pour justifier que 9 ans de code peuvent être supprimés, mais pas sans notre équipe de rock star.
Le jour est arrivé. Nous avons montré la nouvelle interface utilisateur et expliqué les prochaines étapes pour la mise en ligne. Notre équipe de rock star a commencé à croire que cela pouvait être réalisé. C'est exactement ce qu'il fallait.
Après 4 mois, notre première version est en phase de test.
Résultat
- Nous sommes en mesure de réduire le temps de chargement de la "zone d'administration" de 10 secondes à 2 secondes. (Oui, 5 fois plus rapide !!)
- Nous sommes en mesure de réduire la charge sur nos serveurs de 50 %.
- Nous sommes en mesure de rendre les nouveaux programmeurs productifs en une semaine.
- Enfin, j'ai eu le temps d'écrire un blog!
Et après?
- La première étape consiste à porter le logiciel existant. La prochaine étape serait de créer des fonctionnalités indispensables (nous avons compilé les demandes de fonctionnalités de nos clients et notre liste de priorités est prête).
- Notre API est prête et peut être utilisée par notre équipe ou par des équipes externes pour intégrer différentes applications. Par exemple, nous n'aurions plus besoin de plus d'une semaine pour ajouter une nouvelle passerelle de paiement.
- Nous aurions plus de bande passante pour nous lier à d'autres entreprises qui peuvent ajouter plus de valeur à votre entreprise. Nous nous sommes déjà associés à Réserver avec Google pour vous aider à attirer de nouveaux clients.
PS : Au cours de ces 4 mois, nous avons non seulement créé Appointy à partir de zéro, mais également créé avec succès un autre produit de planification de salle de conférence à partir de zéro. Nous l'avons vendu pour 130 000 $ sans même rencontrer le client en personne.
[Cet article de Nemesh Singh est apparu pour la première fois sur le blog officiel et a été reproduit avec autorisation.]






