Le pair programming est-il une évidence pour tous les devs et les managers ?
Quels sont les avantages de cette pratique ? Peut-elle être un levier d’émulation pour une équipe et un facteur d’attractivité pour l’entreprise ?
Dans le podcast d’aujourd’hui avec Pierre Criulanscy on te donne le top 3 des préjugés sur le TDD !
Quels leviers faut-il activer pour généraliser cette pratique ?
Dans ta vie de freelance, tu peux être amené à construire toi même une solution logiciel ou un outils sur mesure qui te convienne parfaitement face à certains mastodontes que tu trouves, au fond pas terribles.
Faire du code de qualité devrait être donné à tout le monde ; mais on est quasiment tous passés par une expérience ou l'on a fait du code de merde !
Comment et pourquoi créer un design system ? Quelles sont les sources de motivation des devs ?
Pourquoi le rendre open source ? Peut-il vraiment être transposable sans difficulté ?
Quels sont les défis de sa maintenance ?
Très intéressant, comme toujours ;-)
Mais il y a une question que je me posais tout de même : quand tu as abordé l'intérêt d'utiliser le design system de Welcome to the Jungle, les invités ont indiqués qu'il y en avait des bien plus personnalisables déjà sur le marché, pourquoi alors en avoir développé un maison ?
Je me suis dit que ça pouvait peut-être permettre de ne pas se reposer sur un projet qui pourrait faire des breaking change trop souvent et ainsi permettre de migrer les sites de l'entreprise en douceur, mais non, ils nous indiquent en être à la 5e versions majeure en l'espace de 3 ans (si j'ai bien suivi), de migrations compliquées et d'un refactoring en mode "hardcore" de 6 mois !
Est-ce qu'il y a un bénéfice caché qu'ils n'ont pas mentionné et que je n'arrive pas à voir ?
Un peu comme ces éditeurs qui ont un framework maison : ils l'ont souvent fait avant que des projets matures émergent.