Après 6 ans dans l’industrie, des sujets sur le développement logiciel sur lesquels j’ai changé d’avis
(chriskiehl.com)Ce qui m’a fait changer d’avis : des choses contre lesquelles je me battais avant, mais auxquelles je crois désormais
- Dans des équipes composées de personnes aux niveaux d’expérience variés, les langages typés sont préférables
- Les stand-up meetings sont utiles pour garder un œil sur les nouveaux arrivants
- Les rétrospectives de sprint ont des aspects utiles et d’autres qui le sont moins (quand l’agile coach / scrum master fait perdre son temps à tout le monde)
- L’architecture logicielle est plus importante que tout le reste. Une mauvaise implémentation d’une bonne abstraction n’abîme pas une base de code. Ce sont les mauvaises abstractions ou les couches manquantes qui dégradent tout
- Java n’est pas un si mauvais langage
- Le code trop malin n’est généralement pas du bon code. La clarté passe avant tout
- On peut écrire du mauvais code dans n’importe quel paradigme
- Les « best practices » dépendent du contexte et ne s’appliquent pas à tout. Les suivre aveuglément vous rend idiot
- Concevoir un système scalable sans en avoir besoin fait de vous un mauvais ingénieur
- L’analyse statique est utile
- DRY n’est pas une fin en soi, mais un moyen d’éviter certains problèmes
- En général, RDBMS > NoSQL
- La programmation fonctionnelle n’est pas un remède miracle, juste un autre outil
Avis retenus au passage :
- YAGNI > SOLID > DRY : dans cet ordre
→ You Aren't Gonna Need It : un des principes de l’XP
→ SOLID : les 5 grands principes de la conception orientée objet
Single Responsibility
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
→ DRY : Don't Repeat Yourself - Le crayon et le papier sont d’excellents outils de programmation, trop peu utilisés
- Sacrifier la pureté au profit du pragmatisme est généralement un bon choix
- Ajouter davantage de technologies n’est pas une bonne décision
- Parler directement aux clients permet de mieux comprendre le problème, plus précisément et en moins de temps
- Le mot « scalable » a un pouvoir mystique et stupéfiant sur l’esprit des ingénieurs logiciel. Le simple fait de le murmurer suffit à les faire sombrer dans une frénésie corrompue. Son usage sert à justifier des actes impitoyables
- Malgré le fait qu’on les appelle des « ingénieurs », la plupart des décisions relèvent du cargo cult, sans analyse, données ou chiffres pour les étayer
→ Cargo cult : pratique consistant à attendre qu’une personne techniquement plus avancée (une société / des ancêtres) apporte par bateau ou par avion une cargaison spéciale - 90 %, peut-être 93 %, des chefs de projet pourraient disparaître dès demain sans gain ni perte en termes d’efficacité ou d’efficience
- Après 100 entretiens, je suis arrivé à la conclusion que la manière d’interviewer est complètement cassée. Et je ne sais toujours pas comment l’améliorer
Anciens avis qui n’ont pas changé :
- Les gens qui insistent sur le style de code, les règles de linting et autres détails mineurs sont des cinglés
- La couverture de code n’a absolument rien à voir avec la qualité du code
- Les monolithes sont plutôt très bien dans la plupart des situations
- Les puristes du TDD sont les pires. Leur petit esprit fragile est incapable d’accepter qu’il existe d’autres workflows
- Je regarderai ce qui aura encore changé ou s’est inversé quand j’aurai 10 ans d’expérience
9 commentaires
Chaque phrase parle vraiment. J’ai l’impression qu’on passe d’un idéalisme où tout pourrait être parfait à une approche plus pragmatique.
Une fois qu’on comprend l’importance du TDD, à partir de ce moment-là, on est programmeur ...
On continue de voir passer des avis disant que les entretiens d’embauche sont cassés. Moi-même, si on me demandait de passer un test de code, je ne serais pas très confiant(...).
J’ai aussi trouvé ce texte. Il s’agirait d’un passage du livre « HARD CODE ».
https://johngrib.github.io/wiki/better-interview/
Seulement 6 ans pour arriver à ces conclusions ? Hahaha, impressionnant.
Au bout de 6 ans, vous avez donc eu une illumination et êtes devenu Bouddha !
Sur Hacker News, d'autres développeurs et des ingénieurs avec plus de 20 ans d'expérience sont aussi intervenus pour ajouter des commentaires.
https://news.ycombinator.com/item?id=25887373
Dès le premier commentaire, ça tape fort haha. Si on examine chaque point un par un, il y aura sans doute aussi des situations exceptionnelles, mais il semble dangereux de vouer un culte aveugle à quoi que ce soit.
Comme pas mal de bugs peuvent être résolus rien qu’avec la vérification de types, c’est sans doute un sujet qui reviendra sans cesse. Et les méthodes pour gérer les types de façon sûre continuent elles aussi de s’améliorer.
(Mais TypeScript est quand même un peu difficile T_T.)