8539 shaares
234 results
tagged
architecture
Le problème de la simplicité, c'est que ça ne fait pas vendre un écosystème complet de solutions ... Cela dit, effectivement, le "monolithe" (le terme est incorrect), c'est simple ... et ça marche.
Un article qui offre un survol correct de la modernisation d'application. Il est toutefois dommage que les sujets vraiment délicats (comme la dette organisationnelle) n'y apparaissent pas ...
Oh je sens que je vais regarder ça en détail plus tard ...
Un repository intéressant regroupant des ordres de grandeur pour permettre facilement des estimations rapides.
Un article franchement intéressant sur l'adoption (ou pas) de Kafka en fonction de vraies contraintes techniques.
Ce tweet va me servir ...
Une lecture qui correspond très précisément à mon activité du moment ...
Il va falloir que je regarde ce truc, ça m'a l'air ... conceptuellement intéressant.
Cette idée de réécrire une partie d'un code en vérifiant sa qualité au fur et à mesure n'est pas si innovante que ça, mais elle est ici bien présentée.
C'est une vision bien plus intéressante que le découpage en contrôleur/service/repository dont les amateurs de Spring nous rebattent les oreilles (alors que c'est vraiment la pire organisation possible).
Alors ça ça fait du bien parce que ça fait beaucoup de mal. On a toujours tendance à croire que les composants d'un système logiciel sont stables dans le temps, alors qu'en fait, pas du tout.
Ca me fait vraiment penser à la manière dont Simon Brown présent le modèle C4 (bon, c'est normal vu le sujet)
Parfaitement juste : clean code en tant qu'idée est sans doute bien à un niveau très local, mais inapproprié à un niveau plus global. Pour le dire autrement, dans un système complexe, il y a des moments où la complexité se laisse voir
Un article vraiment intéressant pour comprendre comment l'architecture d'entreprise et l'agilité s'articulent
Un article intéressant mettant en regard l'UX et la modélisation de systèmes.
Oh, wow, la minimal viable bureaucracy, c'est vraiment un concept auquel j'accroche à fond
Je suis d'accord avec le constat fait précisément dans ce tweet, même si j'ai tendance à désapprouver les raisons évoquées. A mon avis, il s'agit plus du fait qu'un architecte est fondamentalement un rôle transient.
Il y a dans cet article une vision à peu près correcte. MAIS utiliser des branches/pull request/... sans utiliser le bug tracker me paraît être une vision incorrecte du travail de communication de l'architecte. Franchement, les évolutions ne sont pas que des branches Git. Ce sont aussi, et surtout,d es tickets.
Un chouette article qui met bien en valeur un des aspects cachés qui fait l'intérêt de ce métier : réussir à associer les bons problèmes aux bonnes solutions.
Peut-être un complément intéressant à l'écosystème PlantUML, mais connaissant la complexité qu'il y a à manipuler GraphViz, je crains le truc pas vraiment fiable ...