Les bonnes habitudes de développeurs à appliquer dans sa vie quotidienne

Le métier de développeur a cela de singulier qu'il consiste principalement à transformer de simples lignes de textes frappées sur un clavier en programmes qui font fonctionner logiciels, machines, et sites Internet dans le monde entier.

Comme tous les métiers, il possède son lot de bonnes pratiques qui permettent de travailler plus vite et plus efficacement, mais avec des méthodes plutôt avancées, ceci étant en grande partie lié à la maîtrise des outils informatiques (à mon humble avis).

A se demander s'il n'y aurait pas de bonnes idées à reprendre ailleurs, voire à essayer de transposer dans sa vie de tous les jours...

Je suis justement tombé récemment sur cet article en anglais sur Medium, qui m'a donné envie de creuser le sujet. Voici donc ma version revue et complétée.

Test

photo flickr / Lachlan Hardy

Rien ne sert d'écrire du code s'il ne fonctionne pas, une étape essentielle du travail du développeur est donc de passer en revue son code pour s'assurer que tout fonctionne.

On parle donc souvent dans le monde du développement de concepts barbares tels que les "tests unitaires" (on teste une partie de code indépendamment) et les "tests fonctionnels" (on teste un dispositif complet).

Ne serait-ce pas une bonne idée que d'appliquer cette précaution dans nos vies de tous les jours ?

Quelques idées ?

- essayer de passer quelques nuits dans le quartier où l'on veut emménager pour se rendre compte de l'ambiance et / ou du niveau de bruit,

- se faire vraiment un avis en essayant d'emprunter le smartphone / l'appareil photo / la voiture... d'un ami avant d'acheter le même,

- vérifier que le tuyau d'évacuation n'est pas bouché avant de brancher sa machine à laver (ça sent le vécu),

- tester la peinture sur un endroit peu visible de son meuble ou de son parquet avant de le repeindre en entier (ça aussi),

- etc...

Si tester son code permet à un développeur de s'assurer que tout se passera bien en production, tester nos actions à petite échelle avant de les enclencher réellement peut sans doute nous permettre d'éviter aussi quelques soucis.

Debug

photo flickr / Michael Mol

Lorsque le code créé ne fonctionne pas comme il devrait, le développeur procède à une phase de "debug", qui consiste à reprendre son code étape par étape, pour examiner ce qui se produit, tenter de comprendre pourquoi, trouver les problèmes et prendre des mesures pour les corriger.

Une procédure qui peut s'avérer très utile au quotidien !

Prenons un exemple qui parlera sans doute à beaucoup : j'ai du mal à tenir mon bureau en ordre et il ressemble vite à un amas de papiers et d'objets hétéroclites (que celui qui se reconnaît lève la main).

Je peux commencer par décomposer les étapes qui me conduisent à tout poser sur le bureau. Par exemple :

- lorsque je reçois quelque chose, je ne sais généralement pas où le poser, ou je n'y réfléchis pas, alors je fais une pile dans un coin du bureau,

- si je reçois autre chose qui n'est pas en rapport avec le précédent, je créé une nouvelle pile,

- au final l'espace du bureau se remplit vite, et je reporte sans cesse le moment de m'occuper du rangement, étant donnée la montagne qui m'attend.

Dans cet exemple, on peut détecter au moins deux bugs à l'origine du problème, et imaginer des solutions :

- visiblement je n'ai pas un endroit pour ranger facilement chaque chose. Je peux alors revoir mon système de classement,

- je ne prends pas de temps pour m'atteler régulièrement au tri, et me trouve toujours découragé face à la masse de choses à ranger. Je peux essayer de prévoir des séances plus courtes mais plus fréquentes (5 minutes à la fin de chaque journée, 15mn en fin de semaine...)

Le principe est simple : détecter les bugs, comprendre pourquoi ils se produisent, trouver des solutions pour les corriger.

Profiling

photo pixabay

Pour améliorer le temps d'exécution d'une application, les développeurs font ce qu'on appelle du "profiling" ou "profilage de code", qui consiste à décomposer toutes ses fonctions pour les analyser, et tenter de détecter les "goulots d'étranglements" qui freinent les performances globales.

On retrouve alors un peu l'esprit du debug expliqué au point précédent, axé cette fois sur l'objectif de réduire le temps d'exécution des tâches.

A bien y réfléchir, il y a sans doute aussi des goulots d'étranglements dans notre organisation quotidienne qui freinent considérablement notre productivité, ou nous privent d'une partie de notre temps libre.

Pourquoi alors ne pas tenter de "profiler" ce qui ne fonctionne pas bien ? On peut imaginer analyser heure par heure la composition d'une journée type, puis essayer de trouver ce qui consomme beaucoup trop de temps, et chercher ce qui pourrait le réduire.

Quelques exemples :

- si mon temps de transport domicile - travail est une contrainte importante dans l'organisation de mes journées, il est peut-être envisageable de se poser quelques questions : puis-je changer de mode de transport ? prendre mon vélo pour combiner transport et remise en forme ? trouver une occupation utile dans les transports en commun ? ou à l'extrême déménager ?...

- si mes tâches ménagères sont un fardeau autant en terme de contrainte que de temps, il n'est peut-être pas idiot de retarder l'achat de ma nouvelle console de jeu pour investir d'abord dans des appareils pouvant me faciliter la vie (lave-vaisselle...),

- si je me laisse trop souvent entraîné par l'appel des réseaux sociaux, ou de toute autre source de distraction sur le web, je peux commencer par relire ces quelques conseils pour retrouver le calme et la concentration face à mon PC, ou pour décrocher de Facebook et cie.

(et coreight.com reçoit l'oscar du placement de ses anciens articles, félicitations)

Versioning

image git

Le versioning ou gestion de version est un outil indispensable des développeurs, qui consiste à conserver en permanence l'historique des fichiers sur lesquels ils travaillent. Cela leur permettant de revenir facilement en arrière en cas de problème.

Ces outils permettent en outre de travailler en équipe sur le même projet, de créer des versions différentes pour les mêmes fichiers... et autres joyeusetés dont je vous épargnerai les détails.

C'est je pense quelque chose que nous devrions tous penser à utiliser.

Rien que dans l'usage quotidien de nos outils informatiques : personnellement lorsque je dois éditer un document (traitement de texte, tableur...) important, je copie généralement le fichier d'origine pour le glisser dans un dossier "V1", ou "OLD". Je peux ainsi faire toutes les modifications sur le fichier dupliqué sans risque.

Le mieux est encore d'utiliser les fonctions de gestion de versions que certains logiciels embarquent... à condition de savoir s'en servir.

Dans la vie de tous les jours, j'imagine qu'il peut être utile également de "capturer" certains éléments à un instant précis avant de faire des changements, pour s'en souvenir et être capable d'y revenir si besoin :

- prendre des photos avant de refaire toute la déco du salon, au cas où on se rende finalement compte que c'était mieux avant,

- garder une copie de l'historique de ses documents importants, pour être capable de retrouver des informations,

-etc,...

Frameworks

photo : capture symfony book

La notion de framework est peut-être un peu plus obscure pour le commun des mortels : cela désigne simplement un ensemble cohérent de code qui peut servir de fondation pour la réalisation de logiciels et applications, sans que le développeur n'ait besoin de réinventer la roue à chaque fois.

Prenons l'exemple de la construction d'un site web évolué : on aimerait le coder sans avoir recours à un CMS comme Wordpress ou Drupal, mais il n'est cependant pas forcément utile de construire totalement de zéro tout ce qui va gérer la sécurité du site, la gestion des URL, l'authentification des utilisateurs,... Les frameworks sont là pour ça !

Je pense qu'il peut être extrêmement utile d'imaginer ce même type de structure pour tout type de travail, ou même pour des éléments de sa vie de tous les jours. Cela revient  à imaginer un cadre, une méthode de fonctionnement que l'on sait efficace, que l'on a testé, et que l'on va réutiliser. On peut alors très bien construire son propre "framework", ou aller chercher l'inspiration chez les autres.

J'ai par exemple exposé ici il y a quelques temps ma méthode pour acheter mes appareils high-tech. Peu importe le produit, j'utilise globalement toujours la même routine et les mêmes outils lorsque je dois ouvrir le porte-monnaie pour un achat important, ce qui je pense me fait gagner du temps et de l'argent.

Il s'agit simplement d'avoir une méthode, un cadre, et un ensemble d'outils réutilisables.

Factoriser

photo flickr / Julian Partridge

Les développeurs ont une sainte horreur de se répéter, et l'une des meilleures pratiques consiste à essayer de ne jamais écrire deux fois le même code, mais de réutiliser au maximum ce qui existe déjà.

Ils isolent ainsi des portions de code dans des fonctions ou des classes réutilisables ailleurs. Cela leur permet d'une part de gagner du temps, mais surtout de rendre leur code beaucoup plus clair et facile à maintenir : une même fonction copiée-collée à plusieurs endroits obligeant fatalement à corriger chaque instance en cas de bug, avec le risque d'erreur que cela engendre.

Mais comment envisager un "refactoring" de certaines de ses actions quotidiennes ? Je pense que cela peut s'envisager dans une approche d'automatisation de certaines de ses tâches : au lieu de répéter plusieurs fois la même action dans le temps, il est sans doute possible de chercher une solution pour qu'elle s'exécute d'elle même :

- plutôt que de répéter chaque fin de semaine la copie à la main de ses fichiers vers un serveur de sauvegarde, mettre en place un système de sauvegarde automatique,

- utiliser des outils comme IFTTT pour connecter certains services web entre eux et leur faire exécuter automatiquement certaines actions répétitives (poster sur les réseaux sociaux, sauvegarder des choses importantes, recevoir des alertes...)

Si la répétition est utile dans certains domaines, notamment l'enseignement et l'apprentissage, "factoriser" certaines de ses actions peut s'avérer être un gain de temps précieux.

Commentaires et documentation

image inspiration : stackoverflow

C'est un point que l'on met souvent en avant pour distinguer un "bon" code d'un autre : les explications qui sont fournies avec, sous forme de commentaires directement au sein du code. On peut placer également dans cette section les éventuelles documentations qui peuvent accompagner une application.

Le code d'un bon développeur est généralement suffisamment clair pour que l'on comprenne comment il marche, les commentaires viennent expliquer pourquoi il est construit ainsi.

C'est extrêmement important pour que les autres codeurs qui reprendront le projet puissent le comprendre rapidement. Sans compter qu'un même développeur ne saura plus forcément ce qu'il a fait en revenant dessus plusieurs mois, voire plusieurs années plus tard.

Est-il possible d'appliquer cette idée dans la vie de tous les jours ? Bien sûr !

Pour tous les projets nécessitant des opérations délicates, des actions précises... il me semble important de garder une trace quelque part de la procédure que l'on a suivi pour la mise en place.

- je pense par exemple à la prise de notes ou de photos lorsque l'on démonte un objet que l'on souhaite réparer (mon expérience ici pour la réparation d'un écran LCD),

- lorsque l'on a un quelconque conflit à résoudre (service après-vente, procédure juridique...), consigner soigneusement toutes les actions effectuées, les dates et heures, mais aussi tout le cheminement nous ayant amené à les effectuer.

Commenter et documenter ces actions permettra non seulement de se souvenir de tout mais aussi de se rappeler pourquoi nous avons agi ainsi.

Open Source

photo flickr / opensource.com

Nous utilisons tous des logiciels libres ou "open source" sans forcément en avoir conscience ; ce sont ces logiciels dont le code est ouvert à tous, généralement développés par une communauté plutôt que par une entreprise seule.

C'est une pratique très commune dans le monde des développeurs, de partager tout ou partie de son travail, et de profiter en retour de celui des autres.

C'est une excellente façon de s'améliorer en profitant des retours des autres, d'écrire du code plus clair et plus efficace, et pourquoi pas d'inspirer d'autres.

Et si nous imaginions de cultiver cette bonne pratique dans d'autres domaines ?

Nous sommes tous amenés régulièrement à corriger des problèmes, réparer des choses cassées, résoudre des conflits... et pour cela nous devons parfois faire des recherches, faire preuve d'imagination, ou de créativité...

Pourquoi ne pas partager ces efforts avec notre entourage ? Ils pourront apprendre de notre expérience, nous donner d'éventuels conseils et astuces, et seront inciter à partager à leur tour leur savoir.

Blog, réseaux sociaux, les outils numériques ne manquent pas aujourd'hui pour partager facilement nos connaissances avec nos proches, voire un public plus large.

Pour ma part c'est aussi pour ça que j'ai lancé ce blog !

 

J'espère que cet article basé sur quelques bonnes pratiques de développeurs vous aura donné quelques idées.

Que tous les barbus présents dans l'assemblée n'hésite pas à compléter avec leurs idées ;-)

Allez, je vous laisse pour aujourd'hui, j'ai du code à débugger.