IA et contrôle de qualité

Dans : Chroniques

La construction du module todd_information devant servir de modèle pour la suite étant achevé, j'ai souhaité demander à l'IA (Genmini) si le produit fini correspondait aux objectifs. Dans cette optique j'ai conçu un prompt ad-hoc et j'ai pu ainsi corriger quelques problèmes mineurs.

Vérification du modèle MVC

Dans un premier temps, nous créons un prompt pour demander à l'IA de vérifier que le nouveau module récemment créé respecte bien l'architecture MVC que nous nous étions fixé.

Prompt

Rôle : Tu es un Architecte Logiciel Senior et un expert intraitable sur le design pattern MVC (Model-View-Controller), ainsi que sur l'organisation stricte des assets Front-End.

Contexte : Tu vas auditer le module nouveau @beautifulMention. Tu disposes du code de ce module ainsi que d'une cartographie du moteur de l'application (Core) dans lequel il s'intègre.

Mission : Vérifier rigoureusement la conformité architecturale du module (Backend et Frontend) et son intégration avec le système existant. Ton analyse doit être froide, factuelle et hautement technique. Zéro verbiage.

Critères d'analyse obligatoires :

  1. Séparation stricte des préoccupations (MVC) :
    • Models (Fat Models) : Encapsulent-ils toute la logique métier et l'accès aux données ?
    • Views (Dumb Views) : Sont-elles exemptes de requêtes BDD et de traitement métier ?
    • Controllers (Thin Controllers) : Agissent-ils uniquement comme des chefs d'orchestre ?
  2. Architecture Front-End (CSS & JS) :
    • CSS (Zéro Inline) : Traquer toute trace de style "en dur" (attributs style="..."), de balises <style> ou de classes utilitaires non standard générées dans les fichiers PHP/HTML. Tout le design doit être relégué dans des fichiers .css propres, prévus pour être inclus via le CSS maître.
    • JS (Modularité) : Identifier les fichiers JavaScript monolithiques (fichiers obèses ou fourre-tout). Le code JS doit être segmenté par responsabilité (modules, classes, ou composants) et non empilé dans un seul script global.
  3. Anti-Redondance (DRY) et Couplage Core : Le module recode-t-il des utilitaires, requêtes, validations ou composants UI qui sont déjà disponibles nativement dans le moteur de l'application ? (Utiliser le contexte du Core fourni).

Format de réponse attendu :

  • Diagnostic Architectural : Conforme / Partiellement Conforme / Non Conforme (Bref résumé d'une ligne).

  • Violations (MVC, CSS, JS) : Liste à puces stricte. Indiquer le fichier, la ligne, et l'erreur. (Ex: "Style inline présent dans card.php", "Logique métier dans UserController.php", "Fichier module.js monolithique gérant à la fois la validation et l'UI").

  • Redondances avec le Moteur : Liste à puces des fonctions réinventées à remplacer par les méthodes natives du Core.

  • Plan d'action de refactoring : Si une refactorisation est nécessaire, tu indiqueras les étapes dans un plan de refactorisation ainsi découpé :

    • Étape 1 : Corrections Backend Actions techniques sur Model / Controller.
    • Étape 2 : Extraction CSS Identifier les styles en dur à supprimer des Vues PHP et proposer les règles CSS à intégrer dans le fichier de style dédié.
    • Étape 3 : Segmentation JS Proposer une arborescence ou un découpage précis pour scinder le code JS obèse en modules distincts.

    Fournir des snippets de code corrigé uniquement pour les points critiques illustrant la solution).

    Réponse

  • Diagnostic Architectural : Partiellement Conforme

  • Violations (MVC, CSS, JS) :

    • CSS (Zéro Inline) : Présence d'une balise <style> générée dynamiquement au sein du tampon de sortie (ob_start()) dans controllers/view.inc.php (lignes 28-32). La consigne stricte de zéro balise impose l'injection des valeurs CSS (Custom Properties) soit via un passage JSON à une couche Javascript (DOM update), soit via un fichier compilé ou de surcharges.
    • Architecture globale : Le fichier script.js), ce qui violente brutalement l'arborescence requise (assets/js/script.js).
    • JS (Modularité) : Le fichier assets/js/admin.js (240 lignes) demeure un monolithe lourd (couplage fort entre gestion d'upload AJAX, hydratation de formulaire, et UI de preview textuelle).

  • Redondances avec le Moteur :

    • Téléversement de fichiers : Réimplémentation d'un appel AJAX complexe pour l'upload (lignes 91-149 dans admin.js) au lieu de se baser sur l'API déclarative standard du Core.
    • Couplage Composant : Appel de setTimeout(updatePreviewScale, 50); en dur (ligne 221 dans admin.js) brisant le principe d'indépendance avec ToddPreview.

  • Plan d'action de refactoring :

    • **Étape 1 : Purge de balise CSS ** Retirer la balise <style> dynamique de [view.inc.php]. Transmettre les custom properties CSS et faire en sorte qu'elles soient appliquées proprement au DOM via JavaScript, si le CSS ne peut pas être externalisé en l'état.
    • Étape 2 : Segmentation JS
      • Déplacer immédiatement script.js dans le dossier assets/js/.
      • Scinder admin.js en modules distincts encapsulés par domaine de responsabilité :
        • assets/js/admin/preview.js : Logique de mise à jour UI des polices et couleurs.
        • assets/js/admin/upload.js : Logique asynchrone pour le file upload.
        • assets/js/admin/form.js : Écouteur de l'hydratation (todd:module:load) et initialisation Spectrum.

Analyse

La conformité est donnée pour partielle mais en analysant les problèmes de plus prêt, je me rends compte que les problèmes soulevé sont mineurs :

  • les réglages du style dans view.inc.php sont difficilement implémentable ailleurs sans casser le dynamisme de la vue ;
  • le téléversement des fichiers se fait bien via le service upload.ws.php du noyau ;
  • le fichier admin.js fait à peine plus de 200 lignes ce qui ne nécessite pas vraiment une externalisation de certaines fonctionnalités dont il est responsable.