Travailler la réduction à « ma dépendance »

Travailler la réduction à « ma dépendance » (le 8 juin 2015)

Un tweet de STPo exprime bien un sentiment qui me dérange de plus en plus dans mon métier. Grosso modo, la phrase qu’il cite donne ceci (traduction approximative et incomplète).

La pire partie du développement web est la quantité de temps dépensée à investiguer chaque petit nouvel outil qui sort. Cela pourrait être utile ou non, comment le savoir tant qu’on ne l’a pas essayé soi-même ?
[…]
Enfin, qu’arrive-t-il quand vous quittez votre job et que quelqu’un arrive un an après ? Oh, ce pré-processeur Sass ne marche pas ? C’est quoi Angular, un outil pour faire des mesures ?

Effectivement, et ce n’est pas la première fois que j’en parle ici et ailleurs (notamment dans la veille technologique), il y a actuellement une espèce de course à l’armement point de vue outils sur le front-end (mais pas que).

Une blague qui revient d’ailleurs souvent étant qu’il ne se passe pas une journée sans qu’un nouveau framework JavaScript/CSS ne sorte. Sans compter tous les outils de workflow : pré-processeurs, post-processeurs, imparfait-du-subjonctif-processeurs, etc. Ils ont d’ailleurs des noms bizarres, Grunt (pour moi le cri d’un Orc), Gulp (quelqu’un qui avale sa salive, ça ne met pas en confiance), etc.

Comme tout curieux, il m’arrive d’en tester, d’en utiliser, d’en adopter, d’en créer, etc. Je me dis que tout ce qui est « cool » et qui apporte un vrai bénéfice ne peut pas tarder à être adopté.

Sauf que non, pas du tout, enfin, pas toujours. Laissez-moi vous raconter quelques mésaventures.

L’autre jour, on me demande de revenir sur un site que j’avais intégré. J’avais fait un boulot millimétré, hyper carré (variables, conventions, etc.) avec la version Sass de Röcssti. Sauf que le site en question a été modifié entre temps par un autre, bien malmené, le tout sur la CSS générée et non la version Sass. Oui, vous pourriez me répondre que celui qui a fait ça mérite des baffes (et je suis 100% d’accord), il n’empêche que ça arrive, et in fine, j’ai été emmerdé par mon propre choix.

Autre cas de figure : j’avais utilisé Sass pour un autre site, et dès qu’une modification doit être effectuée dessus point de vue CSS, je suis systématiquement appelé (configuration, etc.). Et pareil pour plein d’autres très bons outils.

Ce n’est pas mal en soi que je sois référent sur la CSS de certains sites ou sur certains outils, mais clairement et pour le dire vulgairement : moi ça m’emmerde d’être le maillon incontournable.

J’adore rendre service. J’adore expliquer des trucs, des techniques. En tutoriel, dans des billets, des articles, des conférences ou de vive voix, c’est un des plus grands plaisirs de mon métier. Mais comme tout développeur, j’ai aussi besoin qu’on me foute la paix quand je code. Et je déteste être dérangé en congé ou en vacances parce que j’ai mis en place un truc que je suis le seul à maitriser (et encore dans certains cas, repassez sur un développement vieux de deux ans, des fois, vous écarquillez les yeux, même sur votre propre code).

Et la seule loi qui prévaut, c’est celle de l’emmerdement maximum, autrement dit la loi de Murphy. Si je peux être emmerdé sur 5 projets, je vais être emmerdé sur 5 projets. Au final, quel est le plus important ?

  • Que j’utilise un outil qui me fait gagner 2 heures mais où je peux être dérangé 10 fois à l’avenir ?
  • Que je permette qu’on reprenne mon travail sans moi ?
  • Que je sois future-ready pour des trucs instables ? (j’adore les gens qui prédisent le futur dans notre métier, ils devraient postuler chez les voyants)
  • Que je me facilite la vie sans penser aux conséquences ?
  • Ou que je réduise la dépendance à l’outil ?

Alors oui, pour certaines intégrations, je ne voudrais et ne pourrais pas me passer de Sass car le temps pour faire certaines choses à la main serait monstrueux. Mais depuis une année, je remarque… qu’on s’en passe très bien dans de (très) nombreux cas, surtout quand on a un peu de méthodologie. Et une CSS reste une CSS, même dans 3 ans. Qui me dit ce qui restera dans 3 ans des outils ?

Que ce soit clair, je ne suis pas anti-outils, j’adore l’outil de calcul de rythme vertical de Pascal pour n’en citer qu’un parmi beaucoup. Et il y a pas de risque à utiliser les valeurs qu’il génère, c’est de la CSS.

J’adore l’approche de Kaelig quand il explique comment faire le pont entre les développeurs et les designers. C’est brillant et le contexte est parfaitement adapté.

Clairement, je travaille à réduire la dépendance à ma personne (et donc à l’outil). Déjà, parce que j’ai décidé d’arrêter de sauver le monde. Et surtout pour penser aux autres, que j’emmerde tout autant que moi. Et curieusement, je n’ai jamais autant progressé que depuis que je réfléchis ainsi. Cela force par exemple à faire des scripts aussi simples et souples que possible. À être hyper carré dans mes CSS.

La fin est dans l’amélioration qualitative globale, pas dans les outils. Les outils ne sont qu’un moyen. Il devrait y avoir une mesure de l’empreinte que l’on fait sur ces choix. Une mesure de la quantité de doigts que l’on met dans un engrenage…

Permalien :

Flux RSS des commentaires de ce billet : https://www.nicolas-hoffmann.net/rss/commentaires.php?id_news=1667

5 commentaires

Posté par br1o le 09/06/2015 à 5:02:13
Très bonne réflexion à laquelle j'adhère totalement, d'autant plus que je n'utilise aucun outil pre-post ou uber-processeur, à l'exception de mon cortex frontal (clin d’oeil)

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.
Posté par MoOx le 09/06/2015 à 7:40:27
C'est marrant car j'avais la même réflexion. On peut rapidement se faire dépassé par le nombre d'outils que certains utilisent.
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 (clin d’oeil)

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 ?
Posté par Nico le 09/06/2015 à 8:20:03
@Br1o :
> 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 (clin d’oeil)

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). (grand sourire)
Posté par STPo le 09/06/2015 à 15:33:52
Merci d'avoir rebondi, je suis assez d'accord avec ce que tu dis ici.

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.
Posté par mulk le 26/06/2015 à 11:26:08
Ça me fait penser à cette grande période, début 2000, où nombreuses étaient les agences qui proposaient leur CMS "propriétaires" à leurs clients.
Combien de ces agences existent encore aujourd'hui? Parmi les clients, combien sont ceux, après disparition de l'agence, ont dû TOUT refaire?

Ajouter un commentaire









L'option « Se souvenir de mes informations » utilise un cookie, elle ne sera pas effective si vous les avez désactivés.

Les balises HTML ne seront pas interprétées, il est donc inutile d'en mettre. Par contre, les sauts de lignes de votre commentaire seront pris en compte, ne mettez donc pas de <br />, le site s'en chargera. Bien sûr, un commentaire vide ne sera pas ajouté !

L'auteur (autrement dit moi) n'est pas responsable des éventuelles fautes d'orthographe dans les commentaires.
Tout propos raciste et/ou insultant sera supprimé sans préavis. Les commentaires hors de propos destinés à faire de la pub pour des sites seront également supprimés sans ménagement.

Je vous prie de me pardonner, j'ai énormément de mal à lire le "langage" SMS, il n'est donc pas du tout interdit de s'abstenir de l'utiliser. Qui plus est, vous avez sûrement un clavier digne de ce nom et pas celui d'un téléphone portable. Ne vous gênez pas pour utiliser l'option "Prévisualiser" si vous voulez vous relire avant de poster, je vous en remercie d'avance !

Cet article a été écrit par Nicolas Hoffmann.

Ce site est la propriété de Nicolas Hoffmann.
Tous droits réservés, les textes du blog sont publiés sous licence CC BY-NC-SA.