Certains s'étaient donné comme défi de faire un article par mois, dans le passé. (Référence à COil sur Strangebuzz.com en 2019, qui partage sur son blog des articles et snippets sur le développement, et souvent à propos de symfony). J'en suis loin, même si mon deuxième sujet arrive un mois environ après le premier.
Dernièrement, j’ai repris le développement de mon projet personnel, pour la gestion des stocks d’un restaurant (GLSR). Ça devenait compliqué. La branche principale était sous Symfony 2.8, et deux branches de restructuration étaient en version 4. Il fallait agir…
Et pour faire les choses correctement, je me devais de reprendre avec une organisation, une structure qui ne serait pas dictée par un framework, comme je le faisais depuis le début. En 2006, je commence avec Copix. Je débutais en php, l’idée avait démarrée 3 ou 4 ans auparavant, en php pur. J’aimais bien cette approche de cadre de travail comme je l’avais avec Excel. Un prochain article présente la genèse de cette idée.Visuel de la version Copix
En 2008, Copix est abandonné, et ma réflexion balance entre Zend framework et Symfony. Mon instinct m'a servi 😋. J'ai donc redémarré le dev avec Symfony 2. J'avançais petit à petit pendant mes jours de repos, certaines nuits aussi, filant sur le code de certaines fonctionnalités. Et tout se bloque en 2013, avec un changement d'emploi. Nouveau restaurant, nouvelle équipe. Je n'étais plus sur le code. C'était l'abandon.
2020 fut une année bizarre, et à plus d’un titre. Je travaille dans la restauration depuis trente ans, et jamais je n’aurai pensé pouvoir profiter d’une pause. Qui pouvait imaginer que tout le tourisme et la vie sociale (la vraie) s'arrêteraient d’un coup ? J’ai mis à profit cet “arrêt de travail” pour améliorer mes compétences dans le développement informatique, mon souhait de reconversion.
En parallèle d’un projet, pour lequel j’avais été recruté (ma première grosse mission) pendant cette période troublée, je continuais mes recherches sur des podcasts, blogs, vidéos tutorielles et conférences sur de multiples sujets piquant mon intérêt. J'avais plus de temps qu'avant 😉. Dernièrement, j’ai découvert, ou plutôt redécouvert une technique qui ressemble à une expérience vécue dans un groupe de restauration pour lequel j’ai travaillé : un genre de brainstorming géant. Mais plutôt que de créer une vision (projection) de la vie de et dans l’entreprise à un horizon de cinq ou dix ans, on travaille sur les éléments du projet. Le but est que, pour chaque fonctionnalité, ressortent des scénarios pour comprendre comment le tout fonctionne, mais surtout comprendre comment le développer sans se tromper de direction. Et ce, autant pour le développeur que pour le reste de l’équipe qui participe à l’élaboration de ce produit. Le principal dans cette approche, c’est que tout le monde y participe. Le client, qui est souvent l’expert métier, les différents responsables autour du produit, mais aussi et surtout les devs. Tous ceux qui ne connaissent pas le métier sur lequel ils vont travailler vont pouvoir poser un maximum de questions pour se faire expliquer tout ce qu’ils ne comprennent pas.
Mon but n'est pas de refaire un énième article/tuto sur la manière de faire, mais plutôt de vous partager les ressources qui m'ont permis de le faire : à chacun son expertise.
Cherchant de l'aide sur les différents canaux où je m'étais inscrit (slack, discord...), je prends connaissance pour débuter de la conférence de Kenny Baas-Shwegler : explications du concept de l'Event storming au sein d'un environnement DDD (ce sera l'objet d'un autre article) ; puis, un auteur me renvoie vers ses articles, où j’ai trouvé matière à bien aborder la démarche. J'aime bien sa présentation de son cerveau. Je vous les conseille, c'est une bonne source d'information pour cette réflexion, surtout pour la mise en œuvre.
Il s'agit donc de délimiter le périmètre du projet, les impacts,
puis d'établir le cheminement de chaque fonctionnalité.
Ainsi émergent des scenarii de fonctionnement, qui pourront guider les développeurs. A l'aide de ces tests d'acceptation, les premiers tests unitaires se dessinent, et le code en découlera.
Le gros changement se situe ici. Tout le développement peut débuter sans avoir besoin de quelque framework que ce soit, ni même de partie front. (Même si pour les besoins de ma diffusion, je pense développer un front en parallèle du back).
Le résultat de mon Event storming, disponible sur miro.com, n'est pas finalisé à l'écriture de cet article, mais il vous donne une vision du projet pour les premières fonctionnalités.
J'espère avoir éclairci le sujet pour celles et ceux qui souhaitaient de l'info, et de l'intérêt pour ceux qui aimeraient participer au projet.
Bientôt je vais pouvoir commencer les premiers tests, mais cela fera l'objet d'une prochaine publication.
Image par PublicDomainPictures de Pixabay