Architecture logicielle et sociale

Dernièrement je me suis rendu compte que je lisais d’excellents livres, mais que je ne partageais pas mes découvertes. Empressé de briser cette image d’égoïsme qui me hante, me voici qui en partage quelques uns avec vous!

Nous avons régulièrement des échanges au travail, parfois sérieux, parfois non. Il nous arrive aussi régulièrement d’avoir des échanges moins agréables, dans lesquelles nous sommes émotivement impliqués. Celles-ci finissent généralement mal, ou d’une manière neutre qui laisse tout de même un goût amer dans la relation. Il y a une solution! Mais avant tout il faut comprendre les éléments qui composent la situation, ainsi que ceux qui ont de la valeur dans une optique de résolution positive du conflit. Le livre Difficult Conversations: How to Discuss what Matters Most de Douglas Stone, Bruce Patton, Sheila Heen, Roger Fisher du Harvard Negociation Project est à la fois une méthode et un condensé de psychologie qui sera toujours utile lorsque le feu prend dans nos tripes et que la situation nous semble incontrôlable. Je dois dire qu’il est très difficile d’appliquer ces connaissances, mais elles sont sans contredit très efficaces.

Vous devez vous présenter chez un client? Travailler avec lui, quelque fois ravaler de sûres paroles, d’autres fois essayer de ne pas être biaisé lorsqu’en privé vous entendez des choses que vous ne devez pas? Être consultant est difficile, et souvent épuisant. Pourtant, c’est aussi un domaine qui fait un peu penser à celui du héros masqué; il arrive dans une ville en flamme, sauve les meubles et s’en va vers le soleil couchant, sans que personne ne l’aie remercié. Ce livre m’a beaucoup aidé à apprécier les tâches de consultation qui me sont assignées, et je le conseille sans hésiter: Secrets of Consulting, A Guide to Giving and Getting Advice Successfully, de Gerald M. Weinberg. Ses conseils, exprimés sous forme de lois et de faits, sont toujours pertinents, et amènent une réflexion bénéfique qui quelque fois dépasse le simple sujet de la consultation.

Le livre qui m’a fait passer de programmeur à architecte dans mon coeur est Patterns of Enterprise Application Architecture, de Martin Fowler. Ce livre aidera tout développeur à élargir sa vision du domaine en embrassant la complexité inhérente à l’homme, et la simplicité effarante du code lui-même. Le style d’écriture de Martin Fowler fait sa part pour faire de ce livre une ressource à ne pas manquer.

Je suis désolé pour vous qui ne connaissent pas encore la valeur des Design Patterns. D’un côté, je ne fais pas partie de ceux qui diront qu’on peut concevoir une application uniquement en imbriquant des Patterns, mais ces petits outils sont toujours utiles pour communiquer plus facilement des concepts complexes, pour servir de base à une idéation ou simplement pour éviter de réinventer la roue. Le défi est de voir les problèmes de conception se fondre avec les Patterns pour rendre leur utilisation pratique et naturelle, donc commencez tout de suite avec Design Patterns du Gang of Four (GOF), soit Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides.

Personne n’écrit de code sans quelques fois se retrouver avec une structure qui ne tient pas, ou avec des masses gluantes de code dont l’odeur vous fait fuir toute mise à jour. Certains proposent de réfléchir, concevoir et établir tous les éléments pour programmer du premier coup une oeuvre d’art, mais la nature de l’homme fait que ça n’arrive pas. Il nous faut donc une manière de refaire les fondations sans tout démolir, de peinturer les murs sans recouvrir les ampoules, poignées et oeuvres d’arts malencontreusement laissées là. Une technique existe, qui je dois le dire fonctionne exceptionnellement bien lorsque suivi scrupuleusement, qu’on retrouve dans Refactoring: Improving the Design of Existing Code de Martin Fowler. Quelques techniques toutes simples, mais définies dans tous les sens de manière à bien comprendre les implications et méthodes qui lui sont liées. Une fois que vous serez à l’aise avec le Refactoring, il sera temps pour vous de monter d’un niveau en lisant Refactoring to Patterns, de Josh Kerievsky. Suite à ces lectures, il n’y aura plus de code qui vous fera faire de cauchemars la nuit, et les maintenances se feront un café à la main, chantonnant. Ces techniques requierent une sécurité que, je dois l’avouer, je passe souvent outre, soit les tests unitaires. Plusieurs livres ont été publiés sur le sujet, mais je nommerai Test Driven Development: By Example de Kent Beck. Quelque fois ces stratégies de développement vont subtilement s’immiscer dans vos habitudes, le tout pour le mieux.

On parle de conception, mais comment peut-on échanger sur nos idées? Les Patterns sont une bonne base, mais on ne peut pas seulement aligner des termes et se comprendre, nous avons besoin d’images, et surtout, de bonhomme allumettes! Oserais-je nommer le terrible UML? Ceux qui ont osé chercher ses spécifications sur le site de l’OMG auront compris qu’il ne s’agit pas de simplement dessiner quelques carrés, quelques flèches et de crier victoire. Pourtant, plusieurs ont essayé de conserver la nature d’UML tout en expliquant les outils les plus communs pour permettre de se comprendre tout en utilisant les puissants outils existant, et parmi eux un grand vainqueur, UML Distilled: A Brief Guide to the Standard Object Modeling Language de Martin Fowler. Ce livre est un bijou à conserver près de soi en tout temps. Simple et plaisant à lire, c’est selon moi la référence en matière d’UML qui ne donne pas de maux de têtes.

Dans un autre ordre d’idées, j’aimerais citer un livre qui a charmé tous ceux qui l’ont lu, moi inclus. Lorsqu’on parle de gens, d’équipe, de locaux, bref toutes ces choses qu’on oublie souvent mais qui, pourtant, sont la fondation même de notre motivation et de notre capacité à produire, il est essentiel d’avoir pris connaissance de Peopleware: Productive Projects and Teams, de Tom DeMarco and Timothy Lister. Ce livre qui se lit comme du bonbon et qui se base sur des études des plus sérieuses vous marquera certainement, et je l’espère vous ouvrira les yeux sur l’importance de ce qu’on appelle: l’équipe.

Pour finir, j’aimerais conseiller une lecture à tous les développeurs C#: Pratique de .NET et C#: Comprendre et exploiter les atouts de l’architecture .NET, de Patrick Smacchia. C’est de loin le meilleur livre pour comprendre les concepts de base de .NET, le CLR, le threading et ainsi de suite. Je crois qu’il est primordial de connaître les fondements de ces outils qu’on utilise tous les jours, et démystifier certains comportements qu’on accuse parfois gratuitement d’être “mal faits”.

Finalement, voici un petit texte que j’ai trouvé très utile dans la clarification des requis: http://www.complianceautomation.com/papers/writingreqs.htm. Ça se lit facilement et peut-être que ça va faire des requis quelque chose de plus qu’une blague locale.

Si vous avez des recommendations, faites-moi en part! Quant à moi, je vais tenter de continuer à critiquer mes lectures. Prochainement: Getting to Yes: Negociating Agreement Without Giving In, de Roger Fisher et William Ury du Harvard Negociation Project!

Cette entrée a été publiée le Lundi, 2 octobre 2006 à 13:48 et est rangée sous Travail d'équipe, Livres, .NET/C#, Architecture Logicielle. Vous pouvez suivre les réponses sous cette entrée avec le flux RSS 2.0. Vous pouvez laisser une réponse, ou utiliser un rétrolien (trackback) à partir de votre site.