3 éléments témoignant que votre logiciel devient une « usine à gaz » 3 éléments témoignant que votre logiciel devient une « usine à gaz » 3 éléments témoignant que votre logiciel devient une « usine à gaz » INTRODUCTION Les choix techniques de l'éditeur de logiciel relèvent de la stratégie et doivent être pris en fonction de son marché. Cependant, malgré toute la bonne volonté du dirigeant, un logiciel peut vite se révéler être une "usine à gaz". Quels sont les critères pour l'identifier ? Les points ci-dessous viennent en partie d'une traduction de l’article publié par Jon Evans dans Techcrunch Nous l'avons complété par nos retours d'expérience en la matiére avec des cas chez des éditeurs de logiciel RECRUTEMENT 1/ Temps d’intégration d’une nouvelle recrue = Dette technique Une dette technique n’est pas toujours une mauvaise chose, mais elle peut vous tuer en devenant trop conséquente. Lorsque l’on a un calendrier de livraison de nouvelles versions serré, ou lorsque de nombreux développeurs intègrent et quittent un projet, il est parfois plus facile de créer des sous-systèmes et de les connecter entre eux. Il est très difficile de mesurer une dette technique, particulièrement pour un non développeur. Cependant il y a des signes révélateurs : la capacité à intégrer de nouveaux développeurs dans l’entreprise. Demandez-vous donc : combien de temps cela me prend-il pour former une nouvelle recrue et qu’il soit capable de lancer du code en production ? La réponse devrait être inférieure à quelques heures. Et là vous vous dites, mon environnement est trop complexe ! Nous avons des machines virtuelles, de nombreuses bases de données et des réseaux privés ! Impossible qu’un nouveau développeur lance en prod’ en quelques heures ! Et pourtant, si votre nouvelle recrue a besoin de plus d’un jour pour être capable de lancer en production, luttant avec les différentes configurations et environnements, c’est que vous avez dû accumuler une dette technique. LES TESTS 2/ Le point critique de la suite de tests Il est évident que vous devez écrire et mettre en œuvre des batteries de tests pour votre code. Et dans un monde parfait, vous auriez une suite de test entièrement à jour pour l’intégralité de votre code, lancé automatiquement pour chaque production. Malheureusement, dans le test comme dans la vraie vie, le parfait est souvent l’ennemi du bien. Il est impressionnant de voir le nombre de suites de test très élaborées, dépassées depuis plusieurs mois ou prenant une éternité à mettre en œuvre. Les développeurs écrivent des tests mais ne les lancent pas régulièrement, ce qui les rend obsolètes. La pression liée aux dates de livraison des nouvelles versions rend ces actions non prioritaires, nous faisant rentrer dans un cercle vicieux rendant les suites de tests rapidement inutilisables. La ré-écriture de ces tests peut alors prendre une éternité et ralentir votre développement. Maintenir une suite de tests complexe coûte cher. Après avoir revu votre code, vous devez revoir vos tests : les redévelopper, ce qui prend du temps, ou les laisser tomber. La meilleure solution est donc de réduire votre suite de tests. Cela ne paraît pas très attirant, mais il vaut mieux une petite batterie de test que vous utilisez plutôt qu’une grosse suite de test que vous ignorez. SERVEURS 3/ Arrêtez ou continuer les serveurs maison ? Les projets dans les grande entreprises ont tous les mêmes problèmes : ils tournent sur des serveurs maison. Ils ont leurs propres machines, leurs propres sysadmins, leurs propres processus de patch, de mise à jour et de déploiement du code, et leurs propres paranoïa en sécurité. Le résultat ? Chaque production devient extrêmement complexe. L'hébergement et la gestion d'infrastructure est un vrai métier. La question à se poser : nos sysadmins sont-ils meilleurs que ceux d'hébergeur spécialisé comme OVH ? Et comme la question est bien souvent non, il faut alors se poser la question : « pourquoi ne pas laisser les experts s’en occuper ? ». Il peut y avoir des ralentissements serveurs et cela engendre une perte de contrôle : une analyse coûts/bénéfices s’impose ! LE PLUS Le développement de logiciel doit se penser de façon industrielle avec à la base, la mise en place de normes et de standard, d'un cadre méthodologique (agile ou autre), des métriques (KPI) et des outils adaptés : chaine d'outils Devops et autres outils de tests. On ne développe pas directement dans l'environnement de production comme cela se voit parfois (cela existe encore malheureusement). Il nous arrive réguliérement d'intervenir pour retravailler et mettre en place une organisation adaptée à la production de logiciel de qualité optimale (TRL9). Des méthodes et outils sont à disposition de nos abonnés ainsi qu'à nos clients. Contactez nous par l'intermédiaire du bouton "conseils" pour en bénéficier Conseils industrie logicielle Recherche de logiciels