Archives de catégorie : Leadership

3 livres pour avoir les bases en .net

Quels
sont les livres que je peux lire pour avoir de bonnes bases en .net ?”

est en substance la question que se peuvent se poser ceux qui débutent en .net (et
que devraient se poser beaucoup de développeurs qui pensent avoir les bases :)). Il
se trouve qu’on vient de me la poser pour 686 ème fois, voici donc ma sélection de
3 ouvrages que je trouve important d’avoir lu pour être efficace.

Le
premier est la 3ème édition de CLR via C# écrit par Jeffrey Richter de Wintellect.
J’ai déjà lu les deux premières éditions et je suis en train de lire cette 3ème édition
(qui est sorti très récemment), et c’est de mon point de vue un des meilleurs ouvrages
sur les fondamentaux de la CLR et donc de la BCL.
Le
second ouvrage est orienté maitrise du langage C#. C# in depth de Jon Skeet est très
clairement l’ouvrage le plus pédagogique est le plus avancé que j’ai pu lire sur le
langage C#. Ce qui est plaisant avec cet ouvrage, c’est que l’ensemble des concepts
et notions sont abordés de manière intelligente sans passer sur les détails qui peuvent
paraitre compliqué au premier abord. Une vrai référence pour ceux qui s’intéresse
au langage C#.
Et
enfin, le petit dernier est le bien connu Framework Design Guidelines. Cet ouvrage
annoté par plusieurs acteurs importants dans le monde .net permet de comprendre comment
le framework .net a été conçu, et indique comment créer des frameworks qui respectent
les recommandations de Microsoft. Sa lecture peut très globalement être appliquée
à la création de tous type d’applications.

 

Et vous ? Quelles sont vos recommandations de lecture sur .net en général et sur
C# ?

<br />

Le principe de précaution

“Quelqu’un peut il m’expliquer pourquoi il arrive fréquemment, dans une équipe
projet, d’avoir une ou deux personnes qui ne peuvent écrire une classe sans écrire,
systématiquement, une ou plusieurs interfaces ou classes abstraites qui, en fin de
projet, ne sont finalement implémentées que par une classe voir pas du tout ?”

Voilà en substance un mail qui a lancé un débat intéressant entre collègues. Et je
dois dire que je suis d’accord avec ce constat et qu’il est vrai que j’ai parfois
l’impression que certains développeurs pensent que savoir développer proprement et
professionnellement signifie devoir implémenter 9879798 interfaces et classes abstraites
et ajouter 98770754 niveaux d’abstractions. Après tout, rajouter de l’abstraction
est le premier réflexe que l’on peut avoir lorsque l’on essaie d’atteindre l’objectif
premier de tout développeur qui se respecte :

Ecrire du code maintenable

Cet objectif est en effet primordial afin de réduire le coût de développement (et
de maintenance) d’un projet. Mais il mène parfois vers le travers évoqué ci-dessus.

Cette
mauvaise habitude appelée “le syndrome du “ocazou”” par David,
se rapproche beaucoup du principe de précaution dont on parle beaucoup en ce moment.
Adapté au développement logiciel celui-ci pourrait se traduire par :

“ l’absence de certitudes, compte tenu des connaissances techniques du moment,
ne doit pas retarder l’adoption de mesures effectives et proportionnées visant à prévenir
un risque de dommages graves et irréversibles au projet de développement à un coût
économiquement acceptable ”

Seul problème avec ce genre de principe de précaution, il est très souvent difficile
d’arriver à proportionner correctement son action afin d’éviter les problèmes par
la suite. L’actualité récente l’a montré, le principe de précaution incite souvent
à exagérer la menace, et a dans quasi tous les cas une certaine faculté à faire exploser
les coûts pour un résultat… souvent peu mesurable.

En réalité, la maintenabilité doit certes être basé sur du code propre et bien structuré,
mais il repose également sur deux principes fondamentaux :

  • Le principe KISS (Keep
    It Simple and Stupid)
    : Plus un code est simple et plus il sera facilement
    compréhensible et maintenable. Ajouter de la complexité en ajoutant des niveaux d’abstractions
    inutiles ne fait… qu’ajouter de la complexité.
  • Le principe
    YAGNI
    (You aren’t going to need it)
    : Ce principe indique qu’il
    ne faut pas ajouter des fonctionnalités ou du code tant que l’on n’en a pas réellement
    besoin.

Ces deux principes sont d’autant plus valables que nous avons à présent des outils
efficaces (comme ReSharper) permettant
de refactoriser intelligemment son code afin de faire évoluer son architecture quand
on a en besoin
. Inutile donc de rajouter de la complexité en prévision
du futur, il ne sera pas trop tard pour le faire par la suite…