L:architecture represented les decisions significantes où celles ci sont mesurées par le coût de leur changement.
Simon présente un exercice qu’il fait avec ses étudiant, partir d’une liste de besoins, leur laisser 40min et leur demande d’architecturer cela. Le résultat doit être des dessins représentant le système.
On se rends compte de plusieurs choses:
- Le plus difficile n’est pas de concevoir Mais representer les elements
- lord de la presentation des solutions, les gens expliquent des chooses autour de lemurs dessins, ce qui veut dire que le gros des informations est toujours ds leur tête!
Notre industrie s’est beaucoup améliorée ces 10 dernières années avec l’agilite mais rien n’a été fait pour améliorer la représentation des éléments techniques et fonctionnels d’architecture. UML n’etant pas une valide, ou en tout cas pas suffisante.
Sketching architecture
Dessinons des choses simples:
The origami sketch(celui qu’on doit plier pour que cela puisse prendre du sens…)
Celui qui privilégie la technique:
Dans tous les cas, aucune représentation n’est bonne. Le mode de représentation n’est pas clarifié et juste lié à l’interprétation des gens qui on fait les dessins au moment ou ils l’on fait (ces couleurs veulent t’elles dire qq. chose ou c’est juste que les gens avaient des feutres différents?…)
Tout est base sur des suppositions, à la fois au moment de la réalisation des dessins mais aussi après coup au moment de leur lecture…
Tout ça pour se rendre compte que globalement nous n’avons pas les bons moyens de communication
Quelques faits supplémentaires:
- collaborative design : faire du pair architecture est bon! (Note: oui oui oui)
- on ne peut tout mettre ds un seul modèle, c’est souvent la source du pb, on essaye de tout mettre ds un dessin
- en général pas besoin d’uml, on se débrouille très bien avec des dessins mais ce qu’il manque c’est un certain formalisme commun
- se poser la question: est ce que vous pourriez coder ce dessin tel quel?
Solutions
Bien mettre des boîtes pour encapsuler ce qui va ensemble
Se mettre d’accord sur un ensemble simple d’abstractions (pas forcément de notation standard)
Définir progressivement le niveau de détail avec l’approche C4:
.
Les 4 C:
Contexte
- que construisons nous, qui l’utilise (acteur, rôles, personés…), comment cela rentre ds le système
Containers
- qu’elles sont les décisions techniques de haut niveau, comment les containers communiquent, en tant que développeur ou Vait je devoir mette mon code
Components
- de quels composants, service le container est constitué, est ce que les choix et responsabilités sont clairs?
Component
Vue détaillée d’un composant. Faire attention à ce niveau de détail à ne pas mettre de noms mais plutôt de décrire des responsabilités (le nom peut être mal interprété alors que la signification restera)
Trucs supplémentaires:
- dessiner sur papier ou bobard mais utiliser des post It pour les boîtes,
- toujours se poser la question de comment on coderait un truc juste pour voir si on a le niveau d’infos supplémentaires
Des dessins efficaces restent le meilleur moyen de communiquer sur une architecture. Cela devrait faire partie des choses que tous les développeurs devraient apprendre à mieux faire.
Ces dessins sont des moyens de communication avant tout mais ce ne sont pas des modèles précis, quand vous en avez besoin faites de l’uml.
D’une forme agile, il s’agit avant tout pour chacun de trouver la bonne abstraction et de trouver ce qui marche le mieux pour son équipe.
Pour finir une petite réduction sur son bouquin valable 1 semaine:
