legacy

Legacy projects come with additional challenges for code quality. They underwent many changes (more or less significant) and are probably not maintained by the original authors. Due to a lack of anticipation at design time or complex maintenance, they often have accumulated substantial technical debt. You maintain such an application and want to control its debt? Here I propose four steps to get your technical debt under control.

1. Steady the debt

You may think it’s counter-intuitive, but first, it is essential to focus on current developments rather than fixing past issues. If you plan to reduce your technical debt, you should stop the leak and prevent the creation of new debt. In this first step, you should not consider existing violations and correct new ones immediately.

Linters are very good at giving a diagnosis of the current state, but they do not follow the evolution of the software. So you have to rely on tools like SonarQube, which can display changes since the last analysis or since the beginning of the current development period. Promyze offers a personalized and detailed follow-up to each developer and warns for any violation she made.

Based on this feedback, you can understand that your actions may introduce technical debt. It would be best if you thus took the necessary measures to reverse the debt curve. For example, you can identify commonly violated rules so you can pay more attention to them.

2. Fix priorities

Once you contained your debt, you can start to reduce it. You won’t be able to deal with everything at once, so you have to decide which violations to fix first. The criticality of the rules is an important factor, but it must be differentiated from the priority. The priority can also be set according to the complexity to fix an issue or its location.

Priority according to rules

The first way to set priorities is to consider each rule individually. You will prioritize some rules because they are more critical. It’s more important to fix a potential security flaw than a code formatting issue. You will prioritize other rules because they are easier to fix. Based on the previous example, code can be formatted by tools, thus correcting many violations very simply, while security flaws may require an in-depth rewriting of components.

The ideal is to find a balance so that you can progress quickly and get tangible results. By starting with too tricky problems, you can quickly become discouraged by the lack of change and difficulty, but minor fixes may not seem very useful.

Priority according to components

Another approach is to prioritize according to the location of violations, not the rules. You’ll feel more comfortable fixing issues in a component you know well (for example, because you recently made code editions in there). Also, completely removing violations from a file or a component allows one to observe positive progress and remain motivated.

It is, of course, possible to combine a priority by components and a priority by rules. Thus, you can eliminate code violations of a given rule component by component or inversely eliminate violations of a component rule by rule.

3. Create action plans

Even with the best will in the world, it can be difficult to make a trade-off between new developments and reducing technical debt. To keep in mind the actions to be accomplished, Promyze proposes to create action plans. Each plan corresponds to a development period (its duration is configurable) and can be assigned to a team or a developer; it contains a list of actions to be performed (for example, a fixed number of corrections to perform for a rule).

If you gave priority to some components, an action plan might only take into account actions performed on certain parts of the code. You can therefore customize the action plans according to the priorities set. This way, you can adapt the efforts dedicated to debt reduction at each development period and focus them on the parts that need it most.

4. Monitor KPIs

Finally, don’t forget to monitor KPIs (Key Performance Indicators), such as the number of bugs, violations, etc. It’s important to observe positive effects from your efforts and tracked the value provided throughout your ongoing developments. KPIs ensure your technical debt is reduced. You can also check the impact on current developments to avoid slowing them down.

KPIs will help you adjust action plans. If the debt is not decreasing fast enough, you can create plans that require more effort. If the effort to correct the debt is getting in the way of other tasks, it may be necessary to reduce the scope and create lighter action plans.

Summary

Controlling and reducing the technical debt of a legacy project is not an easy task, but it is possible to obtain results by proceeding iteratively. It is first important to stabilize the debt and then set priorities to move forward step by step. Action plans will allow you to implement these priorities, and KPIs will help you balance them.

Les projets legacy apportent des défis supplémentaires pour la qualité du code. Ils ont subi de nombreuses modifications (plus ou moins importantes) et ne sont probablement pas maintenus par les auteurs d’origine. Que ça soit par manque d’anticipation à la conception ou une maintenance difficile, ils ont souvent accumulé beaucoup de dette technique. Vous maintenez une telle application et souhaitez maîtriser sa dette ? Vous avez lu « les cinq étapes pour commencer à gérer sa qualité logicielle » mais vous avez eu l’impression de devoir nettoyer les écuries d’Augias ? Je vous propose ici quatre étapes pour reprendre votre dette technique en main.

 

1. Stabiliser la dette

Cela peut sembler un peu contre-intuitif, mais dans un premier temps il est important de se concentrer sur les développements actuels et non pas sur la correction de ceux du passé. Si on veut pouvoir réduire la dette, il faut d’abord la stabiliser en arrêtant d’en créer. Lors de cette première étape les violations existantes ne sont pas considérées, et il s’agit de ne pas en créer de nouvelles ou de les corriger immédiatement.

Les linters sont très bons à donner un diagnostic sur l’état actuel, mais ils ne suivent pas l’évolution du logiciel. Il faut donc s’appuyer sur des outils comme SonarQube ou Themis. SonarQube est capable d’afficher les changements depuis la dernière analyse ou depuis le début de la période de développement courante. Themis offre un suivi personnalisé et détaillé à chaque développeur et l’avertit des violations qu’il a fait.

En s’appuyant sur ces retours vous pouvez ainsi comprendre la dette qui est créée par vos actions et prendre les mesures nécessaires pour que la courbe de la dette s’inverse. Par exemple, vous pouvez identifier les règles couramment non respectées afin d’y accorder plus d’attention.

 

2. Fixer des priorités

Une fois la dette stabilisée, vous pouvez commencer à la faire diminuer. Vous ne pourrez pas tout traiter en même temps, il faut donc décider des violations qu’il faut corriger en priorité. La criticité des règles est un facteur important mais il faut bien la différencier de la priorité. La priorité peut aussi être fixée selon la difficulté de correction ou la localisation des violations.

Priorité par règles

La première façon de fixer des priorités est de considérer chaque règle individuellement. Certaines règles seront prioritaires parce qu’elles sont plus critiques. Il est plus important de corriger une potentielle faille de sécurité qu’un problème de formatage du code. D’autres seront prioritaires car elles sont plus simples à corriger. Pour reprendre l’exemple précédent, le code peut-être formaté par des outils, corrigeant ainsi un grand nombre de violations très simplement, tandis que les failles de sécurité peuvent demander une réécriture en profondeur de composants.

L’idéal est de trouver un équilibre, afin de pouvoir progresser rapidement et d’obtenir des résultats tangibles. En commençant par traiter des problèmes trop difficiles vous pouvez rapidement vous décourager devant le manque de changement et la difficulté, mais des corrections mineures pourront sembler peu utiles.

Priorité par composants

Une autre approche consiste à fixer les priorités selon la localisation des violations et non les règles. Un composant mieux connu (par exemple, parce qu’il a été édité récemment) sera plus facile à corriger. Aussi, supprimer complètement les violations d’un fichier ou d’un composant permet d’observer rapidement une progression positive et ainsi rester motivé.

Il est évidemment possible de composer une priorité par composants et une priorité par règles. Ainsi vous pourrez éliminer les violations d’une règle composant par composant, ou à l’inverse éliminer les violations d’un composant règle par règle.

 

3. Créer des plans d’action

Même avec la meilleure volonté du monde, il peut être difficile de faire un compromis entre nouveaux développements et réduction de la dette technique. Pour permettre à l’équipe de garder en tête les actions à accomplir, Themis propose de créer des plans d’action. Chaque plan correspond à une période de développement (dont la durée est configurable) et peut être affecté à une équipe ou un développeur individuel; il contient une liste d’actions à réaliser (par exemple, un certain nombre de corrections de violations à réaliser pour une règle).

Si vous avez donné la priorité à certains composants, un plan d’action peut ne prendre en compte que les actions réalisées sur certaines parties du code. Vous pouvez donc personnaliser les plans d’actions selon les priorités fixées. Ainsi à chaque période de développement vous pouvez adapter les efforts consacrés à la réduction de dette et les concentrer sur les parties qui en ont le plus besoin.

 

4. Surveiller les indicateurs

Enfin n’oubliez pas de surveiller les KPIs (Key Performance Indicators), comme le nombre de bugs, de violations, etc. Il est important que vous puissiez observer des effets positifs suite aux efforts consentis, et en fournissant des valeurs qui peuvent être suivies tout au long du développement, les KPIs permettent de s’assurer que la dette est bien réduite. Vous pourrez aussi vérifier l’impact sur les développements courants pour éviter de les ralentir.

Les KPIs vous aideront à ajuster les plans d’action. Si la dette ne recule pas assez vite, vous pouvez créer des plans demandant un effort plus important. Si les efforts de correction empêchent le bon déroulement des autres tâches il est peut-être nécessaire de réduire la voilure en créant des plans d’action plus légers.

 

Résumé

Maîtriser et réduire la dette technique d’un projet legacy n’est pas une tâche facile, mais en procédant de manière itérative il est possible d’obtenir des résultats. Il est d’abord important de stabiliser la dette, puis de fixer les priorités, afin d’avancer pas à pas. Les plans d’actions vous permettront de mettre en œuvre ces priorités, et les KPIs vous aideront à les équilibrer.

Leave a Comment

Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition

Features
©2022 Promyze – Legal notice