Qu\u2019est-ce que la dette technique ?<\/h2>\n
Il existe plusieurs interpr\u00e9tations de la dette technique, mais la d\u00e9finition la plus commun\u00e9ment accept\u00e9e est toute d\u00e9cision prise dans le but d'obtenir des gains rapides m\u00eame si on le sait implique une refactorisation ou une r\u00e9vision \u00e0 une \u00e9tape ult\u00e9rieure<\/strong>. Dans notre cas, il peut s'agir par exemple d'impl\u00e9menter un morceau de code parfaitement fonctionnel et non align\u00e9 avec la strat\u00e9gie \u00e0 long terme du produit, ou de cas extr\u00eames laiss\u00e9s volontairement de c\u00f4t\u00e9 en l'absence d'exigences fonctionnelles qui en ont besoin \u00e0 ce moment-l\u00e0.<\/p>\n Comme la grande majorit\u00e9 des solutions logicielles d\u2019entreprise, la plate-forme Moneythor repose sur un grand nombre de biblioth\u00e8ques Open Source. Les logiciels Open Source ont toujours \u00e9t\u00e9 d\u00e9velopp\u00e9s par des particuliers ou financ\u00e9s par des leaders de l'industrie. Aujourd'hui, les grandes organisations contribuent de plus en plus au d\u00e9veloppement de nombreux projets de logiciels Open Source pour r\u00e9pondre \u00e0 leurs propres besoins. Pensez au d\u00e9sormais in\u00e9vitable Apache\u00a0Kafka<\/a> (de LinkedIn), Kubernetes<\/a> (de Google), R\u00e9agir<\/a> (depuis Facebook\/M\u00e9ta)\u00a0; la liste s\u2019allonge chaque jour.<\/p>\n Compte tenu de la complexit\u00e9 de la solution Moneythor, il serait inimaginable, extr\u00eamement long et co\u00fbteux de construire nous-m\u00eames tous les aspects de la solution, sans parler du risque de r\u00e9inventer la roue sans jamais atteindre le m\u00eame niveau de qualit\u00e9 de ces projets tiers sponsoris\u00e9s. par des organisations renomm\u00e9es et test\u00e9 de mani\u00e8re intensive dans plusieurs environnements de production.<\/p>\n Cela dit, la s\u00e9curit\u00e9 est une pr\u00e9occupation majeure. Personne n'aime entendre comment un service a subi une violation de donn\u00e9es, mais il est presque impossible d'\u00e9viter des vuln\u00e9rabilit\u00e9s comme celles r\u00e9guli\u00e8rement signal\u00e9es. Vuln\u00e9rabilit\u00e9s et expositions courantes<\/a> et n\u00e9cessitent souvent une action imm\u00e9diate pour y rem\u00e9dier.<\/p>\n En tant que tel, nous testons et s\u00e9lectionnons soigneusement toutes les biblioth\u00e8ques tierces, en consid\u00e9rant toujours les alternatives et la difficult\u00e9 de comprendre leur code source et de r\u00e9soudre nous-m\u00eames les probl\u00e8mes de s\u00e9curit\u00e9. Cela fait, nous l'int\u00e9grons dans notre solution avec les couches n\u00e9cessaires pour garantir qu'il puisse \u00eatre facilement mis \u00e0 niveau ou m\u00eame remplac\u00e9.<\/p>\n R\u00e9\u00e9crire le code source ou passer d\u2019une technologie \u00e0 une autre entra\u00eene souvent un co\u00fbt \u00e9lev\u00e9, difficile \u00e0 justifier aupr\u00e8s des parties prenantes. C\u2019est pour cette raison que nous prenons en compte la dette technique d\u00e8s l\u2019origine. La fa\u00e7on dont nous concevons notre solution joue ici un r\u00f4le important et parfois, nous n'h\u00e9sitons pas \u00e0 d\u00e9ployer un effort suppl\u00e9mentaire initial pour pr\u00e9parer la solution \u00e0 une fonctionnalit\u00e9 suppl\u00e9mentaire non confirm\u00e9e.<\/p>\n C'est \u00e9galement l'occasion pour nous d'enregistrer d\u00e8s le d\u00e9but ce qui sera consid\u00e9r\u00e9 comme des impl\u00e9mentations finales de nouvelles fonctionnalit\u00e9s et des \u00e9l\u00e9ments pour lesquels nous avons d\u00fb prendre quelques raccourcis pour produire une solution fonctionnelle \u00e0 temps, tout en sachant que certaines parties pourraient \u00eatre revisit\u00e9es plus tard.<\/p>\n Il est \u00e0 noter que les exigences fonctionnelles \u00e9voluent et que nous devons revoir le code existant. Dans ce cas, nous ne traitons pas d\u2019un poste de dette technique. Il s'agit simplement du cycle de vie naturel d'une solution constamment am\u00e9lior\u00e9e.<\/p>\n Cela dit, il est impossible de pr\u00e9dire l\u2019avenir et il est risqu\u00e9 de parier sur une solution ou un mot \u00e0 la mode \u00e0 venir. Par exemple, la solution Moneythor s'appuie sur les fondements de la suite d'applications Java Enterprise, une plateforme tr\u00e8s mature et respectable qui a soutenu le d\u00e9veloppement de millions de projets logiciels d'entreprise \u00e9prouv\u00e9s au cours des derni\u00e8res d\u00e9cennies. L'une des fonctionnalit\u00e9s de la plate-forme Java est la v\u00e9n\u00e9rable API Servlet bloquante, un mod\u00e8le \u00e9prouv\u00e9 diff\u00e9rent de l'approche de traitement de flux asynchrone non bloquante promue par la nouvelle initiative de programmation r\u00e9active.<\/p>\n Si cette derni\u00e8re devient l'approche par d\u00e9faut \u00e0 l'avenir une fois que la communaut\u00e9 et de nombreuses d\u00e9pendances auront adopt\u00e9 ce nouveau paradigme de programmation, cela pourrait cr\u00e9er une dette technique o\u00f9 il serait n\u00e9cessaire d'investir du temps pour apporter une solution \u00e0 un nouveau standard avec le m\u00eame niveau de performance. fonctionnalit\u00e9 comme avant.<\/p>\n Dans ce cas, le r\u00f4le de l\u2019\u00e9quipe d\u2019ing\u00e9nierie est encore une fois de concevoir la solution de telle mani\u00e8re que nous puissions minimiser l\u2019effort de r\u00e9\u00e9criture et d\u2019adaptation des fonctionnalit\u00e9s existantes sans avoir \u00e0 consacrer du temps \u00e0 adapter la logique m\u00e9tier existante.<\/p>\n Comme chacun le sait, le monde produit et consomme de plus en plus de donn\u00e9es chaque ann\u00e9e \u00e0 un rythme exponentiel. Le traitement et l'analyse d'une \u00e9norme quantit\u00e9 de donn\u00e9es ont toujours \u00e9t\u00e9 un d\u00e9fi majeur pour les organisations de tous les secteurs, y compris celui des services financiers. Il n\u2019est pas surprenant que l\u2019industrie du logiciel travaille et cr\u00e9e constamment de nouveaux outils visant \u00e0 r\u00e9soudre ces d\u00e9fis en constante \u00e9volution en mati\u00e8re de donn\u00e9es.<\/p>\n Alors que les bases de donn\u00e9es relationnelles \u00e9taient autrefois la base de donn\u00e9es par d\u00e9faut et que leurs versions g\u00e9r\u00e9es dans le cloud sont tr\u00e8s \u00e9volutives, il existe d\u00e9sormais des approches compl\u00e8tement diff\u00e9rentes sur la fa\u00e7on de conserver et d'interroger les donn\u00e9es. Passer d'une base de donn\u00e9es relationnelle traditionnelle \u00e0 quelque chose comme un magasin de documents n'est pas aussi simple que de basculer entre deux fournisseurs de bases de donn\u00e9es relationnelles diff\u00e9rents. Dans de nombreux cas, la solution existante s'appuie sur des principes et des contrats qui n'existent plus dans le nouveau magasin de donn\u00e9es.<\/p>\n Notre exp\u00e9rience dans ce secteur au cours des derni\u00e8res d\u00e9cennies et de multiples projets h\u00e9t\u00e9rog\u00e8nes montrent qu\u2019il existe un seuil au-dessus duquel la dette technique devient un trou noir et ce seuil diminue de plus en plus avec le temps, surtout lorsqu\u2019aucune action n\u2019est entreprise.<\/p>\n Cela signifie ceci\u00a0: lorsque la limite est atteinte, il peut s'av\u00e9rer impossible de rattraper votre dette technique, et au final, il vous en co\u00fbtera moins cher de tout r\u00e9\u00e9crire \u00e0 partir de z\u00e9ro, ce qui peut \u00eatre un effort important et d\u00e9moralisant. Lorsque cela se produit, toute l\u2019exp\u00e9rience et les connaissances que vous avez acquises avec une seule technologie doivent \u00eatre reconstruites.<\/p>\n Par exemple, passer de la populaire base de donn\u00e9es relationnelle PostgreSQL au \u00e9galement populaire magasin de documents Mongo DB ne consiste pas seulement \u00e0 rendre votre logiciel compatible avec les deux couches persistantes. Il s\u2019agit \u00e9galement de comprendre les implications que cela a sur le flux de donn\u00e9es, le processus transactionnel, les avantages et les inconv\u00e9nients des deux solutions, ce que vous obtenez et ce que vous perdez. Cela peut facilement \u00eatre n\u00e9glig\u00e9, entra\u00eenant des retards et des co\u00fbts suppl\u00e9mentaires, voire des \u00e9checs dans certains cas.<\/p>\n Comme mentionn\u00e9 pr\u00e9c\u00e9demment, il serait impossible de pr\u00e9voir les \u00e9volutions, et nous ne pouvons pas non plus raisonnablement tout mettre en \u0153uvre d\u2019un seul coup. Ce que nous pouvons faire, c\u2019est essayer de nous prot\u00e9ger contre les obstacles inutiles. Des mod\u00e8les d\u2019architecture et de conception bien connus et \u00e9prouv\u00e9s existent dans ce but pr\u00e9cis.<\/p>\n Premi\u00e8rement, la solution est construite au-dessus du Cadre de printemps<\/a>. Le point le plus important \u00e0 noter ici est que nous avons choisi Spring non seulement parce qu'il est extr\u00eamement populaire, bien entretenu et qu'il fournit un riche ensemble de sous-projets pour aider \u00e0 aborder de nombreux aspects des solutions logicielles d'entreprise, mais aussi parce qu'\u00e0 la base, c'est un framework d'injection de d\u00e9pendances qui nous permet de d\u00e9coupler notre code et facilite grandement la mise en \u0153uvre du s\u00e9paration des pr\u00e9occupations<\/a> principe.<\/p>\n Dans la mesure du possible, nous dissocions tout, des biblioth\u00e8ques tierces \u00e0 notre propre code afin que l'impl\u00e9mentation soit facilement rempla\u00e7able. Ensuite, une fois que nous d\u00e9cidons d\u2019impl\u00e9menter une nouvelle fonctionnalit\u00e9, nous commen\u00e7ons par d\u00e9coupler l\u2019impl\u00e9mentation concr\u00e8te de la logique m\u00e9tier avec le framework. Nous prenons \u00e9galement plus de temps pour concevoir une couche interm\u00e9diaire g\u00e9n\u00e9rique qui se situe entre le cadre technique aliment\u00e9 par Spring ou des biblioth\u00e8ques tierces et la mise en \u0153uvre des exigences m\u00e9tier. Le but de cette couche interm\u00e9diaire est de fournir une abstraction de l'objet de la fonctionnalit\u00e9 afin que nous puissions ult\u00e9rieurement la personnaliser facilement et la prot\u00e9ger de l'impact de la mise \u00e0 niveau ou du remplacement des composants techniques sous-jacents.<\/p>\n Le r\u00e9sultat est que la solution Moneythor devient elle-m\u00eame un framework avec une impl\u00e9mentation concr\u00e8te de la logique fonctionnelle, et pas seulement cette impl\u00e9mentation. Cela nous offre une grande flexibilit\u00e9, ce qui est extr\u00eamement pr\u00e9cieux dans notre cas. Cela nous donne \u00e9galement la possibilit\u00e9 de maintenir le m\u00eame produit pour tous les clients. Bien entendu, nous adaptons notre solution aux diff\u00e9rentes r\u00e9gions, environnements cibles et fonctionnalit\u00e9s sp\u00e9cifiques au client mais cela est r\u00e9alis\u00e9 gr\u00e2ce \u00e0 une seule version du code source sans aucun fork.<\/p>\n Aujourd\u2019hui, on peut mesurer les b\u00e9n\u00e9fices de cette approche. Nous avons commenc\u00e9 \u00e0 d\u00e9velopper cette suite d'applications il y a pr\u00e8s de 10 ans, et pourtant nous ne conservons aucune biblioth\u00e8que vuln\u00e9rable. Au lieu de cela, nous utilisons la derni\u00e8re version de Spring et d'autres composants tiers, ce qui nous permet d'ajouter la prise en charge de nouvelles technologies dans les limites du budget et sans avoir besoin de refactoriser une grande partie du logiciel. Enfin et surtout, cela maintient notre \u00e9quipe de d\u00e9veloppement motiv\u00e9e \u00e0 travailler sur une architecture moderne avec des technologies et des outils r\u00e9cents.<\/p>\n Il s'agit essentiellement de trouver le bon \u00e9quilibre entre une conception et une ing\u00e9nierie complexes et un co\u00fbt de retouche acceptable. Avec la solution Moneythor, nous avons r\u00e9ussi \u00e0 trouver cet \u00e9quilibre et continuerons de le faire.<\/p>\n \u00a0<\/p>\n\tPourquoi est-ce important pour nous ?<\/h2>\n
Soyez conscient de votre dette technique<\/h3>\n
Ma\u00eetriser la dette technique<\/h3>\n
Les syst\u00e8mes de stockage de donn\u00e9es cr\u00e9ent facilement une dette technique<\/h3>\n
La dette technique a des cons\u00e9quences<\/h3>\n
Notre approche pour g\u00e9rer la dette technique<\/h2>\n
![\"Abonnez-vous](\"https:\/\/www.moneythor.com\/wp-content\/uploads\/2024\/02\/Article-CTA-NEW-BRANDING.png\")
\t\t\t\t\t\t\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/a>\t\t\n