Guillaume RICHARD

Blog

  • Écrivez le code comme si vous deviez le supporter pour le reste de votre vie

    Voici une nouvelle règle que je vous propose, tiré du livre 97 Things every programmer should know.
    Aujourd’hui, c’est Yuriy Zubarev qui nous parle de la maintenance du code.

    Vous pouvez demander à 97 personnes ce que chaque programmeur doit savoir et faire et vous pouvez obtenir 97 réponses distinctes. Cela pourrait être à la fois accablant et intimidant. Tous les conseils sont bons, tous les principes sont fondés et toutes les histoires sont convaincantes, mais par où commencer ? Plus important encore, une fois que vous avez commencé, comment suivez-vous toutes les meilleures pratiques que vous avez apprises et comment en faites-vous une partie intégrante de votre pratique de programmation ?

    Je pense que la réponse réside dans votre état d’esprit ou, plus clairement, dans votre attitude. Si vous ne vous souciez pas de vos collègues développeurs, des testeurs, des responsables des ventes et du marketing et des utilisateurs finaux, vous ne serez pas amené à employer un développement piloté par les tests ou à écrire des commentaires clairs dans votre code, par exemple.

    Je pense qu’il existe un moyen simple d’ajuster votre attitude et d’être toujours motivé pour fournir des produits de la meilleure qualité: écrivez un code comme si vous deviez le supporter pour le reste de votre vie.

    C’est tout. Si vous acceptez cette notion, il se passera beaucoup de choses merveilleuses. Si vous deviez accepter que l’un de vos employeurs précédents ou actuels ait le droit de vous appeler au milieu de la nuit pour vous demander d’expliquer les choix que vous avez faits lors de l’écriture de la méthode fooBar, vous deviendriez progressivement un programmeur expert. Vous voudriez naturellement proposer de meilleurs noms de variables et de méthodes. Vous éviteriez des blocs de code comprenant des centaines de lignes. Vous feriez de la veille, à chercher, apprendre et utiliser des modèles de conception.

    Vous pouvez écrire des commentaires, tester votre code et refactoriser continuellement. Soutenir tout le code que vous avez écrit pour le reste de votre vie devrait également être une entreprise évolutive. Vous n’auriez donc d’autre choix que de devenir meilleur, plus intelligent et plus efficace.

    Si vous y réfléchissez, le code que vous avez écrit il y a de nombreuses années influence toujours votre carrière, que cela vous plaise ou non. Vous laissez une trace de vos connaissances, de votre attitude, de votre ténacité, de votre professionnalisme, de votre engagement et de votre plaisir avec chaque méthode, classe et module que vous concevez et écrivez. Les gens vont se faire une opinion sur vous en fonction du code qu’ils voient. Si ces opinions sont constamment négatives, votre carrière vous rapportera moins que vous ne l’espériez. Prenez soin de votre carrière, de vos clients et de vos utilisateurs avec chaque ligne de code. Écrivez du code comme si vous deviez le prendre en charge pour le reste de votre vie.

  • Écrire des tests pour les autres

    Écrire des tests pour les autres

    Cela faisait longtemps que je n’avait pas écrit sur une des règles du livre 97 Things every programmer should know.
    Aujourd’hui, je vais parler de la partie de Gerard Meszaros, sur l’écriture des tests pour les autres personnes travaillant sur le projet.

    Voici ce que nous raconte Gerard Meszaros, en français :

    Vous écrivez des tests automatisés pour tout ou partie de votre code de production. Toutes mes félicitations!
    Vous écrivez vos tests avant d’écrire le code ? Encore mieux !!
    Cela fait de vous l’un des premiers utilisateurs à la pointe de la pratique du génie logiciel.

    Mais écrivez-vous de bons tests ? Comment pouvez-vous le juger ?
    Une solution consiste à demander : Pour qui est-ce que j’écris les tests ?

    Si la réponse est « Pour moi, m’épargner l’effort de corriger les bogues» ou « Pour le compilateur, afin qu’ils puissent être exécutés », alors il y a de fortes chances que vous n’écriviez pas les meilleurs tests possibles.

    Dans ce cas, pour qui devriez-vous écrire les tests ?

    Pour les personnes essayant de comprendre votre code. Les bons tests servent de documentation pour le code qu’ils testent. Ils décrivent le fonctionnement du code. Pour chaque scénario d’utilisation, les tests doivent :

    • Décrire le contexte, le point de départ ou les conditions préalables à satisfaire
    • Illustrer la manière dont le logiciel est appelé
    • Décrire les résultats attendus ou les post-conditions à vérifier

    Différents scénarios d’usages auront des versions légèrement différentes de chacun d’eux. La personne qui essaiera de comprendre votre code doit pouvoir examiner quelques tests et, en comparant ces trois parties, permettre de voir ce qui provoque un comportement différent du logiciel.
    Chaque test doit clairement illustrer la relation de cause à effet entre ces trois parties. Ce qui n’est pas visible dans le test est tout aussi important que ce qui est visible.

    Trop de code dans le test distrait le lecteur avec des anecdotes sans importance. Dans la mesure du possible, cachez ces anecdotes derrière des appels de méthode significatifs: le refactoring est votre meilleur ami.

    Et assurez-vous de donner à chaque test un nom explicite décrivant le scénario d’utilisation en question, afin que le lecteur n’ait pas à désosser chaque test pour comprendre quels sont les différents scénarios.
    Entre eux, les noms de la classe de test et de la méthode de classe doivent inclure au moins le point de départ et la manière dont le logiciel est appelé. Cela permet de vérifier la couverture du test via un balayage rapide des noms de méthodes. Il peut également être utile d’inclure les résultats attendus dans les noms des méthodes de test, à condition que leur nom ne soit pas trop long à afficher ou à lire.

    C’est également une bonne idée de tester vos tests.

    Vous pouvez vérifier qu’ils détectent les erreurs que vous pensez détecter en les insérant dans le code de production (votre propre copie privée que vous allez jeter, bien sûr).
    Assurez-vous qu’ils signalent les erreurs de manière utile et significative.
    Vous devez également vérifier que vos tests parlent clairement à une personne qui tente de comprendre votre code.
    La seule façon de le faire est d’avoir une personne qui ne connaît pas votre code qui lit vos tests et vous dit ce qu’elle a appris.
    Écoutez attentivement ce qu’elle dit. Si elle n’a pas compris quelque chose de clair, ce n’est probablement pas parce qu’elle n’est pas très brillante.
    Il est plus probable que vous n’ayez pas été très clair. (Allez-y et inversez les rôles en lisant ses tests!)

  • Word 2019 : Formation complète

    Word 2019 : Formation complète

    Cette formation de Médiaforma est proposé sur le site Tuto.com.
    Elle traite de Word 2019 depuis la base du logiciel, jusqu’à des concepts un peu plus avancé.
    Elle dure 3h, et coûte 29€.

    C’est une très bonne formation pour les débutants, et pour les personnes voulant connaître des petites fonctionnalités (multi-colonnage, la numérotation des pages, Automatiser les tâches répétitives avec une macro, etc…).

    A voir, ou à revoir pour une petite piqûre de rappelle.

    Une formation = un extrait

    Petite vidéo de la formation présentant le ruban de Word.

    Liens de partenariat

    Lien de la formation : Tuto Word 2019 : Formation complète
    Lien des formations liées à Word.

  • Wordcamp bordeaux 2019

    Wordcamp bordeaux 2019

    Le samedi 23 mars 2019, j’ai eu l’occasion de suivre en direct l’événement suivant : le Wordcamp bordeaux 2019.

    J’ai pu croisé des gens sympathique, avec qui j’ai eu de bonne discussion.
    J’ai suivi des conférences de qualités, dans lesquelles j’ai appris des choses.

    J’ai pu croisé des gens sympathique, avec qui j’ai eu de bonne discussion.
    J’ai suivi des conférences de qualités, dans lesquelles j’ai appris des choses.

    Les conférenciers étaient tous extraordinaire. J’ai passé un très bon Week-end sur Bordeaux.

  • Les Modes SQL

    Les Modes SQL

    Aujourd’hui, je partage avec vous une découverte que j’ai fait dernièrement, qui porte sur les modes SQL.
    Je dis découverte pour le fait que je n’en avais jamais entendu parler jusqu’à il y a quelques jours.
    Voici une définition des modes SQL, issue du site mysql.com, et traduite de l’anglais.

    Le serveur MySQL peut fonctionner dans différents modes SQL et peut appliquer ces modes différemment pour différents clients, en fonction de la valeur de la variable système sql_mode.

    Les administrateurs de base de données peuvent définir le mode SQL global pour correspondre aux exigences opérationnelles du serveur de site. Chaque application peut également définir son mode de session SQL en fonction de ses propres exigences.

    Les modes affectent la syntaxe SQL prise en charge par MySQL et les contrôles de validation des données effectués.

    Cela facilite l’utilisation de MySQL dans différents environnements et l’utilisation de MySQL avec d’autres serveurs de base de données.

    https://dev.mysql.com/

    En clair, les différents mode SQL permettent d’ajouter des règles plus ou strict sur la base de données, et de faire attention aux données qui peuvent être ajouté ou updaté sur cette base.

    Je ne vous expliquerai pas les détails de ce mode SQL, mais il est possible de lire les pages de documentation traitant de ce sujet. Voici quelques liens :