Ce qui a changé dans ma façon de penser
- La simplicité ne vient pas d’elle-même ; c’est quelque chose qui demande un effort constant
- J’ai compris qu’il n’y a aucune raison d’être fier de gérer ou de comprendre la complexité
- Dans une équipe où se mélangent des niveaux d’expérience variés, les langages typés sont indispensables
- Java est un excellent langage précisément parce qu’il est ennuyeux
- Le REPL n’est pas très utile comme outil de conception, mais il l’est pour l’exploration
- En pratique, l’essentiel de la programmation devrait presque entièrement se faire avant l’écriture du code
- Le développement frontend est devenu un domaine digne d’un cauchemar kafkaïen, et ce n’est plus amusant
- La notion d’élégance ne constitue pas un véritable indicateur mesurable
- Un bon management est extrêmement précieux (j’en ai très rarement vu au cours de ma carrière)
- DynamoDB est une bonne base de données si elle correspond exactement à une charge de travail donnée
- L’orienté objet est une excellente approche dans les domaines où il s’applique bien. Vouer un culte exclusif au fonctionnel est absurde
Opinions acquises
- Le cœur de l’ingénierie, c’est la communication
- Il ne faut pas pousser trop loin le concept de Monad en Java
- Le Query Planner est redoutable
- Le moment où quelque chose semble « facile » est en réalité souvent le signe qu’on ne l’a pas vraiment compris
- Il faut laisser aux développeurs juniors la marge d’explorer et de faire des erreurs
- Il faut développer activement ses soft skills. Le retour sur investissement est immédiat
- Dans le développement d’applications généralistes, il n’existe presque pas de « véritable abstraction générique ». Mieux vaut écrire uniquement le code nécessaire
- À l’inverse, développer une bibliothèque consiste à concevoir des abstractions. Il faut consacrer du temps à trouver la bonne structure (forme algébrique)
- Les ORM posent problème dans tous les langages et dans toutes les implémentations. Mieux vaut simplement écrire soi-même le SQL
- Le problème du functional programming vient souvent de ses adeptes
- Si l’on attend assez longtemps, on finit par énormément regretter d’avoir construit un système sur des serverless functions
- Les types sont des assertions que nous faisons sur le monde
- Les verrous distribués restent un problème extrêmement difficile
- La modélisation formelle et la capacité d’analyse sont des compétences indispensables
- La propriété la plus importante dans une suite de tests d’intégration est l’isolation
- DynamoDB peut aussi être le pire choix possible pour le développement d’applications généralistes
- La plupart des gens ne se soucient pas tant que ça de l’« artisanat du code ». Il faut apprécier ceux qui s’y intéressent, tout en collaborant avec les autres là où ils en sont
- Je pense que les langages gradual et dependently typed représentent l’avenir
- Je suis convaincu qu’on ne met jamais trop de commentaires dans le code de test
Opinions inchangées
- Je continue de penser que les gens qui s’obsèdent sur des détails mineurs comme le style de code ou les règles de linting sont des profils un peu étranges. Il faut se concentrer sur des choses plus importantes
- Je maintiens que la code coverage n’a aucun lien avec la qualité du code (et qu’elle lui est même souvent inversement corrélée)
- Je considère toujours que le monolithe est un bon choix
- Je reconnais qu’il est difficile de surpasser des décennies de recherche et d’amélioration accumulées dans les SGBDR
- Il faut une raison légitime pour adopter des micro-services (je trouve regrettable que cela tende de plus en plus à aller de soi aujourd’hui)
- La plupart des projets (y compris en interne chez AWS) n’ont en réalité pas besoin de « scaler », et concevoir d’emblée pour le scaling fait souvent plus de mal que de bien
- Je pense que 93 %, voire 95,2 %, des chefs de projet pourraient disparaître sans grand effet, voire avec un gain d’efficacité (le pourcentage a augmenté depuis il y a 4 ans)
- Je verrai bien ce qui aura encore changé à la quinzième année
20 commentaires
La plupart des propos résonnent.
La plupart des projets n’atteignent jamais le moment où le passage à l’échelle devient nécessaire, ou disparaissent avant que cela ne le devienne...
Que sont les langages à typage dépendant progressif.. ?
D’après ce que j’ai glané dans un podcast, il s’agit apparemment d’un système de types où les valeurs influencent les types. Vu que l’auteur de l’article mentionne les langages fonctionnels, c’est probablement bien de ça qu’il s’agit. Comme c’est quelque chose qui est recherché et développé du côté des langages fonctionnels…
Par exemple, pour le type
List… si les valeurs sont toutes triées, cela devient uneSortedList….Avec ce genre de propriété, la vérification de types peut sans doute prouver davantage de choses à la compilation.
Si une fonction prend une
SortedListet renvoie uneSortedList… mais que le code contient un bug et casse l’état trié, alors on obtiendra une erreur de type à la compilation.Évidemment… le coût de cette vérification de types doit être assez élevé…
Je n’ai absolument aucune idée du niveau de maturité pratique que ça a atteint.
Ah, merci. Ça semble étonnamment fascinant...
Il s’agit, dit-on, de langages que l’on peut appliquer de manière flexible en naviguant entre typage statique et dynamique.
Java est un excellent langage précisément parce qu’il est ennuyeux
Qu’est-ce que cela veut dire ?
Peu importe qui le code, le résultat se ressemble, donc j’imagine que ça facilite la maintenance, quelque chose comme ça.
Je pense que cela voulait peut-être dire qu’il n’y avait rien qui mérite une attention particulière ni quoi que ce soit susceptible de surprendre les développeurs, et que c’est justement ce qui lui donne une impression de stabilité.
Pour tout ce qui touche au style du code ou au linting, une bonne partie peut être réglée avec des outils ; à l’inverse, quand je rencontre des gens qui n’y prêtent pas attention, ça me donne peu envie de travailler avec eux.
Je suis d’accord. J’ajoute des vérifications de style dans la CI afin d’empêcher toute fusion si le style n’est pas respecté.
> Je pense toujours que les gens qui s’obsèdent sur des questions mineures comme le style du code ou les règles de linting sont d’un genre un peu étrange. Il faut se concentrer sur des choses plus importantes.
https://www.youtube.com/watch?v=JcY35HD77lg&t=828s
Mais il y a aussi l’idée qu’il ne faut pas simplement laisser passer cela, car ce sont des éléments qui, en tant qu’humains, rendent la concentration plus difficile ; mieux vaut donc les régler avant d’avancer.
> La plupart des gens ne s’intéressent pas vraiment à l’« artisanat » du code. Il faut accorder de la valeur à ceux qui s’y intéressent, mais avec tous les autres, il faut collaborer là où ils en sont.
Tellement vrai..
Je suis l’une des personnes qui regrettent d’avoir construit un système sur du serverless.
Les cold starts restent lents,
et à un moment, le trafic a explosé au point qu’il n’y a pratiquement plus de différence avec l’on-demand,
et même en mobilisant tous les moyens possibles, les déploiements sont beaucoup trop lents.
La couverture de code n’a rien à voir avec la qualité du code dans deux cas, je pense :
À mon avis, le code de test ne prend vraiment son sens que lorsqu’il combine une couverture élevée et divers scénarios susceptibles de provoquer des erreurs, en testant plusieurs fois la même partie avec des entrées différentes.
Cette dernière interprétation me parle davantage. Un chiffre élevé de couverture de code n’est pas directement synonyme de qualité du code ; l’important est de le remplir avec des cas de test pertinents.
> Java est un excellent langage précisément parce qu'il est ennuyeux
C'est assez drôle, haha
Je suis d’accord.
Sujets liés au développement logiciel sur lesquels j’ai changé d’avis après 6 ans dans le secteur
Commentaire Hacker News