2021-02-02 - Complexite.md 2.4KB
Complexité
[en] As much as we talk about avoiding complexity in our programs, we seem to love the complexity of the tooling around our programs. As Ousterhout notes, ==every time you add a tool or configuration to a project, you’re adding an element that developers must learn==, be aware of, or at minimum be exposed to. So while we think we’re lowering the bar of contributing and collaborating on a project — which may be true for some people — it’s possible we’re actually excluding people from contribution and collaboration because of the overwhelming complexity of our team of robots.
Suite de mes réflexions sur le sujet (et en fait il s’agit d’un truc autour duquel je tourne depuis pas mal de temps), je doute de plus en plus de la pertinence de ces enchaînements d’étapes à chaque commit/push. Ma difficulté actuelle est de faire la distinction entre les moments où c’est important et ceux où ça peut être facultatif (et potentiellement le rendre désactivable). On peut rapidement être nostalgique (cache) d’un temps où l’on n’avait pas tout ça mais je me rappelle aussi du renommage des fichiers en direct sur le serveur et des conflits ou des oublis lorsqu’on travaille à plusieurs dessus, etc. C’était l’enfer et c’est bien pour cela que l’on s’est outillé un minimum depuis.
Il y a probablement un entre-deux plus sain à trouver. Et en fait plusieurs en fonction du contexte. Je regrette parfois d’avoir lâché du lest sur certains aspects, j’en apprécie d’autres au quotidien. Une histoire de compromis.
[en] The technology stack was not the limit we faced in this project over the years. It was rather the ==abstractions== we created our own that got in our way.
*Maintaining JavaScript applications in the long term* (cache)