GIFTED : Développement web, pentesting et audit web SEO à Reims

GIFTED - AUDIT DÉVELOPPEMENT WEB

Dette technique : le Guide Ultime

Rendre votre site accessible l'ouvre à un public plus large, ce qui peut être idéal pour les entreprises. Mais que signifie « Accessibilité » dans la pratique ? Et que devez-vous faire pour rendre votre site web plus accessible ? Nous explorerons ces questions dans cet article.

En savoir plus

La seule agence qui vous récompense !
Recevez 5% de cashback pour tous les clients que vous nous apportez.

Découvrez notre guide ultime concernant la dette technique et ne vous laissez plus surprendre par les surcoûts liés à vos projets.

La dette technique ressemble à un terme financier, c'est là que cette théorie de la programmation a ses racines. En matière de développement logiciel , la dette technique est l'idée que certains travaux nécessaires sont retardés pendant le développement d'un projet logiciel afin d'atteindre un livrable ou un délai.


  1. Dette technologique : quand mieux est l'ennemi de bien
  2. Définir la dette technique et le cruft
  3. Technicités de la dette technique
  4. Bon vs mauvais : Raisons de la dette technique
  5. Types de dette technique
  6. Entropie logicielle
  7. Identification de la dette technique
  8. Comptabilisation des exigences non fonctionnelles (NFR)
  9. Eviter (trop) la dette technique
  10. Évaluation de la dette
  11. Communiquer la dette
  12. Rembourser la dette
  13. GIFTED à Reims : Réduire la dette dans de nouvelles initiatives

Dette technologique : quand mieux est l'ennemi de bien

Par nature, les développeurs doivent toujours trouver un équilibre entre ce problème : développer une application, un logiciel, un système, etc. parfaitement conçus, par rapport à la publication d'un code suffisamment bon. Un code propre et bien conçu permet aux futures itérations et innovations d'être plus facilement mises en œuvre. Cependant, dans un environnement professionnel, les délais et les ressources limitées empêchent souvent les développeurs de produire un code propre et parfait avant de livrer un produit.

C'est là que la dette technique entre en jeu. Le concept reconnaît un compromis entre des produits parfaits et les courts délais souvent requis pour la livraison des produits. Bien qu'il puisse être utile de contracter des dettes, tout comme pour les questions d'argent, il y a une limite au montant de la dette que vous souhaitez assumer.

Définir la dette technique et le cruft

Le concept de dette technique est que la « dette » représente le travail de développement supplémentaire qui survient lorsqu'un code médiocre est mis en œuvre à court terme, bien qu'il ne s'agisse pas de la meilleure solution globale de qualité. Le code médiocre, qui est généralement redondant, mal conçu, inutile ou les trois, est appelé cruft.

Quelle est la définition exacte de la dette technique ? Le Software Engineering Institute de l'Université Carnegie Mellon note que la dette technique "conceptualise le compromis entre l'avantage à court terme d'une livraison rapide et la valeur à long terme". Une autre perspective vient de l'analyste industriel Gartner , définissant la dette technique comme l'écart d'une application par rapport à toute exigence non fonctionnelle.

Voici un exemple général : Imaginez que vous êtes un développeur de logiciels et que vous devez ajouter une nouvelle fonctionnalité à un logiciel ou à un système. Il y a deux chemins à choisir :

  • L'itinéraire le plus simple, composé d'un code ou d'une conception plus désordonné, vous y conduira plus rapidement.
  • La route la plus difficile, composée d'un code et d'une conception plus propres, prendra plus de temps.

Comme la dette monétaire, la dette technique peut accumuler des « intérêts ». Dans ce concept, l'intérêt est la difficulté croissante qu'il peut être d'implémenter des changements par la suite, d'autant plus qu'un projet logiciel passe par plusieurs phases. Plus la dette technique est ignorée ou non traitée, plus l'entropie logicielle peut se produire.

La dette technique, c'est comme nettoyer en cachant tout sous le canapé - c'est rangé pour l'instant, mais rien n'est à sa place. Vous devrez éventuellement passer du temps à le nettoyer et à l'organiser correctement afin de trouver quelque chose que vous recherchez.

Quelle que soit la façon dont vous choisissez de le définir, reconnaître l'importance du concept de base fournit le meilleur point de départ pour réduire les risques. Cela signifie affiner la capacité à reconnaître le fait que les problèmes liés au code source ont un impact négatif sur la productivité et concevoir un plan pour remédier à cet impact.

Technicités de la dette technique

La dette technique n'est pas globale. Une distinction importante est que la dette technique n'inclut aucune caractéristique ou fonction que vous n'avez pas intentionnellement construite. (Peut-être, par exemple, une fonctionnalité a-t-elle été initialement définie, mais supprimée par la suite lorsque les délais ont changé.)

Au lieu de cela, la dette est contractée lorsque le service informatique choisit de retarder un meilleur codage et de créer des éléments internes qui devraient être là, pour diverses raisons. Mais ce choix d'ignorer certaines pièces est entendu qu'il entravera le développement et la livraison futurs s'il n'est pas fait - et si l'équipe ne revient pas pour résoudre le code médiocre ou résoudre les bogues connus, le résultat est l'intérêt cumulé.

Bien que la dette technique puisse faire référence à n'importe quelle partie du développement logiciel, elle est généralement associée à une programmation extrême, en particulier à la refactorisation de code . La refactorisation est la restructuration du code existant dans le cadre du processus de développement, sans modifier le comportement externe du code (par exemple, la refactorisation d'un morceau de code mal écrit qui prend n'importe quel nombre et le multiplie par deux produira toujours 2 x 2 = 4, même après le code sous-jacent a été réécrit).

Les deux principales raisons pour lesquelles un développeur refactorisera sont les suivantes :

  • Résoudre le code hérité mal écrit
  • Faire évoluer les solutions au fur et à mesure qu'un problème est mieux compris

Bon vs mauvais : Raisons de la dette technique

Tout comme la dette financière, il peut y avoir de bonnes raisons pour la dette technique, mais il est important de savoir qu'en entrant, la dette ne devance pas l'équipe, ce qui ralentit les progrès et les livraisons futures.

Une bonne raison de contracter une dette technique est souvent qu'une livraison est plus importante que la propreté interne du code ou la fluidité des fonctionnalités. Si le produit fonctionne pour l'utilisateur, bien qu'il ne soit pas le meilleur ou le plus propre, la livraison peut incomber à votre entreprise en termes de délai de mise sur le marché, de revenus, etc. Si, toutefois, les besoins de l'entreprise nécessitent une conception parfaite, vous prendrez votre temps pour offrir un produit plus propre.

Une mauvaise raison de contracter une dette technique est que l'équipe a choisi de se concentrer sur d'autres domaines plus innovants ou intéressants mais moins importants.

Même si vous avez une bonne raison de contracter une dette, choisir l'option la plus désordonnée qui assure une livraison plus rapide n'est pas la fin de ce choix de conception. Au lieu de cela, l'équipe doit revenir, à un moment donné, à cet élément de conception pour ajouter plus de fonctionnalités ou le réviser. Plus l'équipe attend pour traiter un problème, plus il est susceptible de causer plus de problèmes ou d'être enfoui dans le code. C'est ça l'intérêt : le temps qu'il vous faudra dans le futur passer à nettoyer pour qu'il s'adapte aux nouvelles modifications que vous devrez apporter.

Les équipes de développement doivent être équilibrées. Examiner de nombreux aspects de la question pour déterminer si ou combien de dette technique contracter.

Types de dette technique

Comme nous l'avons vu ci-dessus, la dette technique est un résultat normal du développement logiciel - certaines d'entre elles se produisent pour une bonne raison. Et certains types de dette technique sont pires que d'autres :

Dette technique prévue

Ce type de dette technique survient lorsque l'organisation prend la décision éclairée de générer une dette technique en ayant pleinement conscience des conséquences (risques et coûts). Dans le cas d'une dette technique planifiée, il est essentiel d'être le plus précis possible dans la définition des compromis que l'organisation entend faire.

Un exemple pourrait être : « Afin de respecter la nouvelle date limite de publication de novembre, nous avons décidé de renoncer à écrire des tests unitaires au cours des trois dernières semaines du projet. Nous écrirons ces tests après la sortie.

Étant donné que ces décisions peuvent s'accumuler rapidement au fil du temps, il est impératif d'en conserver une trace. Cela augmentera la probabilité que la dette technique soit traitée et remboursée plus rapidement. Sinon, il sera rapidement oublié, ce qui pourrait coûter cher à l'organisation à long terme.

Dette technique involontaire

Il s'agit de la dette technique non planifiée qui survient en raison de :

  • Mauvaises pratiques
  • Inexpérience avec les nouvelles techniques de codage
  • Problèmes de déploiement

Par exemple, une approche de conception qui finit par contenir de nombreuses erreurs est une dette technique involontaire. Ce type se produit parfois comme le résultat direct d'une mauvaise communication au sein de l'organisation ou d'un désalignement entre les développeurs et les équipes d'exploitation .

Une dette technique incontournable

La dette inévitable se produit en raison des changements dans l'entreprise et des progrès de la technologie au fil du temps qui présentent de meilleures solutions. Cela survient généralement lorsque des changements de portée sont demandés à mi-projet, ce qui entraîne un coût immédiat, comme l'ajout d'une nouvelle fonctionnalité à une conception existante pour mieux prendre en charge la livraison mobile. En bref, une dette technique est créée lorsque de nouvelles exigences métier rendent l'ancien code obsolète.

Entropie logicielle

Également connue sous le nom de bit-rot, l'entropie logicielle se produit au fil du temps à mesure que la qualité du logiciel se détériore lentement, entraînant des problèmes d'utilisation, des erreurs ou des mises à jour nécessaires. L'entropie se produit lorsque de nombreux développeurs, dont beaucoup ne comprennent peut-être pas la fonction et la conception prévues, apportent des modifications incrémentielles qui augmentent la complexité, violent les exigences NFR ou cassent lentement le code.

La solution à l'entropie logicielle est la refactorisation.

Identification de la dette technique

Voici quelques signes avant-coureurs qu'un projet a créé une dette technique :

  • Les erreurs de code sont beaucoup plus subtiles que les erreurs de logique et indiquent des problèmes qui sont plus susceptibles d'avoir un impact sur la qualité globale des performances que de provoquer un plantage.
  • Des niveaux de complexité plus élevés lorsque les technologies se chevauchent.
  • Bogues du produit qui provoqueront un plantage complet du système.
  • Problèmes avec le style de codage , qui peuvent être traités en développant un guide de style de codage et en s'y tenant.
  • Problèmes d'exigences non fonctionnelles où le code viole une restriction NFR. Les exemples incluent des performances lentes, des hacks de sécurité, des résultats de code peu fiables, une utilisation de plus en plus difficile, une perte de compatibilité avec d'autres logiciels ou matériels.

L'élément clé à noter à ce stade est que, s'ils ne sont pas traités, ces drapeaux rouges peuvent entraîner :

  • Coût total de possession plus élevé
  • Délai de mise sur le marché plus long
  • Agilité réduite
  • Expérience client négative
  • Mauvaise sécurité

Comptabilisation des exigences non fonctionnelles (NFR)

L'utilisation de la définition Gartner de la dette technique nécessite une analyse approfondie des exigences non fonctionnelles (NFR). Comprendre ces exigences non fonctionnelles est important pour identifier la dette technique. Chaque système a des NFR, bien qu'ils ne soient souvent pas définis ou suivis. Les NFR font référence aux contraintes d'un système logiciel et incluent les sept attributs suivants :

  • Compatibilité
  • Sécurité
  • Fiabilité
  • Convivialité
  • Efficacité
  • Maintenabilité
  • Portabilité

Il existe également des sous-caractéristiques importantes des NFR :

  • Des exigences explicites sont prédéfinies par les principales parties prenantes, telles qu'une spécification de conception détaillée, par exemple.
  • Les exigences implicites sont celles qui sont attendues mais qui n'ont pas été énoncées sans équivoque Un exemple est d'assurer la facilité d'utilisation de l'application.

En revanche, les exigences fonctionnelles décrivent ce que le système doit faire et sont beaucoup plus faciles à mesurer et à analyser, par exemple dans le cas des épopées. La satisfaction des exigences fonctionnelles et non fonctionnelles est essentielle pour assurer le succès du projet.

Eviter (trop) la dette technique

Alors que la dette financière est facile à suivre, la dette technique n'est pas une métrique en soi. Avec quelques ajustements, la théorie de la dette technique peut être traduite en certaines mesures, telles que le délai de mise sur le marché par rapport au temps passé à faire des heures supplémentaires pour rembourser les intérêts. Ou cela peut se traduire par une baisse de la productivité d'une équipe, ce qui est également difficile à mesurer.

Évaluation de la dette

Lors de l'identification de la dette technique, vous pouvez rencontrer certains signaux clés. Par exemple, les notes de performance de votre produit peuvent être en baisse ou vos développeurs peuvent prendre beaucoup plus de temps pour itérer. Mais comment mesure-t-on cela ? Quel est le véritable coût de la dette technique ?

Une façon de mesurer cela consiste à examiner le nombre de jours que les développeurs devraient consacrer à la réduction de la dette technique en effectuant des activités telles que la refactorisation ou le remplacement de l'application. Une fois que vous avez associé un montant en dollars à ces fonctions, vous pouvez ensuite comparer ces données à d'autres jalons, comme le nombre de jours restants avant la date de sortie. Cela fournira une excellente analyse coûts/avantages et aidera à communiquer plus efficacement avec le reste de l'organisation.

En plus de fournir une mise à jour de l'état actuel, il est également important de générer des estimations de la façon dont vous vous attendez à ce que la dette technique évolue au fil du temps.

Communiquer la dette

L'une des étapes les plus importantes à franchir dans la gestion de la dette technique consiste à reconnaître son existence et à partager cette découverte avec les principales parties prenantes. Il devrait incomber à la direction informatique de donner le ton et de communiquer aux responsables non informatiques le véritable coût de la dette technique. Le responsable informatique doit également expliquer l'importance de rembourser la dette technique le plus tôt possible.

Rembourser la dette

Il y a trois options à considérer en termes de remboursement de la dette technique :

  • Renoncer complètement à l'exigence . En d'autres termes, l'organisation décide de vivre avec le système tel qu'il est et ne juge plus l'exigence nécessaire. (Si vous ne pouvez pas renoncer à l'exigence, vous êtes coincé avec deux autres options...)
  • Refactoriser l'application . Cette option vise à réduire la complexité, à supprimer les doublons et à améliorer la structure du code. Le refactoring est le seul moyen d'améliorer la structure interne d'un code sans modifier le comportement du programme.
  • Remplacez l'application . Même si cela introduira une nouvelle dette technique, l'idée est de s'y attaquer rapidement et de la minimiser autant que possible.
  • Minimiser la dette technique avec les pratiques Agiles. Les praticiens agiles savent que "fait" est un terme relatif. Dans les environnements de développement traditionnels, le logiciel est terminé lorsqu'il est livré aux utilisateurs. Mais dans les environnements Agile , des itérations de travail sont fréquemment livrées à l'utilisateur, améliorant les bogues et les problèmes qui se développent à chaque version. Il n'y a pas de "fait".

La méthoede Agile s'appuie sur la réduction de la portée d'une version pour garantir un travail de qualité, au lieu de promouvoir un grand nombre de fonctions dans une version.

Parce que la méthode Agile englobe les incréments et les itérations, au lieu de projets finis, la mise en œuvre des théories Agile peut être un bon moyen de rester au top de la dette technique. Toujours penser en courtes périodes de travail permet aux équipes informatiques de s'attaquer plus facilement à de plus petits groupes de dette technique : en continu. De cette façon, la dette n'est pas oubliée pour des projets et des phases plus grands et meilleurs, évitant ainsi les intérêts à long terme.

Pour alléger la dette technique, l'utilisation de méthodologies agiles telles que l'automatisation des tests et l' intégration continue (CI) peut garantir que votre équipe informatique travaille toujours sur la dette technique. Des sprints hebdomadaires permettront également aux équipes Agiles de nettoyer les données et les hypothèses obsolètes. En mettant en œuvre ces théories à long terme, beaucoup pensent que la dette technique peut être entièrement évitée.

GIFTED à Reims : Réduire la dette dans de nouvelles initiatives

La meilleure façon de réduire la dette technique dans les nouveaux projets est d'inclure la dette technique dans la conversation dès le début. Vous serez en mesure de tenir compte de l'impact des décisions à court terme sur le retour sur investissement à long terme et de créer un plan de remboursement de la dette au début d'un projet.

N'oubliez pas que, tout comme la dette financière, la dette technique devient plus chère à mesure que vous la détenez longtemps. En minimisant la dette technique, votre équipe peut réduire les risques, améliorer l'agilité et fournir les meilleurs résultats de sa catégorie. N'hésitez pas à contacter GIFTED, agence spécialisé dans le développement web pour vous accompagner dans la gestion de votre dette technique.

Découvrez nos derniers articles sur le sujet

Comment choisir une agence Jamstack en 2022 ?

Comment choisir une agence Jamstack en 2022 ?

Chercher la bonne agence Jamstack est beaucoup plus facile à dire qu'à faire. GIFTED est une agence Jamstack de premier plan et nous pouvons vous aider à atteindre vos objectifs.

En savoir plus
Qu'est-ce que l'accessibilité d'un site Web ?

Qu'est-ce que l'accessibilité d'un site Web ?

La plupart des gens pensent à l'accessibilité des sites Web en termes de la façon dont elle affecte les personnes handicapées.

En savoir plus
Dette technique : comment cela affecte votre business ?

Dette technique : comment cela affecte votre business ?

La dette technique peut avoir de rééls impacts sur votre business

En savoir plus
Pourquoi Wordpress headless est-il l'avenir de votre entreprise ?

Pourquoi Wordpress headless est-il l'avenir de votre entreprise ?

Le monde de l'entreprise devient chaque jour de plus en plus compétitif.

En savoir plus

Vous avez un projet de développement web ?
Vous souhaitez faire un audit technique et SEO ou tester la sécurité de votre SI ?

Recevoir les dernières nouvelles de GIFTED

Incrivez-vous pour recevoir une alerte lorsqu'un nouvel article sera disponible. No SPAM. Promis!