La dépendance aux outils est hélas inévitable aujourd'hui (et je n'ai pas l'impression que ça aille en s'améliorant). Je crois que le seul moyen de limiter la casse c'est de commenter et de faire relire le code qu'on livre, le plus souvent et le mieux possible.

Dans ma mission actuelle, je passe plus de temps à discuter et à documenter ce que je fais qu'à effectivement coder. C'est incroyablement chronophage (vraiment, je suis surpris par cette inertie pachydermique, nouvelle pour moi) mais ça permet de fournir un boulot solide et pérenne. Naturellement cette qualité a un coût certain (très lourd comparativement à ce que je facture d'ordinaire) et se justifie davantage quand on développe des outils amenés à durer que quand on pond des sites jetables à la chaîne comme j'ai l'habitude de le faire.

Les clients qui ont besoin, comprennent et financent cette exigence de qualité sont encore rares, et je ne sais honnêtement pas si ça va s'améliorer. ]]> text/html https://www.nicolas-hoffmann.net/source/1667-Travailler-la-reduction-a-ma-dependance.html#comment158686 STPo Tue, 09 Jun 2015 15:33:52 +0000 > sans avoir à s'installer derrière un tableau de bord digne d'une navette spatiale.

voilà une bonne idée : en faisant aussi simple que possible. ^^

@MoOx
> Pour le point futur-ready… à méditer ;)

Cela n'empêche pas, on est bien d'accord. Comme je le dis, je ne suis pas contre ces outils, ils amènent forcément quelque chose. Mes interrogations sont plus sur la dépendance.

> Au final, il "suffit" de prévoir la communication (documentation) et de travailler en équipe (code review). Non ?

Oui, la doc est critique, quoi qu'il arrive, 1 000 000 fois d'accord. Et communiquer, communiquer, communiquer : +2 000 000 (au moins). :D ]]> text/html https://www.nicolas-hoffmann.net/source/1667-Travailler-la-reduction-a-ma-dependance.html#comment158685 Nico Tue, 09 Jun 2015 08:20:03 +0000 Dans ce sens je tends vers une simplification du workflow avec un minimum de dépendance (1/2 max par langage) + 1/2 outils globaux pour gérer tout ça.
Ce qui me fait aujourdhui par exemple: npm/webpack pour gérer mes développments + babel/eslint pour JS et cssnext/stylelint pour les CSS.

Pour être tranquille pendant mes vacances, tout ce qui doit être nécessaire à savoir est documenté dans un README (qui contient même l'installation des dépendances comme Node.js, pour dire). Ainsi, je gagne du temps, et j'en fais gagner aux autres. On ne me dérange pas pour me demander ce qu'il faut faire.

Ensuite on est en 2015, on fait plus du code en ninja que personne ne voit passer. Il faut des process simple et propres afin de faire des code review systématiquement.
J'ai aussi eu le cas d'un gros malin qui a bosser sur un fichier de cache CSS il y a 5 ans, on ne m'y reprendra plus.

Pour le point futur-ready, c'est bien rigolo de voir ces comportements. Si je prends l'exemple de Babeljs, je pense que JavaScript n'a jamais autant évolué et eu de nouvelles spécifications (ne serait-ce que des proposals bien fondé) depuis que un mec s'est amusé à faire un tool future-proof. A méditer ;)

Toutes mes dépendances tiennent finalement dans un README + quelques 2/3 scripts pour développer/préparer la production.

Il m'arrive de travailler avec des anciens qui ne proviennent pas vraiment du web et j'ai constaté un comportement assez fun:
- 1er abord: la personne ne veut pas "trop compliqué" (par peur de l'inconnu probablement)
- cela étant dit, la personne doit faire confiance car manque d'expérience sur ce plan. Elle écoute mes arguments (bien que sceptique)
- la personne voit le README, install tout sans accros en quelques minutes max et lance la commande "npm start".
- pour la production "npm build" et on voit le poids de fichiers fondre
- la personne va rapidement me demander d'améliorer ce workflow et fini un jour ou l'autre par dire quelque chose du genre "ah bah faut avouer que c'est quand même assez cool, j'ai montré ça à un dev .NET pour mettre en place tout ça, il en revenait pas que ça soit mis en place en 5min. Puis quand il a vu le livereload là, il pensait que c'était un bug". Je pense que ce dernier "testimonial" est bien la preuve qu'on ne fait pas tout ça pour rien.

Au final, il "suffit" de prévoir la communication (documentation) et de travailler en équipe (code review). Non ? ]]> text/html https://www.nicolas-hoffmann.net/source/1667-Travailler-la-reduction-a-ma-dependance.html#comment158684 MoOx Tue, 09 Jun 2015 07:40:27 +0000

Malgré l'intérêt des ces outils je trouve qu'ils ne valent pas la possibilité de pouvoir modifier ses CSS "là tout de suite" sans avoir à s'installer derrière un tableau de bord digne d'une navette spatiale.

Restons agiles. ]]> text/html https://www.nicolas-hoffmann.net/source/1667-Travailler-la-reduction-a-ma-dependance.html#comment158683 br1o Tue, 09 Jun 2015 05:02:13 +0000