Comment refactoriser pour les Startups 2022 : raisons et compromis

(Cross posté depuis le site web de Klotho )

Ce billet de blog est un aperçu de haut niveau sur les raisons de refactoriser le code et les systèmes dans un environnement de démarrage. Nous couvrons les risques, les approches et les compromis à considérer en 2022.

Comment juger quand le coût vaut les gains

Soit honnête avec toi

La tentation sera toujours de refactoriser : le code du monde réel est désordonné et les ingénieurs n'aiment pas le code désordonné. Assurez-vous qu'il existe une analyse de rentabilisation pour la refactorisation en mesurant le temps que l'équipe consacre aux fonctionnalités directement visibles par le client.

Nos recherches montrent que les entreprises de taille moyenne et les startups à croissance rapide consacrent 39 % de leur capacité d'ingénierie à des travaux indifférenciés, comme l'infrastructure. Divisez les histoires en sous-tâches comme l'infrastructure et la refactorisation afin que vous puissiez mesurer où va votre temps.

Bien structuré est bien entretenu

Des limites claires entre les modules facilitent leur test, leur déploiement et leur surveillance. Gardez un œil sur les bogues signalés par les clients, la latence du service et la fréquence à laquelle vous devez annuler le code. À l'autre extrémité du cycle de vie du logiciel, il existe plusieurs indicateurs indiquant que vous tendez vers un goulot d'étranglement : le temps qu'il faut pour passer de la conception à la livraison, le degré de satisfaction de l'ingénierie et l'augmentation des coûts d'infrastructure ; ils peuvent tous être des indicateurs avancés. que vous vous êtes endetté.

Points d'inflexion dans les entreprises

Les bases de code ont tendance à s'organiser selon trois dimensions : la taille de l'équipe, le rythme des nouvelles fonctionnalités et le nombre de clients. Lorsque ces chiffres changent de manière significative, il peut être temps d'envisager de diviser les composants.

Si vous agrandissez l'équipe ou augmentez le taux de développement des fonctionnalités, le facteur limitant sera la lisibilité du code. Commencez par une refactorisation ciblée et opportuniste. Si votre clientèle augmente, vous aurez peut-être besoin de technologies ou de flux de travail plus évolutifs.

Contrôlez ce que vous pouvez, planifiez le reste

Bien choisir n'empêchera pas de repenser l'architecture

La refactorisation et la réarchitecture ne signifient pas que vous avez fait un mauvais choix plus tôt. Le plus souvent, les forces motrices derrière la réarchitecture sont liées aux changements d'exigences ou à des facteurs externes. Il y a au moins 4 dimensions importantes qui forceront une réarchitecture au cours de la durée de vie d'un produit : le taux de développement de nouvelles fonctionnalités, la taille de l'équipe d'ingénierie, le temps consacré à un travail indifférencié et la croissance de la clientèle. Chacun d'entre eux est progressivement plus difficile à contrôler directement.

Commencez par les cadrans faciles…

Sur les quatre dimensions, les deux plus faciles à contrôler sont le taux de nouveautés et la taille de l'équipe d'ingénierie. Vous pouvez contrôler le rythme des nouvelles fonctionnalités en étant plus strict sur la planification et la hiérarchisation. La mise à l'échelle de l'équipe est un processus plus lent, mais c'est généralement celui que vous pouvez au moins planifier.

Si l'équipe et le taux de nouvelles fonctionnalités sont petits, il est peu probable que la refactorisation ait un impact significatif sur l'entreprise. À l'autre extrémité du spectre, une grande équipe travaillant sur de nombreuses fonctionnalités peut bénéficier d'une réorganisation en équipes plus petites - et vous devriez envisager de refactoriser ou de ré-architecturer le code en conséquence. Une architecture qui permet des frontières organisationnelles et de code plus propres permettra au produit et à l'entreprise d'évoluer.

…puis passez aux plus difficiles

Le temps que votre équipe consacre à un travail indifférencié peut être difficile à maîtriser, et la croissance de la clientèle est la mesure la plus difficile à affecter. Si cela était facile, tout le monde minimiserait le travail indifférencié et maximiserait la croissance de la clientèle ! Pourtant, vous pouvez

devancez les problèmes grâce à une approche prudente et proactive de la refactorisation.

La première étape est de savoir quand ne pas refactoriser. Si la croissance de votre clientèle et le temps consacré à un travail indifférencié sont faibles, ne passez pas de temps à refactoriser : concentrez-vous plutôt sur des fonctionnalités percutantes et visibles par le client. De même, si vous avez une bonne croissance de la clientèle et une faible quantité de travail indifférencié, votre équipe se porte bien. Envisagez une refactorisation tactique pour éviter que la quantité de travail indifférencié n'augmente, mais n'y consacrez pas trop de temps.

Si votre équipe passe trop de temps sur un travail indifférencié, il est temps de revoir l'architecture en une architecture qui s'adapte mieux à la situation actuelle de votre entreprise.

Si l'adoption de votre client est plus faible, votre priorité devrait être une architecture moins chère qui vous donnera plus de piste.
Si l'adoption par vos clients et le temps que votre équipe consacre à un travail indifférencié sont élevés, il est peut-être temps de se concentrer sur une solution centralisée et optimisée. Cela prend généralement la forme d'une équipe d'exploitation dédiée qui peut exécuter efficacement les tâches d'infrastructure. C'est un grand problème à avoir - alors prenez un moment pour vous féliciter, vous et votre équipe, d'être arrivés ici !

Ayez un objectif, puis trouvez des raccourcis pour y arriver

Ayez un plan, même s'il n'est pas parfait

Une fois que vous vous êtes engagé dans une ré-architecture, n'ayez pas peur de voir grand. Appuyez-vous sur vos ingénieurs pour trouver un état final qu'ils aimeraient, puis réduisez-le au besoin. Il y a de fortes chances que l'opportunité d'une ré-architecture majeure ne se présente qu'une ou deux fois dans le cycle de vie d'un produit, alors soyez prêt à accepter tout compromis que vous ferez. Mais du même coup, sachez que même les plans les mieux conçus iront de travers lorsque vous commencerez à les mettre en œuvre.

Faites de grands projets, faites de petits pas

Une fois que vous savez où vous voulez que le code soit, soyez tactique sur la façon de l'y amener. Travaillez un composant à la fois ou choisissez des composants aussi éloignés que possible les uns des autres. Si vous n'avez pas encore investi dans des tests solides, tant au niveau de l'unité que du système, c'est le moment. Les tests vous donneront l'assurance que vos modifications n'affecteront pas l'expérience client existante, mais ils peuvent également aider votre équipe à définir sa définition du terminé. Lorsque les tests passent, le composant est prêt !

La meilleure technologie est celle que vous pouvez adapter

La clé pour réduire l'impact de la refactorisation et de la réarchitecture sur les startups en particulier est d'utiliser une technologie adaptable.

Historiquement, les entreprises choisissent des technologies spécifiques telles que les machines virtuelles, le sans serveur ou les conteneurs pour héberger leurs applications. Le problème, c'est que passer d'une technologie à une autre coûte trop cher, et ce dont vous avez besoin aujourd'hui n'est peut-être pas ce dont vous aurez besoin demain.

Une architecture adaptative est une architecture qui vous permet d'héberger votre application sur n'importe quelle technologie avec la même facilité. Cela vous permet d'ajuster l'environnement d'hébergement à la volée, en fonction de vos besoins actuels. Des choix technologiques spécifiques comme AWS Lambda, Fargate, Kubernetes, gRPC, Linkerd, Azure/GCP deviennent interchangeables.

En réutilisant des constructions de langage de programmation existantes telles que des fonctions et des gestionnaires d'événements, ainsi que des interfaces idiomatiques pour chaque langage, les architectures adaptatives facilitent l'utilisation des services cloud.

Recherchez des abstractions et des outils légers, mais suffisamment flexibles pour vous permettre de changer de technologie. Nous pensons que les annotations Klotho conviennent parfaitement, car elles vous permettent de séparer la signification sémantique de votre architecture de la configuration de déploiement, mais avec un investissement suffisant dans les bibliothèques d'exécution et l'automatisation de l'infrastructure, vous pouvez créer vous-même une solution similaire.