Je ne crois pas me tromper sur moi même en disant que j’ai un avis fort et renseigné par des lectures et des expériences notamment professionnel, et au grand damne des recruteurs pas que professionnel, en restant ouvert a la discussion; cela concerne un certains nombre du sujet notamment en ce qui concerne la programmation avec Python (exemple, je grossi et simplifie le trait: les ORM c’est mal, l’OOP c’est pas la panacée, Ansible est au déploiement ce que Django et Flask sont aux framework web…).
Tu as pas demandé tout ce pavé, mais c’est une bonne occasion pour moi de faire le point sur ce que je sait que je sait, j’espère que cela sera utile a d’autres.
Vu que tu as quelque chose en production, tu rentres dans la phase “make it right” de l’expression, “make it work, then make it right, then make it fast”.
Il faut explicitement identifier, écrire sur du papier numérique (ou pas!), quelles sont les avantages et inconvénients de la solution actuel, eu égard du fonctionnement de bout en bout de ton logiciel.
De bout en bout, il s’agit de l’expérience de développement, notamment la mise en place depuis zero de l’env de dev, l’onboarding d’un nouveau contributeur, la maintenance (correction de bug, maj des dépendances, strategie de tests…), et ajouts de fonctionnalités, l’architecture de l’infrastructure de preproduction et sa relation avec la production (comment on maj la preprod), l’infrastructure de production (est-ce qu’il y a un SPOF? est-ce que c’est grave? comment c’est gerer?), le processus de déploiement, et le coût d’exploitation de l’infrastructure (combien ça coûte d’héberger). D’autres chose facile a faire, mais qui prenne du temps c’est mesurer un certains nombre de chose a travers des microbenchmark memoire et cpu, mais aussi le nombre de requetes par seconde que ton installation de production supporte de meme en mesurant a la fois la consommation des cpu et de la mémoire, notamment de la production (ce qui inclus de mesurer le comportement des autres services autre que le backend python, ex: le ou les db). Quelles a la strategie de backup et de restoration from scratch de la production ie. plan de relance d’activite PRA.
Il faut que tu es une idée même approximative des évolutions futures. On ne peux généraliser par exemple factoriser, uniquement qu’a partir de deux^Wtrois exemples, il faut avoir ça en tête quand tu fait une refacto / rework qui vise a rendre plus facile non seulement l’existant qui soit disant et généralement pensée et voulu en amont comme iso-fonctionnel, car c’est dans la pratique jamais iso-fonctionnelle, il y a toujours au moins des ajouts, et parfois des régressions (nouveau ou ancien bug qui refont apparitions), voir retrait de fonctionnalités pas toujours prévues ou désirées. Il faut aussi penser la stratégie de déploiement du nouveau code (iterative vs. bigbang ou entre les deux).
Une opinion mainstream et hyper populaire c’est que la re-ecriture complete (ou pas) est impossible: je ne suis pas d’accord pour en faire une règle generale, et exclure systematiquement la re-ecriture des plans envisageable. Je dirait meme plus, dans le cadre d’un point d’etape qui vise a ameliorer l’existant d’une application en production qui marche (le bon terme c’est marchotte), il est souhaitable de toujours envisager, documenter et planifier plusieurs plans notamment celui de la re-écriture complète.
Pour résumer, il faut une vision, plusieurs plans et élaborer des chemins pour y parvenir. Et après c’est possible de faire un choix renseignes.
J’ai donc commencé à approfondir mes recherches vers des DSL pour ceci et j’avoue avoir trouvé des solutions plutôt intéressantes.
Je considere DSL un terme faux, c’est souvent confondu avec API. Je préfère parler d’interface public. DSL ce rapporte normalement au Domain Driven Design. L’exemple de DSL que toute le monde sans exception cite c’est SQL 
[…]. Ce que tu cherches c’est une bibliotheque sur etagere qui resoud le probleme que tu crois que tu as. D’experience, hormis les systèmes experts (exemple: scikit learn), c’est ce tirer une balle dans le pied d’acheter (caveat emptor) une lib quelle quelle soit dans le language ou tu es expert ou veux devenir expert quand il y a pas d’algorithmes critique (il faut aussi relativiser vis-a-vis de la vision en considerant le time-to-market, mais dans ton cas si ca marche en production, le time-to-market n’est pas a considerer).
Pour le moment ce sont des libs non maintenues
Non maintenue, ne veux pas dire inutiles. Si la licence est compatible ou si tu reprend le code est que tu le transforme tellement que cela a rien avoir avec le code initiale, c’est toujours une bonne source d’information. Lire du code existant est une compétence, rare ou pas, elle reste essentielle a une progression rapide dans notre métier, pour des réalisations immédiates mais aussi dans le cadre de la veille. D’ailleurs, acheter du code (import) ne devrait jamais se faire sans lire le code, au moins pour vérifier qu’il n’y a pas de faille de securites, et potentiellement de gros problemes type algo n^2 ou n^3 dans le chemin critiques, ou un problème de montée en charge si c’est un aspect qui remonte dans la vision du produit (exemple: volume des donnees, nombre de requetes, nombre d’utilisateurs, adequation avec le budget d’exploitation de l’infra etc…).
J’ai d’autre idées de paragraphes mais c’est déjà assez long (spoiler: sqlite sans orm est tres bien dans un certains nombre de cas).
(aussi ca manque de citation, la flem, mais si vous voulez que j’appuie certaines idees avec des arguments d’authorite je peux)
Mais plus sérieusement, le fonctionnement actuel n’est vraiment pas optimal et je pense qu’il faut améliorer le projet avant de continuer sur de nouvelles fonctionnalités.