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)
This commit is contained in:
@@ -19,11 +19,11 @@ last_compiled: "2026-04-17"
|
||||
|
||||
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](development-methodology.md))
|
||||
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](development-methodology.md))
|
||||
|
||||
Sources : Confluence EasyWMS France — *Revue - Code* (v10, 08/01/2026), *Revue - Fonctionnel* (v2, 27/02/2024), *Revue - Documentation* (v3, 04/03/2024).
|
||||
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](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/code_review/index.md), [nomenclature](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/nomenclature/index.md), [null management best practices](https://msscc.mecalux.com/documentation/Development/master/ES/map_application_development/null_management_best_practices/index.md).
|
||||
|
||||
@@ -56,7 +56,7 @@ Si le projet utilise les **kits sans assemblage** (cf. [kits](../concepts/kits.m
|
||||
|
||||
> ⚠️ 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.
|
||||
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
|
||||
|
||||
@@ -113,7 +113,7 @@ Chaque nouvel élément ou élément modifié doit être **préfixé `CST_`**. T
|
||||
Particulièrement : **`FirstOrDefault()`** doit être sécurisé.
|
||||
|
||||
```csharp
|
||||
// ❌ Dangereux — exception si aucun ordre n'existe
|
||||
// ❌ Dangereux - exception si aucun ordre n'existe
|
||||
Context.OutboundOrders.FirstOrDefault(s => s.Code == outboundOrderCode).OutboundLines
|
||||
|
||||
// ✅ Sécurisé
|
||||
@@ -156,7 +156,7 @@ Vérifier la **présence des éléments modifiés** dans la branche Git concern
|
||||
|
||||
> 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](custom-application-management.md) — règles d'import/export pour éviter ce cas.
|
||||
> Cf. [custom-application-management](custom-application-management.md) - règles d'import/export pour éviter ce cas.
|
||||
|
||||
### 3.3 Reten
|
||||
|
||||
@@ -166,9 +166,9 @@ Vérifier que la description de la tâche est **présente dans le reten** avec *
|
||||
|---|---|
|
||||
| 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 |
|
||||
| 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](development-methodology.md#manuel-de-reten)).
|
||||
> Le reten est un manuel de retention en **Markdown**, géré dans le repo Git du projet (cf. [development-methodology](development-methodology.md#1-phase-de-développement)).
|
||||
|
||||
---
|
||||
|
||||
@@ -183,8 +183,8 @@ Vérifier que la description de la tâche est **présente dans le reten** avec *
|
||||
|
||||
## Related
|
||||
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) — workflow Git Flow où s'insèrent les revues (avant `Finish Feature`)
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) — la revue est faite avant l'intégration dans `develop` (phase 1)
|
||||
- [Custom Application Management](custom-application-management.md) — règles d'import/export pour éviter les modifs hors périmètre
|
||||
- [Development Methodology](development-methodology.md) — vue d'ensemble (reten, branches, custom apps)
|
||||
- [Kits](../concepts/kits.md) — utile pour comprendre les pièges sur `OutboundOrderOutboundOrderLineDetails` (kits sans assemblage)
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) - workflow Git Flow où s'insèrent les revues (avant `Finish Feature`)
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) - la revue est faite avant l'intégration dans `develop` (phase 1)
|
||||
- [Custom Application Management](custom-application-management.md) - règles d'import/export pour éviter les modifs hors périmètre
|
||||
- [Development Methodology](development-methodology.md) - vue d'ensemble (reten, branches, custom apps)
|
||||
- [Kits](../concepts/kits.md) - utile pour comprendre les pièges sur `OutboundOrderOutboundOrderLineDetails` (kits sans assemblage)
|
||||
|
||||
Reference in New Issue
Block a user