Un refactoring ne se limite pas à supprimer un commentaire

Un des principes que j’applique le plus lorsque je développe est celui de la règle du boy scout. La règle du boy scout est basée sur le fondement suivant : toujours laisser un endroit dans un état meilleur que celui où vous l’avez trouvé.

En programmation, cette règle signifie exactement la même chose lorsque vous effectuez un changement dans une classe. Le synonyme de ceci se résume (presque) ainsi.

refactor-all-the-things

Le contexte à l’origine de ce billet est lié au développement sur la plus grosse application web que moi et mon équipe faisons évoluer. Il s’agit d’une application qui a du vécu. Elle existe depuis 2007, pour vous dire.

Sans révéler de détails confidentiels sur cette application, je m’amuse à dire que, si cette application n’existait pas, mon équipe n’y serait pas non plus. Il s’agit de notre pain et de notre beurre. Près de la moitié de nos itérations à trois développeurs y sont dédiées. C’est quand même beaucoup d’heures de développement.

Or, puisqu’il est question d’une application âgée, dit code base qui a du vécu. Sur une ligne du temps, il s’agit d’une application qui a connu la transition de la fin de .NET 2.0 à .NET 4.5. À la lecture du code, il est intéressant de constater cette évolution dans les façons de coder et par le style de programmation de chacun des individus qui ont contribué au projet avec le temps.

Cependant, au-delà de la curiosité anthropologique, du code âgé signifie aussi qu’il y a du ménage à faire. En particulier aux endroits qui n’ont pas vu beaucoup d’évolution ces derniers temps. Une des pratiques que je tente d’endiguer dès que j’en ai l’occasion est ce que je nomme la surcommentarisation du code.

Je nomme cela aussi l’effet //this is bridge

Vous avez tous déjà vu un extrait de code qui ressemble à celui-ci.

Je suis assez contre l’utilisation des commentaires dans du code. Je me dis qu’il s’agit de la pire documentation qui peut exister. Bien souvent, les commentaires ne font qu’ajouter du bruit inutile à du code qui aurait besoin d’être simplifié.

Parfois, un commentaire peut aider à expliquer un contexte derrière la mise en place d’une solution. À cela, je réponds que je préfère avoir un code plus explicite, mais qui décrit exactement qu’il fait. Par exemple, un commentaire peut être remplacé par une méthode avec un nom significatif qui englobe une ou deux lignes de code. C’est plus long, mais plus clair.

L’avantage est qu’une méthode avec une si petite portée est significativement plus facile à nommer. De plus, ces méthodes ont tendance à faire une seule chose et la comme il faut.

Même si je suis contre l’utilisation des commentaires, même s’il est rare, je concède qu’il peut toujours y avoir un bon contexte pour un commentaire. Tout est une question de modération. Cela est sans rappeler l’histoire du garçon qui criait au loup. À force d’inclure trop souvent des commentaires, on finit par perdre de vue l’essentiel avec le concept d’origine. C’est à dire mieux communiquer ses intentions et faire en sorte que les bogues se tiennent loin du troupeau.

Les liens de la semaine – Édition #170

Développement

.NET

Technologie

Web

 

Je me pose la questions à toutes les fois. Quelle structure opter pour ses vues et contrôleurs avec ASP.NET MVC?

Ce billet a été initialement créé avec l’intention de faire une démonstration sur les façons possibles d’organiser les vues ainsi que les contrôleurs avec ASP.NET MVC. J’avais parti un brouillon avec quelques points comme je fais à l’habitude. Je l’ai laissé mijoter quelques semaines.

Il s’avère que l’inspiration que j’avais initialement pour ce texte s’est évaporée. Pfiou! Il n’y en a plus. Cependant, j’ai tout de même l’intention de produire un texte à ce sujet.

Suite à un brainstorm avec mon équipe lors du démarrage d’un projet, nous avons abordé la question de la façon de structurer les contrôleurs ainsi que les vues du projet. Spécifiquement, il était de déterminer de quelle façon nous allions procéder. À savoir si, d’une part, nous allions de l’avant avec l’un concepts suivants:

  • où nous aurions de grosses actions de contrôleur qui ont la responsabilité de tout récupérer et qui envoient les données à des vues pour le rendu
  • des actions de contrôleur qui servent à réserver des URL dont les vues sont composées de plus petites actions de contrôleur séparées sur plusieurs vues partielles autonomes

Pour faire simple, j’ai résumé cela à déterminer si nous voulons utiliser @Html.Partial ou @Html.RenderAction dans nos vues. C’est un peu simplet, mais, sommairement, il est possible de le résumer ainsi.

Froidement, sans contexte, la décision relève d’une question de préférence. Personnellement, dans le passé, j’ai opéré dans les deux contextes. Il y a des pour et des contre dans chacun. Cela en revient au contexte dans lequel l’application est développée.

Dans notre situation, il s’agit d’une application avec un nombre fixe de pages. Chacune avec des fonctions bien précise. Les composants communs sont clairement identifiés et appelés à partir du Layout de l’application. À titre d’exemple, dans ces composants, il y a notamment le menu principal, l’entête, le pied de page.

Pour notre part, nous avons opté pour le modèle des grosses actions de contrôleur. Le principal avantage de cela est qu’il est plus facile d’extraire les éléments de logique d’affaire dans les couches de service et de laisser uniquement la tâche à ces contrôleurs l’unique responsabilité d’assembler les différents morceaux pour alimenter leurs modèles respectifs.

L’autre argument pour cette façon de faire est qu’elle instaure une distance entre la logique d’accès et de préparation des données et de l’affichage de celles-ci. Une vue partielle reçoit des données et génère un affichage en fonction de celles-ci. C’est son unique responsabilité. De cette façon, il n’y a pas besoin de se soucier d’où proviennent ses données.

Le principal défi, dans les deux scénarios, est de garder le contrôle sur la dette technique que peut générer un mauvais classement des différentes fonctionnalités de son application. Je surnomme cela l’effet « dossier Shared« . À un moment donné, il y a toujours un dossier de type fourre-tout dans lequel on finit toujours par y déposer certains éléments dont on ne sait pas quoi en faire.

Les liens de la semaine – Édition #169

Développement

.NET

Technologie

Web

Science et autres

Les liens de la semaine – Édition #168

Développement

.NET

Technologie

Web

Science et autres

Pensée du jour

Suivre

Recevez les nouvelles publications par courriel.

Joignez-vous à 397 autres abonnés