Fiabilisation et bonne pratiques sur Simplicité

Bonjour à tous,

Nous avons travaillé sur un PoC avec Simplicité, et finalement on veux l’industrialiser et le passer en prod, cependant, je veux avoir brièvement quelques conseils sur les bonnes pratiques dans Simplicité concernant :

  • les règles de nommage
  • la sécurisation de l’application web si nécessité de surcharger le natif
  • La granularité des modules, par ex, actuellement tous ce que je crée je le mets dans un seul module à savoir les BO, les grant, les groupes, les views, l’adapter… est ce la bonne pratique ?
  • En terme de versionning sur git, c’est quoi les limite du merge sur le XML d’un module par rapport à Simplicité ( par ex 2 commit avec 2 modifications sur le même BO, ou la suppression d’un ObjectField par ex…)

Et s’il y’a d’autres bonne pratique que vous pouvez conseiller je suis preneur,

Je vous remercie d’avance,

Les règles de nommage sont votre choix. On vous conseille d’utiliser les suggestions par défaut proposées par Simplicité (quand le param système SYNTAX est à yes et que vous avez renseigné le prefix des modules et des objets métier), mais à minima on vous conseille de tout préfixer avec un préfix lié à votre application ou votre module (regardez les nommages de la démo, tout est préfixé en “demo” ou “DEMO”)

Précisez ce que vous entendez par “sécurisation de l’application web si nécessité de surcharger le natif”. Regardez déjà ces guidelines de sécurité Simplicité® documentation/security, pour le reste la UI Simplicité n’a pas de faille de sécurité connue (quand on en détecte une elle est corrigée immédiatement), en général les “failles de sécurité” sont purement applicatives (ex: filtres “durs” mal positionnés, droits excessifs, attributs masqué vs forbidden, etc.)

Pour la granularité des modules il n’y a pas de règle générale, c’est à décider au cas par cas en fonction:

  • de la complexité du métier et de la capacité à le “découper” en périmètres fonctionnels étanches et
  • de votre organisation (plus vous êtes nombreux à travailler plus vous avez intéret à avoir de “petits” modules pour éviter au maximum les modifs concurrentes, ce découpage organisationnel peut par exemple se faire par type d’implémentation = les objets métier dans un ou plusieurs modules, les processus dans d’autres, les objets externes dans d’autres, etc.)

Là aussi le découpage des N modules de la démo peuvent vous inspirer : 1 module commun = la demo “de base” + N modules “addons”)

En version 5.0+ il y a, comme vous le savez car vous êtes dans votre société en pointe sur ce sujet, un mode d’export (utilisé notamment dans le cas de Git) où le XML est “explosé” en N fichiers JSON unitaires, ce qui rend le merge plus simple. Attention ce mode est encore expérimental mais, vu de ma fenêtre, il fonctionne correctement. Pour l’activer il faut passer le paramètre EXPORT_MODULE_EXPLODED à yes + clear cache global.

Les autres conseils usuels sont:

  1. regardez/relancez régulièrement l’audit de paramétrage Simplicité qui remonte les erreurs de paramétrage usuelles
  2. passez systématiquement vos modules dans un analyseur de code type Sonar (comme nous le faisons pour la démo: https://sonarcloud.io/dashboard?id=simplicite-modules-DemoProject et les autres modules d’exemple de notre app store)

Bonjour David,
Merci beaucoup pour ce retour détaillé, c’est plus clair pour moi maintenant.
Concernant le versionning je vais me rapprocher de mes collègues alors pour creuser cette piste.