Pattern de développement PL/SQL
Bonjour à tous,
Je suis confronté à une réécriture de traitements PL/SQL. Ces traitements sont développés dans trois énormes packages (plusieurs dizaines de milliers de lignes chacun). Ils sont constitués de procédures et fonctions de plusieurs centaines à plusieurs milliers de lignes chacune.
Je suis face à un constat, cette façon de développée ne permet pas une maintenance rapide et efficace. Il est compliqué de faire travailler plusieurs développeurs en même temps sur ces packages. Ces grosses procédures compliquent fortement la tâche de tests unitaires.
Il y a peu de temps j'ai pu développer tout un package en y appliquant des bonnes pratiques de développement issues du développement objet : procédures et fonctions les plus petites possibles (un traitement ou une itération par procédure). Lors des développements, plusieurs développeurs pouvaient travailler sur le package sans se gêner. La phase de tests unitaires a été plus simple qu'à l'accoutumé puisqu'il était possible de tester par injection de données toutes les procédures.
Je souhaite appliquer ceci à la nouvelle réécriture. Mais j'aimerai aller plus loin. Je cherche un pattern pour organiser toutes les procédures et fonctions par rapport à ce qu'elles réalisent.
Par exemple : un package pour l'accès aux données, un package pour des traitements etc...
Le but est de pouvoir utiliser les packages pour structurer un maximum le code. Quitte à utiliser un bon nombre de package.
Avec un code bien structuré et développé le plus microscopiquement, je compte faire gagner en maintenabilité et permettre à un maximum de développeurs de travailler ensembles.
J'ai fais des recherches sur d'éventuels patterns conseillés pour le développement en PL/SQL mais rien n'en est sorti. Ce qui me surprend, il doit quand même bien exister un grand nombre de traitements toujours réalisés en PL/SQL et donc des développeurs ont du déjà être confrontés aux mêmes problématiques que les miennes. Si vous même utilisez une structuration de vos packages (un pattern, un framework etc...) je serais curieux de vos retours.
Si vous n'en utilisez pas et que vous n'en voyez pas le besoin je suis aussi preneur de retour.
Cordialement,
