Une vie de dev sans formalisme
Je pratique la programmation objet depuis 88 en commençant avec ADA, programmation par objet pour les puristes.
À cette époque, la PME dans laquelle je travaillais, collaborait avec des sociétés de services bien connues, nos rencontres avec les développeurs étaient assez édifiantes, ils nous montraient les gros classeurs de conception formelle, à l'époque ce devait être Merise, et il semblait qu'ils ne les utilisaient pas réellement car entre temps tellement de choses avaient changé que cela était devenu inutile, et les délais ne permettaient plus de les actualiser.
Une expérience plus récente m'a pas mal éclairé aussi. Reprenant la direction d'un projet de 5 ans dans une toute petite entreprise, j'étais très surpris de la quantité de documents écrits par les équipes au démarrage. Au départ très content, j'ai vite déchanté lorsque je me suis aperçu que le décalage avec le code réel était en fait énorme, normal au départ, l'argent d'un capital-risqueur coulait à flot ;)
Une expérience encore plus récente. La startup dans laquelle je débutais avait fait appel à une entreprise de service pour amorcer la partie en Java du projet. Ils ont commencé par faire de l’UML, des graphes de séquence, qu’en est-il resté ? Rien, nous étions dans une approche trop informelle avec des itérations trop nombreuses, essais, échec, tout effacé, recommencer… Ce type de formalisme n’a sans doute pas tenu le coup face aux contraintes de la vie réelle et la personnalité du CTO ?
En 16 ans, je n'ai jamais utilisé de manière formelle d'outils de conception et de formalisation, hormis la lecture de Grady Booch sur Ada et les Packages fin des années 80.
Je dois ma formation objet essentiellement à la pratique de NeXTStep/OpenStep/Interviews et donc l'apprentissage des Design Pattern par osmose... Comme me Jourdain je faisais.... ;)
La lecture du code des autres, de quelques bouquins, est la voie la plus utilisée non ?
Nous avons tenté plus d'une fois de faire acquérir des outils spécialisés, mais beaucoup trop cher pour l'employeur, nous utilisions en général les outils GNU, pas très chers il est vrai ;)
Cela nous a t-il empêché de produire des applis de qualité? Non assurément, et les négociations avec les clients se situaient sur un autre niveau, et quelques slides suffisaient amplement.
De mon côté, plutôt académique, j'ai toujours noirci mes cahiers de mes schémas et réflexions, beaucoup de commentaires dans le code afin de retrouver mes petits, mais c'est vrai, c'est surtout bon pour soi même. Pour les autres il est essentiel d'avoir un document 'Concept', mais a t-on le temps? en général non, et ça n'intéresse personne à par soi même pour y voir plus clair...
Il y a une vraie culture de la bidouille, du hack, du patch, malheureusement...
Me trouvant au chômage actuellement, je m'aperçois que les annonces sont remplies d'UML, de Rationale et consort, alors je m'y mets pour avoir le vocabulaire et les bases afin de ne pas paraître ridicule.
Et il est vrai que la perspective de me mettre à mon compte fait que je l'envisage sérieusement. Il m'apparaît clairement que c'est un outil de communication indispensable. Mais ma vocation pour la simplicité me fait croire aussi qu'il est bon de l'utiliser pour les schémas généraux afin qu'ils puissent être réellement compris par le client, et par soi-même par la même occasion. Le code n'en sera que plus simple, et ce n'est pas un mal, vu la tendance à la complexité de certains codeur pur et dur, plus c'est tordu mieux c'est :?
Certains schémas font très peur quand même ;)
2 exemples concernant l'uml pour un projet
via dflp
http://www.nevrax.org/docs/
le premier http://www.nevrax.org/docs/img/nelnet_uml.png
le 2nd http://www.nevrax.org/docs/img/nelnet_uml2.png
UML : escroquerie intellectuelle ?
Tout à fait d'accord. Enfin quelqu'un qui brise le tabou. Le problème fondamental d'UML est qu'il n'est pas précisé exactement de quoi il s'agit : tantôt simple norme graphique, tantôt cadre de modélisation, voire même outil de conception, ce qui est une chose tout à fait différente. Si on le conçoit comme simple norme graphique, on peut effectivement l'utiliser; le problème est qu'on essaye à partir d'UML d'orienter la modélisation, ce qui est une aberration car UML est totalement déficient de ce point de vu. Un problème fondamental est l'absence de modélisation fonctionnelle globale du projet, qui doit être le préalable. Baser la réflexion sur le projet à partir des cas d'utilisation (les fameux use case) est totalement idiot, car c'est le projet lui-même qui va définir le mode d'utilisation, et pas l'inverse ! Il faut bien distinguer ce qui est interface de ce qui est fonctionnalité, la première dépendant de la seconde. Un autre problème d'une modélisation UML est la confusion entre modèle de donnée, fonctionnalité du projet et organigramme : si on prétend montrer les interactions fines entre classes, on va rapidement se trouver face à une usine à gaz ingérable.
Si vous ne trouvez pas d'exemple de modélisation intégralement UML appliquée à un cas réel et qui aille au-delà du retrait au guichet bancaire, c'est peut-être parce qu'il n'y en a pas !
UML est enfin le reflet des insuffisances du modèle objet lui-même, qui s'applique en réalité trés mal à la plupart des projets informatiques. Le modèle objet suppose de nombreux exemplaires (instances) d'un même type d'entités possédant leurs propres données et méthodes; or dans les projets on agit généralement séquentiellement sur une même donnée que l'on va modifier en fonction des besoins, ce qui fait qu'on n'utilise presque toujours une seule instance de chaque classe (à l'exception d'objets techniques comme des tables). La "programmation objet" se réduit souvent à utiliser des objets comme on utilisait les modules et les sous-programmes dans les langages traditionnels. Il y a malheureusement une "dictature de la mode" en informatique, où tout le monde fait semblant de trouver trés bien quelque chose de peur de paraître passéiste. Moultes vessies se croient lanternes....