Marc Bouvier
Strasbourg
Quand tu fais du code, il t'arrives de rencontrer des trucs affreux ?!
Alors comment passer d'un code crade à quelque chose d'évolutif et surtout durable ?
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.
Je me bats avec notre code base pour faire des tests lisibles et pas trop répétitifs mais je ne suis pas ravi par le résultat. Récemment, nous avons décidé d'arrêter de mocker le "domaine" lorsque nous testons les contrôleurs. Les tests sont moches mais éfficaces et testent les grandes lignes (le domaine est plus facile à tester pour couvrir tous les cas). Mais je m'étonne d'être de moins en moins convaincu par les tests unitaires (unité=classe).
blog.sebastian-daschner.com/...
Vue.js ne serait-il pas un jouet ?! Pourquoi ne pas faire du react plutôt ?
Son image de framework facile à appréhender signifie-t-elle un outil moins puissant ?
Y a-t-il un risque de miser sur Vue.js aujourd’hui ?
Quelle opportunité représente ce framework pour les dev ?
On en parle dans l’épisode d’aujourd’hui avec Elise Patrikaien, développeuse front end freelance sur Vu.js et Angular.
Pour suivre Elise Patrikaien sur linkedin : www.linkedin.com/...
Pour suivre Elise Patrikaien sur Twitter : twitter.com/elisepatrikain1
Merci à Élise pour son retour sur Vue.js.
Je suis entièrement d'accord avec elle sur la prise en main vraiment aisée de Vue.js. J'ai eu plusieurs fois l'occasion d'accompagner des devs backends à passer à Vue.js et effectivement, la montée en compétence s'est généralement bien passée, très graduelle et en découvrant au fur et à mesure toutes les fonctionnalités ES6.
Sans compter que depuis l'arrivée du Vue CLI, l'outil de ligne de commande, la gestion de la chaîne d'outillage sous-jacente est grandement simplifiée.
En revanche, bien que je n’aie pas encore essayé la version 3, je suis un peu inquiet entre l’image donnée par Benoît de Python 2 vs 3 sur l’écosystème, et l’impression qu’il repose beaucoup plus qu’avant sur une bonne connaissance de JS/ES laissant de côté la simplicité qui à fait son adoption, mais j’espère me tromper :)
Par contre, mon retour sur l’utilisation de Vue.js en entreprise est mitigé. Pour avoir travaillé sur plusieurs applications, j'ai pu constater que la vélocité baisse très vite dès que l'application commence à se complexifier.
Je pense que ça vient d’une part que Vue.js ne se suffit pas à lui-même. On se retrouve vite à ajouter une couche de gestion des données, généralement la combo Axios pour les appels REST et Vuex pour la gestion des données. Et puis on a plusieurs pages, alors on ajoute un routeur, généralement Vue Routeur. Cette liberté d'ajouter des briques au fur et à mesure du besoin, ça m'a surtout donné l'impression de réinventer la roue en me fabriquant un framework maison.
D’autre part, Vue.js ne propose aucune architecture pour le projet. On a quelques bonnes pratiques qui ont émergées comme le Props Down Events Up(1) et appliquer le bon vieux SRP pour éviter que ça parte trop en plat de spaghettis, mais c'est tout.
Du coup, on a dû expérimenter pour trouver nos propres conventions :
- un package "ui" avec les composants de base réutilisables
- des packages métier avec les composants qui font des traitements et le lien avec le store
- un package "page" pour les composants qui représentent les pages
- un package "store" pour le traitement des données
- un package "api" pour ne pas avoir du Axios partout dans le code
Tout ça consommant du temps et de l'énergie qui auraient pu être utilisés pour du développement de fonctionnalité.
Au final, j'ai du mal à voir l'avantage de cette approche sur les frameworks tel qu'Angular ou Ember.js.
Donc pour répondre à la question initiale du podcast : pour moi, oui, Vue.js est un jouet. Tout comme React d'ailleurs.
Les libs de composant, c’est parfait pour une démo ou un widget météo, mais pour faire une app, c'est vraiment insuffisant. Mon regard se porte maintenant sur les frameworks qui se construisent par dessus ces libs. Élise en a mentionné quelques-uns pour Vue.js : Nuxt et Quasar, qui me semblent également être les plus prometteurs.
(1) jasonformat.com/...
EDIT: reformulations
Pour aller un peu plus loin, je trouve que les webcomponents ont pas mal de potentiel. Ils peuvent être écrits en vanilla js , avec vuejs ou autre. Puis être intégrés avec d'autres frameworks.
Un bon exemple chez Clever Cloud : www.clever-cloud.com/...
Hubert Sablonnière en parle par ici : www.youtube.com/...
Un excellent talk proposant un exemple de clean architecture sur un projet front, en séparant la partie logique d'un composant (la logique 'contrôleur' : le data-model et son comportement) de son application sur le DOM (gérée par un framework). Ainsi, la logique de l’application est complètement découplée de la stack utilisée : dans la démo, on passe facilement d'une application écrite en Angular à une application écrite en React.
Probablement la meilleure explication de la méthodologie TDD que j'ai eu l'occasion de voir.
(le son s'améliore avant qu'il ne commence)
Énormément de pragmatisme. Le conférencier a une approche très particulière et personnelle de Tdd. Il s'approprie les bonnes idées sans aucun dogmatisme. Tout au long du live coding et a la fin il propose des idées pour améliorer l'expérience du developpeur, en particulier au sujet de la charge cognitive. Ces idées peuvent vraiment aider des développeurs neuro-atypiques a améliorer leur quotidien.
Récemment, Dart 2.12 a été livré dans Flutter 2. Cette mise à jour contient l’une des fonctionnalités les plus importantes du langage qui est le Null Safety.
Au final, lorsque je programme en Java (le monde professionnel ne semble toujours pas prêt pour Kotlin) je me rends compte que mon code est devenu plus défensif qu'il y a quelques années justement pour vérifier ce genre de chose et retrouver la sérénité que j'ai sur du Kotlin :/
Un super article de la part d'un confrère Artisan, sur une technique simple et efficace pour mettre le pied à l'étrier sur un projet !
En tout cas, ça pourrait répondre à des problématique que j'ai (syndrome de la feuille blanche)
Du code impeccable écrit partout pareil, ça donne envie, non ? Et pourtant, l’idée s’avère bien plus risquée qu’elle n’y parait.
J'aurais quand même tendance à poser un .editorconfig d'office dans n'importe quel projet pour les conventions les plus basiques : encodage des fichiers, espaces/tabulations, cr/lf en fin de ligne...
C'est supporté par tous les éditeurs, ça ne mange pas de pain et ça évite bien des problèmes (je pense à toi, le caractère de fin de ligne différent selon l'OS et aussi à toi fichier YAML qui ne supporte pas les tabulations).
Pour les aspects plus avancés, je recommanderais les conventions officielles (s'il y en a) et de n'en diverger qu'exceptionnellement : un nouvel arrivant aura déjà bien assez de sujets qui nécessitent une réadaptation.
Très dynamique avec plein de bonnes explications.