Steel Threads est une approche de conception logicielle puissante mais obscure. En savoir plus sur les fils d'acier fera de vous un meilleur ingénieur. Vous pouvez les utiliser pour éviter des problèmes courants comme la douleur d'intégration. Et vous pouvez les utiliser pour réduire la complexité de la conception du système. Si obscur, il a été supprimé de Wikipédia en 2013 À quel point les fils d'acier sont-ils inconnus ? Le concept a été en 2013 parce que "l'idée n'est pas notable dans le génie logiciel et n'a pas reçu de couverture significative de la part de sources notables". Ajoutons à la couverture et parlons également de la raison pour laquelle il s'agit d'une approche si utile. supprimé de Wikipédia Que sont les fils d'acier ? Un fil d'acier est une très fine tranche de fonctionnalité qui se déroule dans un système logiciel. On les appelle un « fil » parce qu'ils se faufilent à travers les différentes parties du système logiciel et implémentent un cas d'utilisation important. Ils sont appelés "acier" car le fil devient une base solide pour des améliorations ultérieures. Avec une approche Steel Thread, vous construisez la version la plus fine possible qui dépasse les limites du système et couvre un cas d'utilisation important. Exemple d'approche conventionnelle et problématique Supposons que vous construisez un nouveau service pour remplacer une partie de votre base de code monolithique. La façon la plus courante de le faire serait Examinez l'ancien code et déterminez les besoins du nouveau système. Concevez et créez les API qui fournissent les fonctionnalités dont vous avez besoin. Accédez à l'ancien code et mettez à jour les références pour utiliser les nouvelles API. Faites-le derrière un drapeau de fonctionnalité. Coupez à l'aide de l'indicateur de fonctionnalité. Résolvez tous les problèmes qui surviennent jusqu'à ce que cela fonctionne, en désactivant l'indicateur de fonctionnalité si nécessaire pour revenir à l'ancien chemin de code. Lorsqu'il est stable, supprimez les anciens chemins de code. Cela semble raisonnable, non ? Eh bien, c'est la façon la plus courante dont les ingénieurs logiciels fonctionnent, mais cette approche a beaucoup de mines terrestres. À quels problèmes dois-je m'attendre dans ce projet ? Il peut être intéressant de construire le nouveau service d'une manière déconnectée de l'ancien système. Après tout, le design pourrait sembler plus pur. Mais vous introduisez également beaucoup plus de changements structurels, et vous apportez ces changements sans aucune intégration à l'ancien système. Cela augmente considérablement la douleur d'intégration. Je m'attends à ce que toutes les estimations du projet soient irréalistes. Et je m'attendrais à ce que le projet soit considéré comme un échec une fois terminé, même si le service qui en résulte est généralement bien conçu. Je m'attends à ce que le passage au nouveau système soit problématique. Il y aura une série de problèmes découverts au fur et à mesure que vous basculerez qui nécessiteront de revenir aux anciens chemins de code ou de travailler intensément pour résoudre les problèmes dans les étapes finales du projet. Ces deux choses sont évitables, en n'ayant pas une énorme transition. Notez que même couper plus d'un pour cent du trafic vers le nouveau service avec un indicateur de fonctionnalité est une approche de basculement. Pourquoi? Vous coupez tout ce un pour cent du trafic vers tous les changements en même temps. Je ne m'attendais toujours pas à ce que ça se passe bien. Vous faites des pas trop grands. Exemple d'utilisation d'un filetage en acier Comparez cette approche avec la façon dont Steel Thread le fait. Pensez au nouveau système que vous construisez. Trouvez des cas d'utilisation étroits qui représentent les fils d'acier du système - ils couvrent les fonctionnalités utiles du système, mais ne gèrent pas tous les cas d'utilisation ou sont limités d'une certaine manière. Choisissez un cas d'utilisation de départ aussi étroit que possible qui apporte une certaine valeur. Par exemple, vous pouvez choisir une API qui, selon vous, ferait partie du nouveau service. Développez la nouvelle API dans un nouveau service. Faites-le fonctionner pour ce cas d'utilisation étroit. Pour tout autre cas d'utilisation, utilisez l'ancien chemin de code. Mettez-le en production et utilisez-le pleinement. (Astuce : vous pouvez même faire à la fois le nouveau et l'ancien chemin de code, et comparer !) Ensuite, vous ajoutez progressivement les cas d'utilisation supplémentaires, jusqu'à ce que vous ayez déplacé toutes les fonctionnalités dont vous avez besoin vers le nouveau service. Chaque cas d'utilisation est en production. Une fois que vous avez terminé, vous arrachez l'ancien code et les indicateurs de fonctionnalité. Ce n'est pas risqué du tout, puisque vous utilisez déjà le nouveau système. N'est-ce pas aussi le motif « étrangleur » ? Oui, mais cela peut aussi être utilisé pour de nouveaux projets. Lisez la suite pour un exemple de greenfield. Les filetages en acier évitent les problèmes d'intégration et vous donnent une plus grande confiance La difficulté d'intégration est l'une des principales causes de problèmes de dernière minute dans les projets. Lorsque vous passez à un nouveau système, vous rencontrez des problèmes auxquels vous ne vous attendiez pas. Vous devez vous méfier de tout ce qui implique une transition. Faites les choses par petits incréments. toujours Les fils d'acier s'intègrent dès le début, de sorte que vous n'avez jamais beaucoup de difficulté à traverser l'intégration. Au lieu de cela, vous avez une petite douleur d'intégration, tout au long du chemin. En outre, votre service n'a jamais besoin d'être testé avant sa mise en ligne, car vous l'avez testé de manière incrémentielle, en cours de route. Vous savez qu'il peut gérer des charges de production. Vous avez déjà ajouté la latence du réseau, vous en connaissez donc les implications. Toutes les surprises sont avancées et gérées progressivement, dans le cadre du déploiement progressif du service. L'important est que vous disposiez d'un système intégré et fonctionnel, et que vous continuiez à le faire fonctionner à mesure que vous y travaillez. Et vous l'étoffez avec le temps. Les filetages en acier peuvent aider à réduire la complexité Lorsque vous concevez un système, vous avez BEAUCOUP de complexité. Construire un ensemble d'exigences pour le nouveau système peut être une entreprise difficile. Lorsque vous utilisez une approche Steel Thread, vous choisissez certaines des exigences de base et les formulez d'une manière qui traverse les couches du système et exerce votre conception. Il fournit une sorte de structure squelettique pour l'ensemble du système. La mise en œuvre de ce fil d'acier devient alors l'ossature sur laquelle d'autres exigences peuvent être construites. Ainsi, les fils d'acier sont un d'un système. sous-ensemble des exigences Les filetages en acier peuvent également être utilisés sur les travaux de Greenfield Disons que vous implémentez un clone de Slack. Votre fil d'acier initial pourrait ressembler à : « Toute personne non authentifiée peut poster un message dans une salle #générale codée en dur dans un compte codé en dur. Les messages persistent lors des actualisations de page. » Notez à quel point ce fil d'acier initial est limité. Il ne gère pas l'authentification, les utilisateurs ou les comptes. Il gère l'écriture des messages et les persiste. Votre deuxième fil d'acier peut faire en sorte que le système soit plus utile. Vous pourriez, par exemple, avoir un fil d'acier qui permet à l'auteur du message de choisir le nom sous lequel il publie. Ce deuxième fil d'acier n'a pas fait grand-chose. Vous n'avez toujours pas d'authentification, de comptes ou même de concept d'utilisateur. Mais vous avez créé une salle de chat qui fonctionne suffisamment pour que vous puissiez commencer à l'utiliser. Notez également que vous n'avez pas tiré le fil d'acier dans toutes les parties du système. Mais vous avez supprimé les concepts d'utilisateurs et de comptes. Les filetages en acier fournissent une rétroaction précoce Notez que dans cet exemple de clone Slack, vous pouvez obtenir des retours précoces sur le système que vous construisez, même si vous n'en avez pas encore beaucoup construit. C'est une autre raison puissante d'utiliser des fils d'acier. Après seulement ces deux fils d'acier, votre équipe pourrait commencer à utiliser la salle de discussion à plein temps. Pensez à tout ce que votre équipe apprendra de l'utilisation de votre système. C'est un système qui fonctionne. Comparez cela à ce que vous auriez appris en construisant les systèmes d'utilisateur et de compte, en connectant tout et enfin en créant une salle de discussion. Commencez avec des fils d'acier Les fils d'acier sont souvent un bon point de départ lors de la conception de vos projets. Ils créent un squelette pour le reste du travail à venir. Ils clouent les parties centrales du système afin qu'il y ait des endroits naturels à étoffer. Je vous encourage à essayer une approche filetée en acier. Je pense que vous trouverez que cela peut transformer vos projets. Faites-moi part de vos expériences avec ça! Les fils d'acier sont étroitement liés aux tranches verticales Vous avez peut-être entendu parler du terme «tranchage vertical». Je décris le concept dans mon post sur . Milestones Steel Threads est une technique de conception de logiciels qui permet de fournir votre logiciel en tranches verticales. Le terme a tendance à être utilisé pour décrire les tranches verticales initiales d'un système. Ce sont des concepts étroitement liés, mais pas complètement identiques. J'ai aussi entendu dire que Steel Threads était appelé « balles traçantes ». Image de parSteen Jepsen Pixabay Cette histoire est apparue à l'origine sur : https://www.rubick.com/steel-threads/

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Making security fun one episode at a time

Comment devenir un meilleur ingénieur : fils d'acier

Trop long; Pour lire

Jade Rubick

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

Comment devenir un meilleur ingénieur : fils d'acier

Trop long; Pour lire

Jade Rubick

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES