La maintenance est une phase qui peut devenir rapidement un enfer si le développement n’a pas été fait en conséquence.

Voici 5 aspects à considérer durant le développement d’un package SSIS

Hardcode or not Hardcode?

Il est rarement bénéfique de « hardcoder » une valeur dans le flux. Évidemment, c’est plus simple et rapide, mais dans la phase de maintenance, ces valeurs deviennent des épingles dans une botte de foin. Si pour une quelconque raison, hardcoder est la seule issue, SVP, mettez une annotation pour indiquer que cette valeur est utilisée uniquement à un endroit précis.

Par exemple, vous avez une spécification qui vous indique de récupérer les informations des clients du groupe « XYZ ». Finalement, après 6 mois, le groupe change de nom pour « ZYX », mais vous partez en vacances. Le développeur responsable de la maintenance doit modifier le package, mais il ne sait pas où cette valeur est utilisée. Peu-importe la complexité du package, le développeur devra investiguer pour s’assurer de ne rien oublier. Même si la valeur est utilisée à un seul endroit, pour le développeur initial, cela paraît anodin, mais pour celui qui fera la maintenance, son travail sera plus simple.

Quel nom donner à cette variable?

Définissez une nomenclature en fonction du type (“data type”) de la variable.

  • Pour le type “boolean”, il est intéressant de mettre un verbe au début du nom. Exemples : isValidAddress, toBeUpdated, doitEtreAjouter.
  • Pour le type “Object”, souvent utilisé pour contenir des listes, uniquement mettre au pluriel le nom peut être un indicateur pour désigner une liste. Exemples : CustomersToAdded, InvoicesToCredited
  • Pour le type “DateTime”, indiquez dans le nom son utilité. Évitez les “uneDate”, “laDate”, “jour1”.

Dites-vous que peut-importe l’utilisation de la variable, vous devez lui donner un nom représentatif, même si elle est utilisée uniquement pour des tests et qu’elle sera supprimée à la fin du développement.

Gardez à l’idée que l’objectif de cette tâche est de rendre la compréhension du package intuitif.

À quel niveau dois-je déclarer la variable?

Si votre variable est utilisée, par exemple, uniquement dans un Dataflow, déclarez-la à ce niveau. Ça ne sert à rien de mettre toutes les variables globales.

Par contre, si vous faites un développement en prévision d’une prochaine phase, ajoutez une annotation dans le flux pour expliquer les variables que vous avez déclarées à un niveau différent de leur utilisation. Gardez toujours en tête qu’une autre personne devra comprendre votre conception.

Constantes?

Il y a certaines variables qui sont en réalité des constantes, car elles ne seront pas modifiées dans le flux. Pourquoi ne pas les identifier différemment? Vous pouvez ajouter un préfixe (ou autre indicateur) par exemple : CONST_FOLDERPATH.

En un coup d’œil, il est facile de les repérer.  Comparativement aux variables, il est préférable de les déclarer au niveau « global ».

Faites le ménage!!!

Vous êtes prêts à faire la mise en production de votre package? Vérifiez qu’il n’y a plus de variables de « test ». Toutes les variables déclarées doivent être utilisées dans le flux! Si ce n’est pas le cas, supprimez-les!

Ne sous-estimez pas la valeur des variables, car elles sont importantes dans la compréhension d’un package. Il est toujours mieux de donner plus d’informations que pas assez. Donc pensez-y durant vos prochains développement car qui sait, un jour vous serez peut être amené à modifier un package existant !

Partager cet article
  


CONTACT

agileDSS Inc.
407, rue McGill, bureau 500.
Montréal (QC) H2Y 2G3.

info@agiledss.com
(514) 788-1337