Files
mcp-wms-wiki/wiki/operations/code-review-process.md
T
arthur 9ce6ae37be lint(standard): corrections completes mode standard
- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md,
  en-tete section Limagrain conserve)
- Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian)
- Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues),
  1 reciblee (manuel de reten)
- related: tenseflow -> tense-flow, pie -> mechanical-elements,
  group.md retire (doublon shipping)
- Registre: compteur global 122 -> 131 pages
- Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie)
- Aucun fichier limagrain/ modifie (cloisonnement)
2026-07-20 13:01:21 +02:00

9.8 KiB

title, type, sources, related, last_compiled
title type sources related last_compiled
Code Review Process (Code, Functional, Documentation) operation
sources/archives/Revue_Code.md
sources/archives/Revue_Fonctionnel.md
sources/archives/Revue_Documentation.md
operations/git-workflow.md
operations/git-branch-lifecycle.md
operations/custom-application-management.md
operations/development-methodology.md
2026-04-17

Code Review Process (Code, Functional, Documentation)

Overview

Procédure interne Mecalux EasyWMS France pour la revue d'une tâche de développement custom avant intégration sur develop. La revue se fait sur trois axes complémentaires, généralement par des reviewers distincts (parfois cumulés) :

  1. Revue Code - qualité technique, conventions de nommage, identification du custom (CST_), gestion des null, erreurs classiques sur le modèle Outbound/Kit
  2. Revue Fonctionnel - exécution des cas de test Jira, comportement des touches Enter / Échap sur les dialogues
  3. Revue Documentation - Jira commentée, présence des éléments dans la branche Git, mise à jour du reten (manuel de retention en Markdown - cf. development-methodology)

Sources : Confluence EasyWMS France - Revue - Code (v10, 08/01/2026), Revue - Fonctionnel (v2, 27/02/2024), Revue - Documentation (v3, 04/03/2024).

Référentiel global Mecalux Espagne : code review checklist, nomenclature, null management best practices.


1. Revue Code

1.1 Pièges sur les requêtes Outbound

OutboundLines vs OutboundOrderLines :

⚠️ Sur les requêtes en writing, utiliser OutboundLines (pas OutboundOrderLines).

Avec OutboundOrderLines, dès qu'une ligne d'ordre de sortie est annulée, on obtient dans les logs :

Le nombre de ligne d'ordre d'expédition ne peut pas être négatif

1.2 Kits sans assemblage : OutboundOrderOutboundOrderLineDetails

Si le projet utilise les kits sans assemblage (cf. kits) :

Propriété Contenu
OutboundOrderOutboundOrderLineDetails Tous les composants du kit
OutboundLines Uniquement le kit lui-même

1.3 OutboundLine.ProductConversion peut être null

⚠️ Sur les requêtes en writing, l'attribut ProductConversion d'une ligne d'ordre de sortie peut être null.

Cas : la commande demande un support spécifique sans article - on a alors le code support renseigné mais pas l'article, donc pas de conversion produit.

1.4 Identification du custom dans le code

Délimiter les blocs de code custom ajoutés au milieu de code standard :

potentiel code standard

//StartCustom
Code custom
//EndCustom

potentiel code standard

1.5 Préfixe CST_ sur les éléments custom

Chaque nouvel élément ou élément modifié doit être préfixé CST_. Trois questions à se poser :

Question Règle
L'élément est-il visible par le client ? Pas de préfixe (ex : les paramètres SmartUI ne prennent pas CST_)
Peut-on modifier le nom de l'élément ? Un workflow non en mode "full edition" ne permet pas de modifier le nom des éléments
Est-ce l'élément de plus haut niveau ? Dans un workflow custom, seul le workflow porte le préfixe ; ses sous-éléments ne le portent pas. Inversement dans un workflow standard, tous les éléments ajoutés/modifiés prennent le préfixe

⚠️ À ne pas oublier :

  • Un dialogue est modifié même si on ne change que l'implémentation de l'activité
  • Les transitions doivent aussi être identifiées

⚠️ Lors du passage d'un workflow de "partial overriden" → "overriden" (full edition), on perd l'identification de couleur des activités/transitions modifiées. Il faut alors préfixer toutes les activités modifiées par CST_ (ouvrir le workflow dans sa version précédente en parallèle pour ne rien oublier).

1.6 Nommage des éléments

Type d'élément Règle de nommage
ViewField d'une vue 2 préfixes + code du viewfield → ViewField_<Vue>_<Champ> (ex : ViewField_OutboundOrderVList_OutboundOrderStatus)
Paramètres SmartUI Préfixer du process impacté, en MAJUSCULES (ex : EXPEDITION_ALLOWED_CONTAINER)
Attributs d'un workflow Commencent par une minuscule (ne pas oublier CST_ dans un workflow standard)
Paramètres formels d'un workflow Commencent par une majuscule
Paramètres d'un dialogue Commencent par une majuscule
Paramètres d'une requête Commencent par une minuscule

1.7 Pas de "code en dur" dans les workflows

Éviter les constantes en dur. En particulier, les actions "Enter" et "Escape" après un dialogue doivent utiliser :

Variable Usage
ProcessContext.EnterAction Tester l'appui sur Entrée
ProcessContext.EscapeAction Tester l'appui sur Échap

1.8 Gestion des NullReferenceException

Particulièrement : FirstOrDefault() doit être sécurisé.

// ❌ Dangereux - exception si aucun ordre n'existe
Context.OutboundOrders.FirstOrDefault(s => s.Code == outboundOrderCode).OutboundLines

// ✅ Sécurisé
var order = Context.OutboundOrders.FirstOrDefault(s => s.Code == outboundOrderCode);
if (order != null) { ... }

2. Revue Fonctionnelle

2.1 Exécution des cas de test

Exécuter tous les cas de test fonctionnel décrits dans la tâche Jira. À défaut, exécuter les cas standard d'utilisation du custom.

2.2 Tester Échap sur les dialogues

Pour chaque dialogue ajouté ou modifié, tester le comportement de la touche Échap en se posant la question :

Que veut faire l'opérateur en pressant Échap ?

  • Revenir à l'écran précédent ?
  • Passer à la suite du process ?
  • Ne rien faire ?

Le comportement par défaut peut ne pas être celui attendu fonctionnellement → bien tester explicitement.

Lié à la règle 1.7 ci-dessus : ProcessContext.EscapeAction doit être utilisé pour intercepter Échap proprement.


3. Revue Documentation

3.1 Jira

Vérifier que les éléments modifiés sont décrits et que les modifications sont explicites dans les commentaires de la tâche.

3.2 Git

Vérifier la présence des éléments modifiés dans la branche Git concernée (cf. git-branch-lifecycle).

Vérification utile : l'historique des commits Git du développeur pour s'assurer qu'il n'a pas inclus de modifications hors périmètre de sa tâche. Ce cas survient quand le dev a été réalisé avec une custom app qui n'était pas au même "niveau" que la branche sur laquelle il l'exporte (typiquement : création de la branche après import de la custom app dans le Builder, alors que d'autres commits ont eu lieu entre temps).

Cf. custom-application-management - règles d'import/export pour éviter ce cas.

3.3 Reten

Vérifier que la description de la tâche est présente dans le reten avec l'intégralité des éléments modifiés.

Cas Localisation dans le reten
Le custom modifie le comportement d'un process Décrit dans les chapitres de process (Entries, Exits, Picking, etc.) avec description fonctionnelle, technique et éléments custom
Le custom ne modifie pas le comportement d'un process Présent dans les tableaux d'éléments custom en fin de reten, avec description de la modification
Des custom attributes ont été utilisés Listés dans la partie "1.2 General custom elements" du reten - et idéalement aussi dans la tâche Jira liée au custom quand il s'agit d'un process custom

Le reten est un manuel de retention en Markdown, géré dans le repo Git du projet (cf. development-methodology).


Common errors (revue détecte)

  • Erreur "Le nombre de ligne d'ordre d'expédition ne peut pas être négatif" dans les logs → utilisation de OutboundOrderLines au lieu de OutboundLines sur une requête writing
  • NullReferenceException sur des chaînages .FirstOrDefault(...).Property → assigner d'abord à une variable + tester null
  • Workflow "overriden" sans préfixe CST_ sur les activités modifiées → relire le workflow précédent en parallèle pour identifier toutes les modifs
  • Élément hors périmètre de la tâche dans le commit → custom app importée à un niveau différent de la branche ; ré-importer après pull/rebase
  • Reten non mis à jour → bloquant pour la revue documentation (le projet ne pourra pas être maintenu post-MEP sans le reten)
  • Échap sur dialogue produit un comportement involontaire → manquait un test fonctionnel ProcessContext.EscapeAction