Le code de qualité est-il une évidence pour tous les développeurs ?
Dans le podcast d’aujourd’hui, on aborde les questions d’hypercroissance et d’autonomie avec Thomas Pierrain de chez Agicap.
Quand on parle de croissance et même d’hypercroissance - c’est à dire quand l’enjeu n’est finalement plus la start-up mais plutôt la scale-up- comment faire pour ne pas diluer sa culture, ses pratiques et sa cohérence ?
Quel management du changement opérer, avec qui et comment ?
Comment conserver les métiers au coeur des décisions, des actions quand on passe de quelques devs à plus de 150 devs ?!
Est-ce seulement possible ?
Et une question en or que l’on a posé à Thomas : Quelles sont, concrètement, les pratiques qui facilitent et qui permettent de conserver l’autonomie dans l’organisation ?
J’en profite pour t’informer qu’Agicap est sponsor d’Artisan Développeur pour quelques mois.
Tout comme moi, ils partagent les valeurs du Craft et du code durable tout en tenant compte des individus qui composent l’entreprise.
Tu retrouveras ci-dessous plusieurs liens pour les découvrir et découvrir, peut-être, ton futur job ?
Dans le podcast d’aujourd’hui, je te propose de parler de ton temps avec Marielle Cuirassier.
Après la battle visant à vous sonder sur la pertinence d'apprendre la tech grâce aux livres, Marek Kalnik nous propose un debrief mardi 5 avril à 12h30.
Est-ce que les frameworks et l'architecture hexagonale font bon ménage ?
Y-a-t-il des projets qui s’adaptent mieux que d’autres avec de l’hexa ou du framework ?
Quelles sont les contraintes, les atouts ?
Comment choisir et adapter son projet à l'une de ces 2 patterns ?
Merci pour ce podcast très chouette, j'ai particulièrement apprécié la partie sur la gestion/priorisation de la dette technique liée à l'absence d'archi hexa.
J'aurais bien aimé quelques précisions sur le fait de switcher vers de l'archi hexa avec Rails. Qu'entends-tu Benoit précisément ? Sur le sujet rails/harchi hexa j'ai la référence suivante que j'avais trouvée très intéressante : martinfowler.com/.... Ce que j'en ai retenu : si le métier s'y prête, il peut être pertinent de partir sur du Rails, donc avec la partie sgbd dans l'hexagone. En revanche cela n'empêche pas de faire de l'hexagonal sur les interactions que l'on considère à droite de l'hexagone, comme les appels vers d'autres partenaires. Et ce point me fait réagir aussi sur la définition de l'archi hexa qui serait "une standardisation du principe d'inversion de dépendance". L'inversion de dépendance me semble effectivement un point important de l'archi hexa, mais l'isolation des modèles (le côté anticorruption layer de l'archi) me parait tout aussi important et n'a pas été évoqué. Car on peut avoir de l'inversion de dépendance, mais se trimballer des objets d'api comme modèle métier, et ça, c'est bien galère :)
Bonne remarque.
Vis-à-vis de rails, mon point est simplement de dire que l'hexa dénature par mal le framework.
Si c'est pour faire ça, autant partir sur autre chose (ou créer un autre framework ?).
Ce n'est que mon avis.
La communauté TheMatureDev vient de fermer ces portes néanmoins les mouvements d'entreprenariat minimalisme n'ont jamais autant le vent en poupe en ce moment.
Connaissez vous d'autres blogs, discords, communautés qui parlent de ce sujet ?
Sur Ethique et tech, on parle de tech étique et notamment d'entrepreneuriat responsable.
discord.gg/SpYfzHj7Tv
L’assertivité est une notion assez complexe à appréhender. On la décrypte dans l’épisode d’aujourd’hui avec Camille Fantini, coach professionnel et formatrice.
Agilité à l'échelle, un mythe ? Une réalité ?
Agilité à l'échelle, un mythe ? Une réalité ?
Daniel Terhirst-North et Anna Urbaniak s'appuient sur leurs expériences et collaborations pour dessiner leur vision globale de cette problématique organisationnelle. Ils proposent des idées pour aider à comprendre et naviguer dans des organisations afin de développer des produits.
Plutôt que de vanter les mérites de tel ou tel Framework © ou Outil®, ils déconstruisent les enjeux des organisations en identifiant 2 états d'esprit.
- "digital product" mindset
- "industrial"
Les conférenciers définissent les 2 états d'esprit et les caractéristiques qui les opposent.
Ils développent pourquoi les organisations qui envisagent l'agilité à l'échelle nécessitent un équilibre entre les deux états d'esprit pour réussir.
Ils en arrivent au constat qu'il est nécessaire pour ces organisations d'atteindre l'autonomie par le biais de l'alignement.
Ils définissent les notions d'autonomie et d'alignement, dont les composantes permettent de comprendre et d'agir sur les organisations.
Les BPM sont des outils très intéressants. Par contre, il s'agit d'une solution technique qui apporte une complexité sous-jacente assez conséquente. Dans le monde de l'entreprise, on y fait ce recours très souvent pour modéliser des process métiers à point de devenir un choix par défaut assez dogmatique, un nième marteau de Maslow. Il est intéressant de voir d'autres alternatives à cette solution.
J'ai pu constater le vendor locking que ça entraînait et la complexité accidentelle que ça engendrait. Ajouter à cela la difficulté de mettre en place des migrations et la quasi impossibilité de tester automatiquement.
Ma perception a été que les avantages que ça apportait (car il y en avait : traçabilité clé en main, outils de visualisation,...) étaient rapidement éclipsés par leurs inconvénients.
Quelles sont les bases pédagogiques qui permettent une bonne transmission ?
Déjà, merci pour ce podcast, c'est toujours des sujets intéressant avec des intervenants qualitatif et ça fait plaisir ^^.
Ensuite, merci à Xavier d'apporter son témoignage sur le sujet.
Je suis dev web depuis 10 maintenant et j'ai eu l'occasion de changer d'entreprise plusieurs fois.
J'ai eu l'occasion de pratiquer pendant 1 an les tests unitaires mais surtout les tests fonctionnelles. Ce n'était pas du TDD car on faisait les tests après avoir coder nos solutions, mais j'ai quand même pu comprendre l'intérêt de la démarche et surtout de comprendre que ce n'était pas du temps perdu.
Mais voilà, j'ai fais 8 boîtes différentes et seulement 1 seules d'entre-elles encadrait le code de l'application avec des tests. C'était d'ailleurs la seule entreprise ou presque à avoir en tête les principes agiles, les bonnes pratiques, à mettre en pratique les design pattern de manière propre et justifiée.
Force est de constaté que si l'entreprise ne possède pas cet état d'esprit à l'origine et la force de s'y tenir sur le long terme, c'est vraiment pas possible de faire attention à la qualité de son travail de manière rigoureuse et complète.
En tout cas, c'est mon ressentit
Et encore, tu as eu de la chance : je suis pas sûr qu'une boite sur 8 utilise les tests automatiques (je ne parle même pas de faire du TDD).
Si c'est important pour ta pratique, je t'invite à en faire un critère de choix pour tes futurs jobs.