Bonnes Pratiques
Contents |
Modification de code Ofbiz
Aujourd'hui, OfbizNéogia comporte environ 260 fichiers ofbiz modifiés, sachant qu'une synchronisation demande entre 4 et 5 heures de travail pour étudier et résoudre tous les conflits causés par ces fichiers, je vous propose de respecter les BestPractices suivantes lorsque vous modifiez un fichier ofbiz, ce qui diminuerait considérablement le temps consacré :
Règles générales :
- ne pas retoucher l'indentation du fichier
- ne pas retoucher les sauts de ligne
- ne pas modifier des lignes inutilement
- ne pas supprimer des lignes mais les commenter
La modification de code existant doit être fait en respectant le formalisme décrit ci-dessous. Respectez les libellés exacts, c'est utilisé pour des traitements lors de synchronisation ofbiz pour repérer tous les spécifiques Neogia.
En java :
// Begin neogia specific : comment /* old code */ new code // End neogia specific : comment
En xml :
<!-- Begin neogia specific : comment --> <!-- old code --> new code <!-- End neogia specific : comment -->
En ftl :
<#-- Begin neogia specific : comment --> <#-- old code --> new code <#-- End neogia specific : comment -->
En respectant ce formalisme, on diminue automatiquement le nombre de conflits lors des synchronisations car le code ofbiz en commentaire n'est pas modifié.
À ne pas faire :
<!-- old code --> new code
Dans ce cas, un conflit peu apparaître car old code est modifié
<!-- Begin neogia specific : comment old code End neogia specific : comment -->
Ce format de commentaire pose des problèmes de relecture
<!-- Begin neogia specific : FR127343 --> <!-- old code --> new code <!-- End neogia specific : FR127343 -->
Le n° de tracker n'est pas suffisant. Lors de la synchronisation je n'ai pas le temps d'aller interroger sourceforge pour savoir le but de la modification.
Le commentaire 'comment' doit correspondre au titre de la tâche, il peut aussi contenir le n° du tracker pour obtenir un complément d'information.
Si le nombre de modifications apporté à un fichier devient trop important, il faut alors se demander s'il ne vaut pas mieux réaliser un fork et arrêter de vouloir suivre les évolutions d'Ofbiz.
Modification de diagrammes UML
Les diagrammes UML sont gérés dans le cvs de Néogia comme des fichiers binaires. Il est par conséquent impossible de suivre les modifications apportées au modèle et d'apporter des modifications à ces fichiers dans une branche.
- La modifications de diagrammes UML doit toujours être réalisée dans HEAD
- Afin de valider qu'il n'y a pas d'écrasement de version, il faut ajouter dans le diagram package dans le commentaire prévu à cette effet, le nouveau numéro de version avec un commentaire explicite de la modification effectuée.
- lors du commit, mettre en commentaire du commit le commentaire saisie dans le diagram UML et il faut vérifier que le nouveau numéro de version CVS correspond à celui du commentaire. Si ce n'est pas le cas il y a eu un écrasement, il faut regarder l'historique des commits et le comparer aux commentaire du diagram UML.
- Après une modification de diagramme, le code doit être regénéré dans HEAD pour conserver la cohérence du modèle avec le code généré.
- Pour chaque modification UML, il faut mettre à jour la page du wiki du diagram correspondant et mettre des explications sur les entités ou attribus ajoutés. Comme cela n'a pas toujours était fait, en profiter pour ajouter quelques explications sur l'existant. (pensez à mettre à jours la page en Anglais ;-)
Messages de debug
Niveau des messages
- Verbose : Déboguage, les messages ne sont pas affichés par défaut
- Always
- Info : le message est affiché tout le temps avec la configuration par défaut (ne pas en abuser)
- Important
- Warn : problème détecté mais qui n'empêche pas le bon fonctionnement de l'application
- Error : erreur inattendue
- Fatal : erreur irrécupérable
if (Debug.verboseOn()) Debug.logVerbose(message, module);
Réalisation de tâche et Wiki
Les pages de documentations du wiki doivent être renseignées lors de la réalisation des tâches, bientôt ce sera obligatoire pour que la tache soit validé sur Head.
Il y a deux pages où il faut mettre de la documentation :
Technical Manual (Manuel Technique)
Concerne l'analyse ou la réalisation. Tout ce qui est noté pendants l'analyse ou la réalisation (c'est donc plutot technique) doit être noté dans documentation/Technical Manual/{le sous-composant où se trouve la modif}. Si possible faire une revue finale juste avant le passage de la tâche en TBT, pour avoir quelque chose de correct (par exemple supprimer les hypothèses non retenues)
Functional Manual (Manuel Fonctionnel)
Juste avant le passage de la tâche en TBT, cette documentation doit être renseignée, elle doit s'adresser à des utilisateurs (ou plutôt des consultants connaissant le reste du fonctionnel). Elle peut comporter la procédure de test de la fonction, (c'est le meilleur moyen de l'expliquer), ou juste un détail de l'objectif de cette fonctionalité et de son usage.
Ecrire des tests fonctionnels avec Selenium
Always reinitialize session at the begining of the test
- logout of the application to test
- fill username
- fill password
- select language
- submit login form
Tous les tests DOIVENT démarrer par ces lignes
(au nom de composant pret)
Example (begining of application/party/webapp/tests/TestCreatePerson.html) :
<!-- Begin of standard login procedure --> <tr> <td>open</td> <td>/partymgr/control/logout</td> <td></td> </tr> <tr> <td>type</td> <td>USERNAME</td> <td>admin</td> </tr> <tr> <td>type</td> <td>PASSWORD</td> <td>ofbiz</td> </tr> <tr> <td>select</td> <td>locale</td> <td>value=en</td> </tr> <tr> <td>clickAndWait</td> <td>submitButton</td> <td></td> </tr> <!-- End of standard login procedure -->
pour plus d'infos : selenium
Test à ajouter après chaque transaction
Dans la plupart des cas il faut ajouter ce test juste aprés l'ajout automatique de selenium du test asserTitle
<tr>
<td>assertElementNotPresent</td>
<td>//div[@class='errorMessage']</td>
<td></td>
</tr>
Création de report
Si un report comporte des calculs portant sur une variable BigDecimal il faut impérativement utiliser les fonctions prévues pour les BigDecimal. ex : subtract(), add()
À faire :
<variableExpression><![CDATA[$V{debit}.subtract($V{credit})]]></variableExpression>
À ne pas faire :
<variableExpression><![CDATA[new BigDecimal( $V{debit}.doubleValue()-$V{credit}.doubleValue() )]]></variableExpression>
Cela permet d'éviter des erreurs de calcul liés aux arrondis
