Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Eric Meyer décrit une approche très intéressante de l'écriture de web components. À tester
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
En résumé :
- N'en mettez pas plein la vue avec vos titres d'expert UX ou autre
- N'intimidez pas vos utilisateurs : ce n'est pas un entretien d'embauche ni une présentation devant votre patron
- Faites au mieux pour observer vos utilisateurs dans leur "habitat naturel"
- Recueillez le plus de contextes et ne restez pas en surface
- Tout le monde ment (souvent de manière non intentionnelle). Vérifiez systématiquement ce qui est dit
Tout est dans le titre
Tout est dans le titre
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur donne plusieurs règles de son équipe, qui doivent être respectées dans le code (utilisation d'exceptions, DTO, etc.) Elles méritent d'être connues
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique la nécessité de connaître les principes orientés objet et autres bonnes pratiques (clean code, tests, refactoring, etc.)
L'article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur présente 3 exemples d'arbitrage qu'il a du faire pour résoudre des problèmes : cette nécessité de choisir est constante dans le développement, et il donne quelques bons conseils à ce sujet.
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur donne quelques heuristiques pour choisir les parties du code à refactorer, en fonction de leur valeur business et de leur fréquence de changement
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur insiste sur le fait que le refactoring fait partie du quotidien du développeur : ce n'est pas une tâche de la todo liste mais bien une étape de chaque item de celle-ci (cf le nettoyage en fin de service dans un restaurant) Si le refactoring est plus important, alors nommer le ticket sur ce qui est refactoré et pas seulement "refactoring"
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique une manière revisitée de la règle du boy scout - toujours laisser le code sur lequel on a travaillé dans un meilleur état que celui dans lequel on l'a trouvé.
Notamment il donne une procédure d'amélioration continue très intéressante.
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique pourquoi il faut se débarrasser des appels statiques (classes difficilement testables unitairement) et comment faire (injection de dépendances)
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur explique l'intérêt d'utiliser un objet pour passer des paramètres à une méthode (DTO). Il montre aussi comment réécrire le code pour passer d'un ensemble de paramètres / d'un tableau associatif à un DTO