Assistant de conception logicielle

"Build software faster", "55% faster coding", "Generate new code faster than the speed of thought"

Quand les vendeurs d'IA générative veulent vous aider à mieux coder, la vitesse reste leur argument numéro un.

La qualité du code est parfois mise en avant mais la promesse d'un logiciel globalement mieux conçu beaucoup moins.

Et pourtant, il y a déjà de quoi faire.

Reprenons ce code mis en avant par l'un des vendeurs

 1onStream={async (stream) => {
 2    return await props.onReturn(
 3      (async function* () {
 4        let buffer = ""
 5        let state: "outside" | "newline" = "outside"
 6        for await (const datum of stream) {
 7          const newToken = datum.content;
 8          for (const char of newToken) {
 9            buffer += char;
10            if (char === "`" && state !== "newline") {
11              if (state === "outside") {
12                state = "newline";
13              }
14              buffer = ""
15            } else if (state === "newline") {
16              buffer = ""
17            }
18          }
19        }
20      })()
21    );
22  }}
23/>

Avant même de demander à un assistant de rajouter du code, on devrait se poser la question de son état présent.

Si je demande à l'IA "comment améliorer la qualité de ce code ?", je vais tomber sur des propositions assez fades (décomposer en fonctions, ajouter des commentaires, optimiser les performances...) ou sur des ajustements très ciblés qui ne sont pas ma priorité.

Non, avec une IA, il faut être plus directif et avoir une idée précise ce ce que l'on veut comme qualité de code.

Par exemple, si je demande1

Analyse ce code en considérant les principes SOLID.
Donne une réponse très courte qui ne contient que les suggestions pour lesquelles les principes sont TRES pertinents.
Il se peut qu'aucun d'entre eux ne le soit.

Là, je commence à avoir des trucs plus intéressants

  • Single Responsibility Principle (SRP) : La fonction onStream gère à la fois la lecture du flux et la manipulation des données. Séparer ces responsabilités en deux fonctions distinctes.
  • Open/Closed Principle (OCP) : La logique de traitement des données (buffer et state) est codée en dur. Utiliser des stratégies ou des classes pour étendre le comportement sans modifier le code existant.

Et je peux enchainer

Propose une amélioration pour le SRP

 1const processStream = async function* (stream) {
 2  let buffer = "";
 3  let state: "outside" | "newline" = "outside";
 4  for await (const datum of stream) {
 5    const newToken = datum.content;
 6    for (const char of newToken) {
 7      buffer += char;
 8      if (char === "`" && state !== "newline") {
 9        if (state === "outside") {
10          state = "newline";
11        }
12        buffer = "";
13      } else if (state === "newline") {
14        buffer = "";
15      }
16    }
17  }
18};
19
20onStream={async (stream) => {
21  return await props.onReturn(processStream(stream));
22}}

Ça tombe bien : c'est exactement la première chose que j'aurais faite en découvrant ce code tout pourri 💩.

Bon, évidemment, je n'avais pas besoin d'une IA pour ça. Un simple refactoring "Extraction de fonction" proposé par l'IDE aurait suffit mais il fallait y penser.

Cette séparation des responsabilités nous ouvre plusieurs portes...
...que l'on explorera une autre fois.


  1. J'ai demandé à DeepSeek ↩︎

Une réaction ? Un commentaire ? Rejoignez la discussion.   linkedin   bluesky   twitter