Gérer votre dette technique – Jessica Torres

Si vous avez déjà travaillé sur un projet professionnel ou même simplement sur une mission, en écrivant du code, vous avez presque certainement entendu un adage similaire à « Get it working ». En tant que programmeurs, nous sommes encouragés, le plus souvent, à nous soucier des tests réussis ou des fonctionnalités de base en premier, et de l’optimisation de notre code en second. L’un des problèmes majeurs avec cela est que les projets et les missions ne cessent de venir et il devient très rapidement impossible de revenir en arrière. Vous finissez par laisser derrière vous cette traînée de reconnaissances de dette techniques, des promesses de code plus propre et plus efficace, des cas de bord que vous avez notés mais également pris la décision de vous en occuper plus tard, des changements que vous pourriez avoir l’intention de faire dans un proche avenir futur mais ne le sera probablement jamais. Cela laisse un gâchis pour l’une des deux personnes, futur vous ou futur programmeur «autre gars» (aucun d’eux n’appréciera la charge de travail supplémentaire).

Ces conséquences des «solutions limitées», les coûts implicites de tout remaniement supplémentaire qui doit être achevé, sont ce que nous appelons la dette technique. Pour être clair, la dette technique n’est pas toujours le résultat d’une décision prise dans le moment par un programmeur, et nous verrons plus en détail les autres situations qui entraînent une dette plus loin dans ce billet. Mais en vérité, la plupart du temps que vous passerez en tant que développeur sera simplement consacré à prendre en charge une certaine forme de ces dettes techniques, et en tant que tel, il est dans l’intérêt de tous d’essayer de minimiser ces dettes dès le début.