Boostez votre productivité

Il y a un certain nombre de choses en code qui vous permettent de booster votre productivité.

Toutes peuvent paraître évidentes mais tous les développeurs ne mettent pas en place ces méthodes.

Organiser sa To-Do

A chaque fois que vous avez une tâche à effectuer, essayez de procéder par étapes:

Posez vous la question:

Est-ce que j'ai déjà fait ça avant ?

✅ Si la réponse est "oui":

• Comment avez-vous fait ?
• Est-ce que vous avez synthétisé cela quelque part ?
• Est-ce que vous en avez fait un outil ?
• L'avez vous mis sur un repo Git ?

Dans l'idée, on cherche à gagner du temps et à optimiser le moindre mouvement.

Je vais vous rappeler une règle de base:

On réfléchit d'abord à comment on peut procéder, et seulement après, on agit.

Foncer tête baissée, c'est le meilleur moyen d'être inefficace.

Essayez de récupérer le maximum d'éléments de comment vous avez procédé la dernière fois.

Si vous n'avez plus rien, le constat est sans appel: vous n'avez pas procédé stratégiquement et intelligemment.

C'est un sérieux problème et il va falloir corriger ça si vous voulez vous améliorer.

❌ Si la réponse est "non":

Il s'agit d'une nouvelle tâche, vous n'avez jamais fait cela avant.

Il est donc temps d'apprendre quelque chose, de se nourrir de cette expérience et d'en sortir grandit.

Posez vous la question ?

Comment je vais faire pour régler ce problème maintenant, et aussi à l'avenir.

Je sais que beaucoup de gens ne se posent pas de question quand ils ont une tâche et veulent systématiquement commencer à coder.

Le problème, c'est que lorsque vous appliquez le proverbe: "A force de trop analyser vous finissez paralysé" vous confondez votre organisation et l'analyse.

Organiser comment vous allez réglez un problème, n'est pas une analyse, mais pour moi, il s'agit bien d'une action.

Oui, vous êtes déjà dans l'action, mais à la différence, vous ne codez pas, vous essayez d'optimiser le chemin avant de coder.

L'objectif est de sortir de cette étape avec un plan clair, une vision du chemin et surtout un outil réutilisable à l'infini.

Beaucoup de gens aiment sauter cette étape, mais au bout de 5 projets, le seul outil qu'ils ont quand ils doivent résoudre une problématique connue, c'est leur mémoire.

Je ne dis pas que c'est un mauvais outil, mais ce n'est clairement pas l'outil le plus optimal.

A votre avis, entre un professionnel qui doit avoir un niveau de concentration maximal pour se souvenir de tout, et celui qui se concentre sur sa réalisation et se fie à ses outils pour le reste, lequel est le plus productif à terme ?

Les outils

Lorsque je me lance dans un projet, j'aime savoir que je fais les choses une fois, non seulement à l'échelle du projet, mais aussi pour les prochains projets similaires à venir.

Cela passe par la mise en place d'outils qui vont couvrir les besoins présents et futurs:

• Le TDD pour savoir que ce que je fais fonctionne, ne casse pas et me permettre de passer à la fonctionnalité suivante
• La documentation pour me permettre de retrouver facilement le chemin que j'ai emprunté et éviter les pièges que j'ai rencontré
• Je documente souvent en Markdown au sein de mes repo, j'utilise également les outils de prise de note et ce même blog sert de documentation sur ce que j'expérimente
• La mise en place d'outils pour gérer les cas répétitifs

De quels outils je parle, et quels sont les cas répétitifs ?

Je suis prêt à parier que vous aussi, dans vos projets vous arrivez à une étape où vous devez faire et refaire souvent la même chose:

• Créer des pages (elles ont souvent une structure similaire à 80%)
• Créer des formulaires (comme pour les pages, se ressemblent souvent)
• Gérer les traductions

Donc pour gérer cela, j'aime bien créer ou utiliser des outils qui vont me permettre:

• soit de ne faire les choses qu'une seule fois
• soit d'optimiser au maximum ces actions afin de gagner du temps

Et pour mettre en place cela j'utilise des outils.

Gestion automatique de la traduction

Lorsque je traduis une application, je ne le fais qu'une seule fois et en français.

Pour le reste, j'utilise des scripts avec Ollama pour faire la traduction.

Je vais fournir à Ollama un schema pour m'assurer que la réponse du LLM soit au format JSON attendu par ma librairie i18next à savoir:

{
    "translation": { ... } 
}

Et tout cela en local, sans payer d'API ou autre...

Regardez ce script:

// Install on your computer Ollama first
// url: https://ollama.ai/
// Then pull mistral model: ollama pull mistral:latest
import ollama from "ollama";
import { fr } from "../imports/locales/fr";
import fs from "fs";
import path from "path";

const enPath = path.join(__dirname, "../imports/locales/en.ts");

const translationSchema = {
  type: "object",
  properties: {
    translation: {
      type: "object",
      additionalProperties: {
        oneOf: [
          { type: "string" },
          {
            type: "object",
            additionalProperties: {
              oneOf: [
                { type: "string" },
                { type: "object", additionalProperties: true },
              ],
            },
          },
        ],
      },
    },
  },
  required: ["translation"],
};

(async () => {
  const response = await ollama.chat({
    model: "mistral:latest",
    messages: [
      {
        role: "user",
        content:
          "Peux-tu me traduire ce bloc suivant en anglais pour une plateforme de mise en relation petit job tech: " +
          JSON.stringify(fr),
      },
    ],
    format: translationSchema,
  });

  const en = response.message.content;

  fs.writeFileSync(
    enPath,
    `export const en = ${JSON.stringify(JSON.parse(en), null, 2)}`
  );
})();

Et de cette façon, je ne travaille qu'une fois et je laisse Mistral gérer la traduction pour moi. Je peux même mettre un watcher sur le fichier fr.ts pour déclencher automatiquement la traduction dans les autres langages.

Lorsque j'appelle ce script, il va générer automatiquement le fichier en.ts pour moi.

Gestion des contenus répétitifs (pages, formulaires, etc.)

Pour générer automatiquement ces contenus pour moi, j'essaye de savoir quel sont les parties communes de mes composants.

Par exemple, une page a besoin:

• du header
• des imports par défaut
• d'un footer

Ok, maintenant que je sais quoi récupérer, je vais utiliser une librairie NPM qui s'appelle Hygen. Je vous laisse regarder leur page npm .

Pour utiliser Hygen, il faut créer un répertoire _template à la racine de votre projet, et dans ce même répertoire on va créer les fichiers suivants:

apps/frontend/_templates/
└── page
    └── new
        ├── page.ejs.t
        └── prompt.js

Je vais vous montrer un exemple de template que j'utilise pour mon projet:

// page.ejs.t
---
to: /pages/<%= h.changeCase.pascal(name) %>Page.tsx
---
import React from 'react';
import { Header } from '/components/view/header'
import { Footer } from '/components/view/footer'

export const <%= h.changeCase.pascal(name) %>Page = () => {
  return (
    <div className="min-h-screen flex flex-col bg-gradient-to-br from-yellow-50 to-purple-50 pt-16">
      <Header />

      {/* Contenu de votre page */}

      <Footer />
    </div>
  );
};

Puis un, on crée un fichier prompt.js:

// prompt.js
module.exports = [
  {
    type: 'input',
    name: 'name',
    message: 'Nom de la page (sans le suffixe "Page")'
  }
]

Avec cet outil, c'est un jeu d'enfant de générer des pages:

Vous pouvez désormais faire de même pour vos structures de formulaires qui se répètent.

D'ailleurs, React est un outil parfait pour gérer la répétitivité.

Vous pouvez faire vos composants (les inputs, lex textareas, les selects) et faire en sorte que vos formulaires utilisent ces mêmes composants afin de factoriser au maximum vos efforts.

Visualiser les workflows

Quand je passe d'un projet à l'autre, il me faut des outils qui me permettent de me remettre dans le bain rapidement.

J'aime bien être capable de visualiser mon code sous forme de Workflow, comprendre quelle brique interagit avec l'autre, dans quel ordre etc.

Pour faire cela, j'utilise tout simplement un fichier Markdown dans mon repo, que j'appelle [ProcessName]-workflow.md et via la synthax Mermaid, j'essaie de faire un chart de ce Workflow.

Voici un exemple, j'ajoute ces lignes à mon fichier Markdown, dans un bloc code de type mermaid:

graph TD
  A[UI Web View] --> B[Form Submission]
  B -- useWriteModelName --> C[Hook]
  C -- frontend --> D[Meteor.call]
  D -- backend --> E[Meteor.methods backend]
  E --> F[ACL Check]
  F -->|OK| G[Write to DB]
  F -->|KO| H[Throw Error]

Ensuite quand je fais CTRL + SHIFT + V sous linux ou encore CMD + SHIFT + V sous mac depuis ce document Markdown dans mon éditeur Cursor:

L'objectif est de me souvenir rapidement, en visualisant le flow, qu'est-ce qui se passe sur ce projet.

Conclusion

Il y a beaucoup d'outils qui permettent d'accélérer et d'améliorer notre Dev XP au quotidien. Ceux que je vous ai cité ici sont des exemples parmi tant d'autres, vous pouvez encore pousser le concept au optimisant encore plus ce que vous faîtes sur vos projets.

Pourquoi je m'embête autant au lieu de juste implémenter ?

Parce que je pars du principe que coder pour coder, ça ne va pas vous faire prendre de l'expérience mais juste vous faire gagner comme des réflexes, travailler votre mémoire musculaire.

Maintenant, si vous voulez que votre expérience elle-même soit un outil pour vous aider à devenir un meilleur développeur, il faut mettre en place des habitudes saines qui vont vous faire grandir en tant que développeur.

La documentation de process vous permet de garder le bon, de savoir ce qui ne marche pas, de comparer, d'apprendre et d'évoluer.

Je ne suis pas rentré dans les détails du TDD dans cet article, car il y a trop de choses à dire sur ce sujet. De même, j'espère que vous êtes suffisamment conscient de cette approche. Je sais que beaucoup de devs pensent que de faire des tests c'est de la perte de temps et qu'il vaut mieux exécuter et avancer. L'expérience m'a prouvé que souvent, le temps gagné au début sera perdu à la fin du projet, donc ça n'en vaut pas la peine.