Halte à l'anarchitecture !

Des propos très génériques, une chose à retenir : "faites de l'architecture avant de coder", mais ça s'appuie sur rien de concret pour le justifier si ce n'est faire confiance à l'expérience du speaker. Ça manquait donc d'illustrations, d'arguments, d'exemples pour nous convaincre.

Bonjour Matthieu, merci d'avoir pris le temps de laisser un commentaire. Je suis bien d'accord sur le fait que je n'ai pas pu développer autant que je le souhaitais sur de nombreux sujets faute de temps.

J'ai donc dû prendre pas mal de raccourcis pour tenir dans le slot.

Ceci étant, je pense que les arguments présentés, même trop brièvement, devrait au moins donner à réfléchir, à défaut de convaincre d'emblée :)

un peu trop utopique à mon sens, difficilement exploitable en entreprise.

Beaucoup d'entreprises à succès ont commencé par "faire" avant de prendre du recul sur leur archi.

Mais un rappel sur ce qu'il faudrait faire si on pouvait, ça ne fait pas de mal ;)

Bonsoir Grégory,

utopique.. non ; compliqué, un peu, oui :)

Une fois encore, le manque de temps ne m'a pas permis d'expliciter mieux le processus. Une grande partie des réponses qu'il convient d'apporter aux questions d'architecture sont effectivement issues de l'expérience - il faut être pris pour être appris, dit-on :)

Ces réponses sont à leur tour des "principes d'architecture" ; l'architecte dispose de cette boîte à outil pour définir l'architecture des projets. Avec l'expérience, une grande partie de ce travail - notamment concernant la macro architecture - ne prend virtuellement plus de temps.

Quand à la micro architecture, du temps lui est consacré de fait. Simplement, si ce temps est dilué dans le développement, il enfle. La conclusion c'est, qu'en ne lui consacrant pas un temps défini, précis, en début de projet, on lui en consacre beaucoup plus !

En fin de compte, savoir "perdre" un quart d'heure pour gagner une heure...

Bonne présentation même si j'aurais également préféré quelques exemples

Très intéressant, merci pour ce retour.
Mais dommage que le propos ne soit pas plus nuancé et que l'architecture du logiciel ne soit pas plus "collaborative" et non la responsabilité unique d'un architecte.

Merci Xavier et Richard pour vos commentaires.

Une fois encore, je ne peux que déplorer le manque de temps :( et je comprends bien votre "frustration" par rapport à l'absence d'exemple ou au manque de nuance (j'ai du me concentrer sur le message à faire passer...).

La remarque de Xavier concernant l'aspect collaboratif est symptomatique : j'ai pris le soin de préciser qu'il était essentiel que l'architecture soit comprise par les développeurs, et qu'il fallait privilégier un média qui permettrait précisément l'échange entre l'architecte et les développeurs. Mais ça a été "noyé dans la masse" :)

Concernant la responsabilité, oui elle est celle de l'architecte, car il est difficile de partager la responsabilité d'une tâche précise. Si tout le monde est responsable, plus personne ne l'est en fin de compte, exactement comme pour les priorités... Ici, il ne s'agit pas de dire que l'architecte est le seul maître de l'architecture, mais qu'il a la responsabilité des choix qu'il fait.

S'il fait le choix de ne pas tenir compte des suggestions ou contestations de l'équipe de développement, ça reste de sa responsabilité, pas celle des développeurs. Mais il faut bien que quelqu'un tranche, sinon chacun fait à sa façon, et c'est .... l'anarchi-tecture ;)

Intéressant, très débatable, un beau pavé dans la marre en somme ;-)

Merci Samuel pour ton commentaire - quand il s'agit de moi, on parle souvent de "pavé Delamarre" :) J'ignore s'il y a un rapport avec ma stature ;)

Plein de bons rappels pour les gens qui ont la tête dans le guidon.

Intéressant de rappeler les concepts d'archi. Ca manquait d'exemples concrets.

Une bonne présentation des concepts auxquels il faut prêter attention avant de commencer un projet.

J'ai eu l'impression de retourner en SSII et de devoir pondre mes bons vieux DAT, MPD, MCD, et déployer le boilerplate de l'équipe pour qu'elle puisse attaquer la conception avec la plupart des problèmes réglés.

Aujourd'hui, je crois de plus en plus dans l'architecture émergente, la refacto continue, et j'aime beaucoup ce que disent Uncle Bob ou Greg Young à ce sujet.

Je dis pas qu'il ne faut pas d'archi et se lancer tête baissée dans un projet, mais je pense que les méthodos actuelles nous permettent de baisser un peu ce curseur et d'économiser du temps pour avancer plus vite sur le produit, ce qui est notamment le nerf de la guerre dans le domaine des startups.

Enfin et puisque les microservices sont à la mode de nos jours, ce type d'archi permet notamment de limiter la casse d'un côté si l'archi a été sous-estimée (moins de refacto par domaine car ils sont plus simple, et on n'attaque pas tout d'un coup), mais d'un autre côté c'est aussi dans ce type d'archi que le temps consommé par la phase d'architecture est la plus rentable car elle peut être réexploitée pour chaque MS.

Ca manquait un peu de pourquoi, et à qui ça s'adresse ? Trop générique à mon goût.

A nouveau, merci aux commentateurs :)

Pour répondre aux "critiques" (je mets des guillemets pour souligner que j'en perçois l'aspect constructif et non trollesque :)) d'Olivier :

J'ai trop peu fréquenté les SSII pour avoir été imprégné de leurs méthodes :) Je suis d'accord avec la majorité de tes remarques, et à titre personnel, je ne peux pas dire que faire ce travail d'archi m'exalte plus que ça...

Comme tu l'as fait remarqué, je n'ai pas précisé explicitement à qui s'adressait cette présentation. C'est sans doute parce que je ne suis pas aussi provocateur que ma réputation le laisse parfois croire :) Clairement, il n'est pas possible de considérer que tous les développeurs sont également compétents. Alors que pour des gens comme toi, comme beaucoup d'autres participants du Forum, ou encore moi-même, ces recommandations apparaissent comme un peu laborieuses, j'en conviens.

Mais mon job, ce n'est hélas pas la R&D, et les équipes avec lesquelles je travaille le plus souvent ont besoin de ce niveau d'encadrement du projet pour que les projets n'explosent pas en vol, notamment en terme de délai et de qualité. Il y a beaucoup de développeurs juniors sur le marché (je ne parle pas d'âge mais d'approche et d'expérience... 10 fois un an d'expérience, ça ne fait pas forcément 10 ans...), et leur niveau de productivité lorsqu'on leur demande à la fois d'adopter des outils qu'ils maîtrisent mal et qu'on leur laisse trop de responsabilité sur l'archi, est souvent catastrophique.

Enfin, mon propos ne s'oppose en aucun cas à la mise en ouvre de micro-services, ni a rien d'autre de ce que tu proposes : je n'ai d'ailleurs suggéré aucune archi :) Je dit juste qu'il est préférable que quelqu'un prenne les responsabilités des choix d'archi. Encore une fois, faire le choix de ne pas en faire reste un choix, et je ne le conteste pas a priori. Ca dépendra de l'équipe, de son niveau de compétence, de son envie de s'investir sur cette partie du job, etc.

Quoiqu'il en soit, merci pour ton commentaire très développé, qui me permettra d'adapter la forme de mon propos pour éviter les malentendus à l'avenir.

Pas ta meilleure pres Gauthier, il y aurait eu plus à dire... en rentrant dans le factuel et en partageant ton expérience plus qu'en énonçant de grands principes. Ca sera mieux la prochaine fois !

Salut François, et merci de ton commentaire ; même si tu es cruel de remuer le couteau dans la plaie :)

Je l'ai déjà dit dans ces commentaires et le répète : j'ai clairement manqué de temps - ces fameux slides trop chargés sur la description de ce que sont les tâches de macro et micro architecture avaient vocation a être bien plus détaillés, et en effet factuels. Mais les 30 minutes qui m'ont été octroyées (et même moins au final, tu en es témoin ;)) ne me permettaient pas d'entrer dans le détail autant que le sujet l'aurait mérité. J'espère avoir l'occasion de revenir sur ce sujet dans de meilleures conditions !

Je me réjouis cependant d'un certain nombre de retours plus enthousiastes, de la part de participants pour qui ces "évidences" et "généralités" n'en étaient pas tant que ça, et j'avoue que c'était d'abord à eux que je m'adressais - je n'ai pas la prétention d'apprendre grand chose sur ce type de sujet à des gens aussi expérimentés que toi ;)

Je rejoins l'avis de certains commentateurs ici, notamment cette impression de revenir vers de la rigidité là où l'on tend plus vers de la souplesse aujourd'hui.

Merci en tout cas de prendre le temps de répondre aux commentaires, il est vrai que de façon générale, les temps alloués à chaque conférencier étaient courts.

Dommage en effet que tu n'ai pas eu plus de temps ! Est-ce qu'il y aurai un blog post, une vidéo, d'autres talks que tu conseilles pour approfondir le sujet ?

Merci pour ces derniers commentaires - j'ai disposé de moins de temps ces derniers jours pour répondre lus tôt, et j'en suis désolé.

@Jérémy de la rigidité, je ne dirais certainement pas ça. La souplesse, bien sûr qu'elle est essentielle. Dans l'application elle-même, et je pense précisément que c'est en pensant correctement l'architecture que l'on garantit un maximum de souplesse à l'application. L'idée étant de se poser des questions et d'y apporter des réponses. Si l'architecte apporte des réponses rigides, ne me le mettez pas sur le dos :) Ce que j'en dis, c'est que ces questions on se les pose quoi qu'il arrive. Mais que si c'est fait de manière anarchique et/ou tardive, les conséquences sur le projet peuvent être considérables.

@Anonymous non, malheureusement, pour ce qui me concerne, je n'ai pas le temps de produire beaucoup de contenus. Je consacre le peu dont je dispose à travailler sur un "mini-framework" qui vise, naturellement, à faciliter ces questions d'architecture... pour le reste, j'avoue n'avoir pas spécialement fait de recherches sur le sujet, puisque, comme je l'ai indiqué, il s'agissait là d'abord d'un retour d'expérience, pas d'une réflexion théorique sur le sujet, qui serait issue d'études "universitaires" sur la question :)