Un site qui répertorie les grands designs d'architectures (pour @animal et @doudou).
Beaucoup de choses appelées patterns ne le sont pas vraiment, on sent le côté buzz-word ou éléments de langage pour apporter de la crédibilité à son discours (surtout à des managers) mais bon, le marché étant ce qu'il est, mieux vaut s'adapter même si l'on n'est pas d'accord.
Une merveille pour réduire la taille des pages à trois fois rien.
J'abonde dans le sens de l'article. Le design pattern Builder est totalement obsolète en Kotlin puisque ce langage intègre les "defaulted method parameters" ce qui fait que si un paramètre venait à manquer, alors il prendrait automatiquement la valeur par défaut, par exemple :
class SocketJavaX(
private val port:Int = 0,
private val host:String? = null,
private val ssl:Boolean = false
)
Quand je vous disais que Kotlin a une multitude de petites choses qui rendent le dev facile et magique.
Comment sont construits les trailers de tous les grands block-busters #SeeThePattern
Les différents types de memory leaks et les patterns de memory consumption pour les détecter et les identifier.
Ils y sont tous ou presque ! Ceux du GoF, ceux d'Avalon, ceux de JEE, ce orientés SOA et MSOA. Quel travail !
Le liens direct dans la page : http://java-design-patterns.com/patterns/
Un autre lien utile : https://github.com/kamranahmedse/design-patterns-for-humans/blob/master/README.md
Un site de Google site écrit en parti par Jeff Shutterland (le mec avec Ward Cunningham qui a rassembler les autres pour créer scrum et rédiger l'agile manifesto).
N.B : pour moi-même et aux shaarlistes qui me suivent, ce site est un Google Site, ce qui implique qu'il puisse crever du jour au lendemain car c'est ce que fait Google avec l'ensemble de ses produits pas assez rentables, bref un backup est à faire.
Toujours pour Chlouchloutte, les design patterns organisationnels (supposés rendre scrum, kanban et agile manière générale obsolètes).
Beaucoup de doc à backuper en tout cas, en voici un extrait pour mémoire d'ailleurs :
Il a été documenté de nombreux Patterns Organisationnels par ceux qui se consacrent à l’étude des organisations. Jeff Sutherland considère par exemple que pour les équipes Scrum qui font du logiciel, il faut ajouter à Scrum les patterns suivants :
- Work Flows Inward (l’information aux équipes de développement ne doit pas venir de la hiérarchie)
- Architect Controls Product (l’architecte donne la direction et agit avec leadership)
- Architect Also Implements (l’architecte est également développeur pour garder le contact avec la réalité du terrain)
- Domain Expertise in Roles (recruter des experts dans leur domaine)
- Get On With It (même si votre plan est incomplet, prendre ce que vous savez déjà et commencer à construire le produit)
Il dit aussi appliquer systématiquement les Patterns suivants dans les équipes qu’il accompagne, celles qui démarrent comme celles qui veulent passer à la vitesse supérieure :
- Stable Teams (pérenniser au maximum la composition des équipes pour gagner en efficacité et en prédictibilité)
- Yesterday’s Weather (ne pas planifier plus que ce que l’équipe a réalisé dans le ou les Sprints précédents)
- Swarming: One-Piece Continuous Flow (maximiser l’effort de l’équipe sur l’élément le plus important à livrer afin de le finir au plus tôt)
- Illegitimus non Interruptus (allouer explicitement du temps pour les interruptions dans le Sprint, et interdire les interruptions au delà du temps alloué)
- Daily Clean Code (faire en sorte de toujours pouvoir fixer l’ensemble des défauts du produit en un jour)
- Emergency Procedure (l’équipe établit une procédure claire qu’elle met en oeuvre lorsque le Sprint va dans le mur)
- Scrumming the Scrum (à chaque Sprint l’équipe identifie le problème numéro 1 et le résout)
- Happiness Metric (l’équipe mesure sa satisfaction au travail, identifie une chose qu’elle pourrait faire pour accroitre sa satisfaction et l’implémente au Sprint prochain)
- Teams that finish early accelerate faster (prendre moins de chose dans les Sprints pour finir rapidement, puis ajouter des choses au Sprint au besoin)
Vous retrouverez le détail (contexte, problème, proposition de solution, effets attendus, etc.) de ces Patterns sur scrumplop.org. Le site est vieillot et il est parfois difficile de s’y retrouver, mais c’est la source la plus aboutie pour quiconque s’intéresse aux organisations et à leur performance. Courez-y !
Un lien pour Chlouchloutte qui porte sur SCRUM. En espérant que cela puisse t'aider durant tes prochaines phases de coaching.
Un tutoriel sur le design pattern builder du GoF où les différentes complexité d'implémentation de ce design pattern sont illustrés. Félicitation à l'auteur, très bon article.
Design Patterns, Anti-Patterns and Refactoring articles and guides. Design Patterns video tutorials for newbies. Simple descriptions and full source code examples in Java, C++, C#, PHP and Delphi.
Entity Component System.
Une façon sympa d'organiser ses objets pour coder un jeu vidéo.