J’ai souvent abordé le sujet de la qualité du code sur ce blogue. C’est un sujet qui me passionne énormément. Je crois sincèrement que la qualité du code est intimement liée à l’importance accordée à la pratique de la programmation.
À mon avis, le souci de la qualité du code n’est pas nécessairement de connaître en détail les implémentations des design patterns du Gang of Four. Il s’agit d’avoir le souci du détail et, c’est étrange de dire ceci, de faire preuve d’amour envers ce que l’on code.
Cette semaine dans les liens de la semaine, j’ai lié le billet Relax. Everyone’s Code Rots. Lorsque l’on produit quelque chose, il faut s’attendre qu’après quelque temps, la solution ne soit plus au goût du jour. C’est normal, en fait.
Cependant, une solution développée avec le souci de la qualité a souvent une qualité qu’il n’y a pas ailleurs. Il s’avère que la maintenabilité de celle-ci est significativement plus simple. C’est souvent très facile d’identifier les composants et ce qu’il doit être fait pour modifier des fonctionnalités.
Il y a un pattern que j’ai vu régulièrement revenir dans des applications que j’ai eu à maintenir dans les dernières années. Il s’agit de celui où une méthode va détenir une quantité phénoménale de paramètres à recevoir, car elle est responsable d’aboutir le résultat d’un grand nombre de traitements qui ont été préalablement exécutés.
Le problème avec cette façon de faire est à plusieurs facettes:
- Cette méthode est invoquée dans le cadre d’exécution Top-Down (ascendante). Habituellement, la méthode dans le bas est impossible d’être dissociée de la pile d’exécution
- Il est strictement impossible de mémoriser l’entièreté des paramètres qui sont gérés par cette méthode
- Lorsqu’on modifie la signature de la méthode, un problème comme celui affiché à droite est créé. 26 erreurs pour une méthode qui accepte 20 paramètres.
- Par le nombre de paramètres qu’elle accepte, cette fonction fait, conséquemment, un très grand nombre de choses en même temps.
Habituellement, la maintenance de ce genre de contexte est très difficile, car, à tous les endroits où cette méthode est appelée, le contexte n’est généralement pas le même. Vous avez donc affaire à « ce code » auquel personne ne veut réellement toucher.
Il est difficile de régler un cas comme celui-là rapidement. Il n’y a pas de remède facile. La stratégie à adopter dans un cas comme celui-là est en deux volets.
- Diviser la fonction principale (CreateRow) en plus petites méthodes. Cela aura pour effet de donner un peu plus de visibilité sur l’interaction de la méthode avec ses paramètres. Peut-être qu’il sera plus facile d’identifier certains paramètres à extraire ou à retirer pour les déplacer dans l’appel d’une autre méthode.
- Procéder à la création d’une classe qui sera utilisée pour regrouper les paramètres de la méthode. Au lieu d’envoyer 20 paramètres, un seul en sera utilisé. De plus, cela aidera à la classification de ceux-ci.
Cela serait une première étape dans le chemin pour faire de ce bout de code quelque chose d’un peu plus agréable à maintenir. L’autre facteur important à tenir compte dans cette opération est le facteur coût/bénéfice de ce refactoring important.
En fait, c’est toujours se demander quelle est la valeur du code en question. Un bout de code qui ne sera pas appelé à être changé ne vaut généralement pas la chandelle en terme d’efforts de développement.
French Coding 