Cette année, je vais avoir l’opportunité d’aller assister à la conférence ConFoo. Il s’agit d’une des plus imposantes conférences liées au développement logiciel qui se donne dans la ville de Montréal. Au total, il s’agit de 155 présentations qui se donnent sur trois jours au total.
En plus du volume de présentations, c’est aussi les sujets qui sont variés. Elles passent de l’architecture logicielle, par le JavaScript et jusqu’à la gestion d’une équipe de développement.
Ce genre de conférences proposent beaucoup de petites présentations en condensé. Le but n’est pas d’aller chercher des connaissances approfondies, mais d’aller chercher certaines bases qui alimenteront des solutions pour des projets à venir.
Pour moi, il s’agit d’une occasion d’aller explorer de nouvelles façons de concevoir la technologie et ainsi pouvoir en faire bénéficier les solutions que je développe pour mes clients. Je compte bien profiter de chacun des moments que je vais passer là-bas pour apprendre quelque chose de nouveau.
Alors, comment vais-je occuper mon temps à ConFoo? Voici mon plan de match.
Il y a des plages horaires où les choix sont plus difficiles que d’autres. Dans ces choix j’ai tenté de conserver un équilibre entre aller chercher de nouvelles connaissances, mon avancement personnel et aller chercher un petit plus pour faire avancer certains projets au bureau. Après tout, pour le dernier point, c’est l’boss qui paie après tout!
J’ai bien hâte que ça commence! En fait, je me sens comme un enfant la veille de Noël. Après avoir révisé mes choix pour les sessions, je crois bien devoir me coucher tôt, car les journées vont être pas mal occupées!
Par pure curiosité: est-ce qu’il y a d’autres lecteurs qui y seront?
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.
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.
Vous avez tous déjà vu un extrait de code qui ressemble à celui-ci.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
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.
Cette année, je vais avoir l’opportunité d’aller assister à la conférence 
French Coding 