[Architecture] Documentation scolaire et bibliographie

Bonjour,

venant de passer il y a peu une certification OCPJP, je m'intéresse aujourd'hui à l'OCMJD (Java Developer).

Vu que je fais tout ça en autodidacte fauché, j'ai préféré éviter les cours Oracle hors de prix et ai suivi les conseils glanés ici ou là sur le net : je me suis procuré le livre SCJD Exam with J2SE 5 de Monkhouse et Camerlengo.
L'ouvrage est très intéressant, tient effectivement ses promesses et prépare correctement au SCJD autour de J2SE 5... sauf que moi je vise l'OCMJD à l'ère de Java 8 !

Outre la différence de JDK entre l'exam de Sun traité dans le livre et l'exam d'Oracle que je vise, j'ai l'impression que ce livre présente une méthodologie un peu désuète et obsolète - bien que suffisante pour l'examen - , dite "en cascade".
Loin de moi l'idée de dénigrer cette méthode ! J'ai seulement cherché à m'informer des autres méthodes susceptibles de pouvoir me servir dans un hypothétique avenir d'architecte logiciel... et là ... c'est le drame.

J'ai beau user mon clavier en harcelant Google, je ne trouve aucun site, aucun ouvrage, aucun document enseignant clairement et pédagogiquement une méthodologie complète pour la conception ! Ô désespoir ! :)

Je suis bien entendu tombé sur des classiques traitant des Design Patterns ("Big Four" et Head First, entre autres), sur des moins classiques abordant l'organisation de projet avec SCRUM et XP, sur des PowerPoints égarés traitant de truc conceptuels comme MVC, MVVM, et autres sigles...
Tous ces "outils", ces "patterns", toutes ces "méthodes", son intéressants individuellement mais beaucoup se contredisent ou se combinent très mal, d'après ce que j'en ai compris.

En bref, j'ai l'impression d'être dans un milieu où règne un jargon confus, où tout le monde parle en sigles et en concepts flous qui changent de définition avec le temps et le contexte, et où tout le monde avance un peu à l'aveugle en apprenant sur le tas.

Voici donc enfin ma question :

* Existe-t-il quelque part, dans la bibliothèque perdue d'une université abandonnée ou dans le coffre fort de Bill Gates, un livre ou un fascicule s'intitulant sobrement "L'architecture logicielle" et détaillant pas à pas et sans langage d'avocat une méthodologie universelle permettant de faire passer un logiciel de l'état de "vision" à l'état de "déploiement" de manière à ce qu'il soit le plus robuste, stable, flexible et fonctionnel possible ?

De mes recherches, j'ai retenu les méthodes agiles - et notamment SCRUM - qui proposent un déroulement temporel précis et clair du cycle de vie d'un projet. Mais SCRUM laisse l'équipe libre de définir l'architecture sprint après sprint, release après release... OK, mais ça me dit pas comment !
J'ai retenu aussi, bien sûr, les célèbres Design Patterns bien utiles (même si j'avoue ne pas savoir quand ni comment m'en servir). J'ai bien compris qu'il s'agissait "d'identités remarquables" de la programmation : elle permettent de simplifier l'entité (a + b)² en l'entité a² + 2ab + b², en quelque sorte, mais comment je sais que pour faire ce qu'il a à faire, mon logiciel doit contenir cette entité ?!?
J'ai vu passer aussi un bon gros zilliard de sous-disciplines de l'architecture logicielle ("Business Architecture", "Information Architecture", etc.). Pas de quoi définir l'architecture comme unité...

Je suis peut-être trop attaché au formalisme et peut-être qu'une telle méthodologie n'a pas lieu d'être dans cette discipline, mais j'avoue être surpris de ne pas avoir pu trouver facilement de telle documentation.

Merci d'avance pour les efforts que vous ferez pour reformuler ma conception peut-être erronée de l'architecture logicielle et me mettre sur la voie des œuvres qui permettent de faire de moi un tueur en la matière :p.

Cordialement.

Le développement d'applications est un domaine professionnel très jeune, normal (et tant mieux quelque part !) qu'une multitude d'approches fourmillent, se recoupent, se plagient, s'opposent... :)

Sur l'architecture plus précisément, je pense que c'est une discipline qui a beaucoup de mal à exister à part entière car elle subit une énorme influence de ses champs voisins très anciens et chacun très "opinionated" :

• Les langages de programmation et leurs paradigmes (OO, fonctionnel, etc.)

• Les OS et plateformes, propriétaires ou Open Source

• Les approches de gestion de projet (agile, cycle en V...)

• Les modèles de gestion de la concurrence (threads, programmation parallèle, asynchrone, actor model...)

• Un standard de délivrance de contenu quasi monopolistique (le Web !)

Tous ces sujets devraient être subordonnés à l'architecture, or dans la pratique il s'avère que les chers créateurs de ces outils/process/approches ont souvent déjà réfléchi pour nous et exercent une force d'attraction vers un type d'architecture particulier qu'on est plus ou moins obligé d'adopter selon ce qu'on choisit...

De plus, il n'y a pas de bonne architecture qui ne tienne compte de son domaine d'application et du contexte métier, donc je ne pense pas qu'un livre puisse sérieusement se revendiquer comme Bible de l'architecture en livrant une recette magique universelle applicable tout le temps.

Je recommande quand même quelques livres qui tentent de décrire une démarche "big picture" de conception de logiciels :

- Growing Object-Oriented Software, Guided By Tests et son approche outside-in où on commence par les couches externes de l'application avec des bouchons qu'on fait sauter au fur et à mesure qu'on se rapproche du centre.

- Patterns of Enterprise Application Architecture de Fowler, plus un recueil de bonnes pratiques où aller piocher selon le contexte.

- Domain Driven Design qui va bien au-delà de l'architecture et touche aussi aux rapports avec les experts métier, à la définition d'un langage commun technique/fonctionnel, au design orienté objet, à l'intégration avec des systèmes externes, etc. (attention, ouvrage très touffu)

Merci beaucoup pour ta réponse ! Je vais jeter un œil à ces références.

Je conçois bien qu'il s'agisse d'une discipline jeune et que différentes approches soient envisageables selon les contextes et technologies de l'environnement. Seulement, avec un bête esprit formaliste, je me figurais que de ce fourmillement de propositions éprouvées empiriquement, quelqu'un avait réussi à en extraire un processus commun plus théorique et plus global.

M'enfin après tout, toutes les disciplines, même les plus formalisées comme les mathématiques, doivent souffrir au moins provisoirement de ce genre de "confusion" empirique dans leurs domaines de pointe... c'est ce qui fait que cette discipline progresse.
L'architecture logicielle n'a donc pas encore de cadre théorique unifié. J'espère que cela viendra :)

Je n'apprends pour le moment que par les livres et de petits projets personnels, c'est ce qui fait sans doute que je m'attache autant au formalisme. Lorsqu'une boîte me laissera ma chance, je finirai pas me fier à mon expérience, certainement.

Pour le moment, j'avoue être plutôt intéressé par la méthode SCRUM, pour sa façon de décomposer l'application en stories. L'ennui - j'y reviens encore - c'est que SCRUM ne propose aucune technique pour organiser le code qui en résulte. C'est le code qui fait l'architecture petit à petit, en se révisant si nécessaire. Mais ça ne me dit ni comment effectivement réviser le code, ni pourquoi (dans beaucoup d'ouvrage sur le sujet) un "Software Architect" est quand même appelé à participer aux réunions précédent un sprint et un autre à accompagner l'équipe au cours du développement même.
En somme : "Ne préparez rien à l'avance, mais prévoyez un minimum quand même !". Et quid des modules/packages/flows ? on les construits petit à petit aussi ? C'est confus...
Je crains - sans en avoir fait l'expérience - que SCRUM amène, au fur et à mesure qu'un logiciel grossit, à un merdier architectural qui demandera une "maintenance" continue pour s'adapter au jour le jour aux nouvelles stories.

UML incite, lui, à tout schématiser avec une pléthore de diagrammes spécialisés qui forcent presque à chercher le parasite présent sur le testicule du morpion du bug qui pourrait peut-être se présenter dans le cas d'utilisation hypothétique... Ca règle le problème des modules/packages/flows, mais ça me parait tout bonnement ingérable de penser à tout à l'avance. C'est prétendument l'arme ultime pour l'architecture, mais ça tue tout le coté adaptation/relationnel du processus de développement. En somme "Prévoyez tout à l'avance, mais attendez-vous à être surpris !". Toujours aussi confus...

Avec tout ça, j'essaie de me construire ma propre méthode, partant de SCRUM pour ce qui est du processus de développement, et dispatchant à divers endroits du processus des "phases" (vilain mot pour SCRUM) et des "stories techniques" visant à creuser progressivement telle ou telle couche d'architecture... Et plus ça va, plus ça devient un merdier, là aussi.

Bref, si d'autres personnes ont des références utiles, des "Big Pictures", comme tu dis, je les supplie de les partager ici ! :D

AH ! Et puis si vous avez une idée du contenu des cours Oracle dont je parlais dans mon premier post, je suis intéressé ! (si Oracle l'autorise, bien entendu).

Je pense que tu mets le doigt sur une question très importante qui est : quelle quantité d'architecture doit-on faire dès le début de projet ? Ce à quoi tu fais allusion avec UML est du Big Design Upfront, un plan parfaitement calculé à l'avance, mais on sait ce qui arrive à ce genre de plans, ils passent rarement l'épreuve du terrain ;)

Beaucoup d'équipes fonctionnant avec Scrum font un "Sprint zéro" purement technique dans lequel les bases architecturales de l'application sont jetées, les environnements de développement/test créés, les outils mis en place, les frameworks installés, etc.

Mais d'autres considèrent plus agile de démarrer avec en point de mire une tranche de fonctionnalité verticale complète (une user story ou un use case) pour que cette première itération apporte quand même de la valeur métier, même toute petite, même si on sait que ça va mettre plus longtemps que quand toute l'architecture sera déjà en place. Le premier livre que j'ai cité, GooS, est sans doute le plus intéressant pour comprendre cette démarche. Il décrit un cas réel (une application d'enchères) et même s'il faut un peu s'accrocher pour comprendre tout le design, on voit bien comment on peut construire incrémentalement une fonctionnalité avec juste le strict nécessaire d'architecture, sans gaspiller du temps de cerveau à prévoir des palais d'architecture logicielle qui ne seront finalement jamais utilisés.

Cela rejoint un peu l'approche d'Uncle Bob Martin pour qui l'architecture doit permettre de reporter les décisions de conception jusqu'au dernier moment possible. On peut par exemple très bien travailler sans base de données pour une application jusqu'à la version X, où on se rend compte qu'on en a finalement besoin. A ce propos je te conseille ce billet de blog et cette vidéo : _https://vimeo.com/68215570 de lui.

Je ne sais pas si tu bosses pour les éditeurs, en tout cas tu les vends bien ! :D

Citation:

---

construire incrémentalement une fonctionnalité avec juste le strict nécessaire d'architecture, sans gaspiller du temps de cerveau à prévoir des palais d'architecture logicielle qui ne seront finalement jamais utilisés

---

Je pense que tout l'art de la discipline est là, en effet.

Je vais faire un tour à la librairie et sur le blog, je te dirais ce que j'en pense.
En tout cas, merci encore !

P.S. : Les autres qui passeraient par là : je suis toujours demandeur de ce genre de références ! :D

Wow.

Je viens de regarder la vidéo de la conférence de Martin et de lire son article "the Clean Architecture"... même s'il n'y a pas de méthodologie précise livrée avec, ça range déjà pas mal de chose dans les idées que je me faisais de tout ça.

Dans sa conférence, il explique bien comment, finalement, tous ces "modèles" et ces "méthodes" dont on parlait plus tôt ne sont que des tentatives des développeurs d'adapter dans l'urgence une architecture simple (comme définie par le modèle "Entity-Interactor-Boundary" de Jacobson) aux changements brutaux qu'ont représenté l'arrivée du web et la dématérialisation des données.
Enfin, au moins pour ce qui concerne l'OO. Mais je suppose que le modèle est adaptable au non-OO puisque les données y sont plus "simples" (les adapters travaillent moins, voire pas du tout). Ça ressemble donc au type de "méta-modèle" que je cherchais !

Dans son blog, il précise et généralise encore plus en insistant sur le principe de dépendance. Son modèle de "Clean Architecture" me parait, au coup d'oeil, particulièrement efficace pour la sécurisation des entités (encapsulées dans la couche applicative), pour la sécurisation du traitement (encapsulé dans la couche des interfaces), pour la modularité, pour le multi-plateforme...

A y repenser, les design patterns sont des cas particuliers où appliquer une ou deux des règles du "SOLID". Son modèle, lui, applique les cinq principes en même temps à chaque couche. C'est en ça qu'il est plus fondamental que ces patterns et que tous les modèles "rustines" qui me déplaisent tant.

Pour en extraire grossièrement des méthodologies de développement :
- soit par couche : de la couche la plus centrale (entité) jusqu'à atteindre les couches externes (GUI, DB), tous les use-cases en même temps. Ce qui est lourd pour la conception initiale.
- soit par quartier/use-case : toutes les couches sont développées en même temps mais seulement pour ce qui concerne le use-case. Ça revient à la méthode des stories.
Dans les deux cas, une schématisation globale des couches, des entités, des use-cases, des adapters, des interfaces attendus sur le logiciel pendant la période préparatoire d'un projet permet de dégager assez clairement et rapidement les modules/packages/flows dès le départ.
Dans les deux cas aussi, la modularité permet d'ajouter des use-cases en cours de route et permet donc le développement par itération sans mauvaise surprise pour l'architecture générale.
Dans les deux cas enfin, le première chose à faire est de définir clairement les entités.

La petite subtilité du modèle, qui va en gêner beaucoup je pense, c'est qu'il faut tout faire pour se passer des frameworks.

Bref, ça me parait très prometteur tout ça. Merci de me l'avoir fait découvrir ! Je fonce lire le bouquin maintenant :D