Dans votre vie de développeur, quel est le meilleur conseil qu’on vous a donné et qui a le plus changé votre façon de faire ?
Les démos doivent coller au metier. Typiquement, proposer un webdesign avec des images de chats partout, ça le fait pas.
Ne jamais oublier les tests (unitaires ou de non-régression) et leur accorder le temps qu’il faut pour en gagner plus tard !
1 « J'aime »
Tu commences à vieillir le jour ou tu arrêtes d’apprendre.
6 « J'aime »
Surtout qu’avec la pratique, je n’ai pas l’impression de développer plus lentement en écrivant des tests. En effet on passe beaucoup moins de temps à valider manuellement le code qu’on est en train d’écrire. Au final on teste toujours, soit manuellement, soit automatiquement. Mon expérience pseudo-scientifique a été, en tant que sous-traitant, de chiffrer un développement de fonctionalité basé sur le résultat attendu, en accord avec le client qui se trouve être un développeur et qui a une idée de combien de temps ça doit prendre, sans se préocupper de savoir si il y aura des tests ou pas. Au final j’étais dans les temps et j’avais des tests. Écrire des tests en même temps ne m’a pas ralenti. Ce n’est pas forcément vrai dès le départ car tester s’apprend, il faut découvrir les outils de test et apprendre à écrire des tests. Mais avec l’expérience, ça ne ralenti pas le dev.
Je ne sais pas si on gagne tellement de temps par la suite, car les regressions detectées par les tests lors de l’ajout de nouvelles fonctionalités sont finalement assez rares. Ce qu’il y a de chouette avec les tests c’est que ça permet de refactorer. Sans tests on a trop peur de refactorer et le code devient vite très sale. Or du code sale va faire perdre du temps par la suite. Donc oui finalement tu as raison :)
1 « J'aime »
Haha et éviter les saisie “à la con” dans une base de donnée “pour tester”. Ça a de forte chance de ressurgier le jour de la démo. Dans le même ordre d’idée, choisir ses labels et ses intitulés avec le plus grand soin, sans se dire que “le mêtier” les fournira plus tard, car au final ça a de forte chance de finir en production.
Quand tu passes d’un projet sans tests à un projet avec tests, tu perds un peu de temps au départ parce qu’il faut te former à l’écriture et à l’utilisation des tests. Une fois que les bonnes habitudes sont prises, ce n’est plus vraiment un gain de temps mais plutôt l’absence de perte de temps ^^ (dû à des régressions provoquées par du code que tu n’aurais pas vu tout de suite à cause de l’absence de tests)
Je pense la même chose. Ce n’est pas un conseil, vu que c’est tiré de ma propre experience: Dans un dev from scratch, il y a des aller/retour entre le code et les tests. Autrement dit, je trouve difficille la mise en place complète des tests a priori.
« Mieux vaut demander pardon que demander la permission. »
4 « J'aime »
Un client n’est pas un patron. On peut le virer nous aussi
5 « J'aime »
Ne fais jamais jamais jamais confiance a un utilisateur.
Une application pour un utilisateur, cela n’existe pas.
Deux conseils que j’ai tiré de je ne sais plus où concernant les commentaires :
- Don’t comment bad code, rewrite it
- Don’t comment what, comment why
2 « J'aime »
Personnellement, le meilleur conseil que l’on m’ait donné fût de me lancer dans la programmation fonctionnelle statiquement typée (au moyen de Haskell).
Cela a fortement changé ma perception de la programmation et j’ai l’intime conviction que mon code Ruby (le seul langage objet que j’utilise pour des choses concrètes) s’en porte mieux. (Mais ce n’est peut être qu’une impression ;) ).
1 « J'aime »
Ni à tes collègues. Il faut toujours verifier.
Ne pas avoir confiance en tes collègues peut être problématique.
Dans mon cas nous avons un processus de review de code entre collègues pour chaque commit mais cela ne veut pas dire que je ne fais pas confiance en mes collègues.
1 « J'aime »
Quand on communique du savoir, à l’oral notamment, c’est très facile d’omettre des éléments importants ou des détails et ceci parfois sans le vouloir. Ajoute à cela des problèmes complexes, plus le stress et il y est fort certains qu’il y a des trous dans les explications qu’il faut mettre à jour avant de commencer le gros du travail.
Vérifier c’est pas être défiant. La preuve permet de démarrer le travail.
Je m’en souviendrais alors ^^.
“La parole s’envole, l’écrit reste.”
“Cherche encore, tu vas trouver.”
1 « J'aime »
En fait j’ai cogité sur ma formulation, c’est vrai qu’elle n’est pas correct et peux blesser les végétariens. En l’occurrence, ce serait plus correct de dire qu’il faut “toujours faire des tests unitaires”, mais cela ne reflète pas toujours la réalité sur le terrain, d’où le «il faut toujours vérifier [et valider]».
Essai cet outils au pire tu restera jusqu’a 22h. Mdr
( l’importance d’essayer meme si ça ne donne pas le résultat escompté )