A l'occasion de son livre "Practical Object-Oriented Design in Ruby: An Agile Primer" (POODR), InfoQ a interviewé Sandi Metz.
Publié l'an dernier, le livre a été reçu chaleureusement par la communauté Ruby et les non-rubyistes grâce à son approche pragmatique qui explique des pratiques souvent considérées comme trop compliquées lorsqu'elles sont présentées (ou imposées) sans un contexte clair, ni motivations.
Bien que Ruby soit le langage utilisé pour les exemples, le livre pourrait facilement être placé dans la catégorie générique "conception de logiciels" puisque l'auteur adopte une approche impartiale en comparant les langages dynamique et statique.
Les développeurs expérimentés peuvent aussi trouver dans ce livre beaucoup de problématiques qu'ils ont sûrement rencontrées au cours de leur carrière. Les développeurs débutants trouveront des explications et des exemples de pratiques de conception clairs et pertinents, et prendront conscience des avantages et des inconvénients de l'application de certaines pratiques dans certains contextes.
Surtout, le livre souligne la nécessité d'évaluer en permanence si la conception est suffisamment adaptée aux connaissances actuelles de l'application (les besoins) tout en minimisant le coût des changements futurs. Selon les termes de Sandi :
"Un code qui est Transparent, Raisonnable, Utile et Exemplaire (TRUE) ne répond pas seulement aux besoins d'aujourd'hui, mais peut aussi être modifié pour répondre aux besoins futurs."
InfoQ a discuté avec Sandi de la façon dont son livre a été reçu, l'apprentissage à partir d'un code open source, de l'usage raisonné des outils d'analyse de code et d'autres sujets.
InfoQ : Quel est le public visé par ce livre ? Pensez-vous que les développeurs débutants et expérimentés peuvent chacun profiter de ce livre ?
Sandi : Le public initialement visé était moi en plus jeune, moins expérimenté, à un moment où cela faisait deux ans que j'écrivais du code orienté objet. Cette personne aurait probablement pu être décrite comme "intermédiaire". En écrivant, je croyais que les lecteurs ayant moins d'expérience ne seraient pas encore en mesure d'apprécier le livre et que les lecteurs plus expérimentés ne seraient pas intéressés.
Cependant, maintenant que POODR est paru et que les lecteurs se sont ont fait leur opinion, il est apparu que je me trompais. Beaucoup de débutants me disent qu'ils l'ont trouvé utile comme de nombreux programmeurs expérimentés disent qu'ils l'ont apprécié. L'éventail de lecteurs est beaucoup plus large que prévu.
L'autre grande surprise est le nombre de non-rubyistes lisant POODR. Le livre est sur la POO et contient très peu de choses spécifiques à Ruby alors peut-être cela ne devrait pas être surprenant, mais je n'imaginais pas ce public et c'est très agréable qu'ils le trouvent utile.
InfoQ : Votre livre parle beaucoup de code exemplaire et de l'idée que du bon/mauvais code encourage l'écriture de code similaire. Dans le recrutement, il semble y avoir beaucoup d'importance apportée aux compétences d'un développeur, mais dans quelle mesure est-ce que la capacité individuelle est éclipsée par l'influence des mauvais exemples au sein de l'entreprise ?
Sandi: Mon expérience est que les applications réelles en entreprises contiennent des tonnes de code imparfait, c'est habituel dans la pratique. Par définition, les débutants ne sont pas en mesure de corriger (ou même juger) de mauvais exemples et sont donc, malheureusement pour eux, toujours forcés de demander de l'aide à des développeurs plus expérimentés.
Les développeurs expérimentés sont formés "sur le tas", nous apprenons ce métier en le faisant. Nous comptons sur nos collègues pour nous apprendre les bonnes pratiques et nous améliorer, et il est du devoir du senior d'enseigner au junior.
La réalité du monde open source est que chaque développeur a accès à beaucoup plus de code que seulement celui de son entreprise, et est en contact avec de nombreux développeurs aguerris hors de son cercle de collègues. On ne demande pas aux débutants d'être nés en sachant comment écrire (ou même reconnaître) du code exemplaire, mais ils doivent accepter de s'exposer au monde et à ses nombreuses influences.
InfoQ : Comment les développeurs débutants peuvent-ils apprendre à concevoir dans la pratique sans compromettre le code existant ? Dans le livre, vous évoquez le danger d'adhérer à des modèles sans avoir une idée claire des compromis liés à cette décision. Quels sont les autres obstacles que doivent éviter les développeurs débutants qui souhaitent maîtriser la conception orientée objet ?
Sandi : Les débutants doivent écrire beaucoup de code et le montrer à qui veut bien le regarder, et aussi regarder le code écrit par d'autres. Github est l'ami de tout le monde et rien ne remplace le temps.
InfoQ : Les outils d'analyse de code : paradis ou enfer ?
Sandi : Le paradis pour ceux qui ont un bon jugement, autrement, l'enfer (ou du moins quelque chose qui y ressemble). Les outils sont très bien pour les opérations fastidieuses consistant à parcourir le code et compter diverses choses, mais c'est au développeur de savoir quoi faire des résultats.
Pour un outil d'analyse de code, une bonne conception d'une mauvaise chose aura un bon score, alors qu'une mauvaise conception de quelque chose qui ne changera jamais aura un score médiocre. L'outil vous complimentera sur le premier et se plaindra au sujet du second, mais dans ce cas, faire ce qu'il indique est un gaspillage d'argent.
La force de résister à l'envie d'écrire du code qui sur-anticipe l'avenir et le courage de laisser du mauvais code qui ne changera jamais, sont des qualités humaines, et non des outils statiques.
InfoQ : En particulier, comment voyez-vous le rôle de ces outils en termes de définition des règles de dépendance et des violations ? Peuvent-ils aider à l'élaboration d'une meilleure conception ou les bonnes pratiques de conception sont-elles trop dépendantes du contexte pour tirer profit de règles drastiques ?
Sandi : J'aime les outils d'analyse et les données qu'ils fournissent. Ils me permettent de rester dans le droit chemin, ils soulignent les problèmes que je néglige et les erreurs que je fais. Je crois qu'aucun développeur ne devrait programmer sans ce genre d'informations ; ils doivent simplement prendre les résultats avec beaucoup de précautions.
InfoQ : De votre expérience, quelles sont les erreurs de conception les plus courantes dans les applications existantes ? Comment recommanderiez-vous de corriger du code posant problème, par où commencer ?
Sandi : Le plus gros problème que je vois personnellement concerne des objets et des méthodes qui ont trop de responsabilités. C'est tellement commun que mon premier conseil à toute personne ayant un problème est de « faire de plus petites choses ».
InfoQ : Avez-vous des recommandations supplémentaires pour les lecteurs intéressés par la conception pratique OO ?
Sandi : Lisez le livre GOOS (Growing Object-Oriented Software Guided by Tests).
InfoQ : Comment le livre a-t-il été reçu par la communauté Ruby ? Avez-vous senti qu'il y avait une lacune dans la littérature au sujet de la conception de logiciels pour les langages dynamiques et Ruby en particulier ?
Sandi : J'ai été étonnée par l'accueil positif de la communauté Ruby. Alors que les rubyistes formés à l'université semblent l'apprécier, la réaction de loin la plus enthousiaste est venue de développeurs Ruby autodidactes. Tous les jours des personnes me disent avoir longtemps attendu ce type d'informations. La modestie m'empêche de répéter trop de compliments, mais un lecteur heureux a tweeté qu'il avait trouvé son chemin de Damas (ndlt : en lisant le livre sa vision de la programmation avait changé radicalement).
POODR ne contient que très peu d'idées révolutionnaires. En fait, il y a un certain nombre d'idées que j'ai d'abord pensé avoir inventées, mais en réalité je les ai "redécouvertes".
Je ne savais pas que ces idées existaient parce que je ne parvenais pas à lire et à comprendre la littérature existante. Il y a donc une lacune dans la littérature, mais il ne s'agit pas de contenu, il s'agit de lisibilité. La réaction enthousiaste à POODR est une indication de la façon dont les développeurs souhaitent que cette lacune soit comblée.
InfoQ : Pouvez-vous partager avec InfoQ vos prochains projets (livres, open source, autres) ?
Sandi : je suis en train de faire une série de vidéos pour POODR et d'envisager la possibilité d'enseigner. Je profite des opportunités qui s'offrent à moi après avoir écrit un livre, le seul bémol, c'est que maintenant je dois planifier du temps pour écrire du code.
A propos de la personne interrogée
Sandi Metz a 30 ans d'expérience sur des projets qui ont survécu aux évolutions et aux changements. Elle code tous les jours en tant qu'architecte logiciel à l'Université Duke, où son équipe résout des problèmes réels pour des clients qui ont de grosses applications orientées objet qui évoluent depuis plus de 15 ans. Elle est engagée dans la promotion de logiciels utiles, les présentant d'une manière extrêmement pratique. POODR est la distillation de plusieurs années de dessins sur un tableau blanc et l'aboutissement logique d'une vie de conversations au sujet de la conception orientée objet. Sandy est intervenue à plusieurs reprises lors de la conférence de Gotham Ruby User et vit à Durham, Caroline du Nord.