Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Êtes-vous pour le refactoring de code ou la réécriture d'un projet de zéro ?


Sujet :

Débats sur le développement - Le Best Of

  1. #21
    Membre extrêmement actif
    Citation Envoyé par abriotde Voir le message
    Ca revient au même a condition que le financier est une vision globale a long terme.
    Un financier qui a une vision globale à long terme??????????????

    Il faudrait voir pour revenir sur terre!

    Dans ce bas monde, il y a autant de "financier avec une vision à long terme" que de poule avec des dents!

  2. #22
    Expert éminent sénior
    je suis bien d'accord avec toutes les réponses précédentes mais au fait le refactoring ça consiste en quoi ?
    Avec un langage objet, à recréer tout un ensemble de classe qui héritent les uns des autres et aussi avec des classes abstraites ?
    Bref à être à fond dans le paradigme objet?
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  3. #23
    Expert éminent sénior
    Citation Envoyé par Mat.M Voir le message
    je suis bien d'accord avec toutes les réponses précédentes mais au fait le refactoring ça consiste en quoi ?
    Avec un langage objet, à recréer tout un ensemble de classe qui héritent les uns des autres et aussi avec des classes abstraites ?
    Bref à être à fond dans le paradigme objet?
    Je te renvoie à un autre vieil article de Joel Spolsky, dont j'ai pu constater sur le terrain(dont je parle ci-dessus) la pertinence. : https://www.joelonsoftware.com/2002/...rub-a-dub-dub/

    Citation Envoyé par Joel spolsky
    No New Features, not even small ones, would be added.
    At any time, with any check in, the code would still work perfectly.
    All I would do is logical transformations — the kinds of things that are almost mechanical and which you can convince yourself immediately will not change the behavior of the code.
    Exactement ce que j'ai fait dans mon premier exemple - à part le module de pilotage qui permettait de tout centraliser. Plus loin dans l'article, Joel Spolsky parle de classes, mais je n'en avait aucune (le COBOL objet est une rare curiosité), et j'ai appliqué sa méthode avec succès. D'ailleurs, je m'aperçois que mon module de pilotage faisait écho à ça (la mise en gras est de moi) :

    Citation Envoyé par Joel Spolsky
    Restructured the ASP site so there is a single entry point instead of lots of different files. This makes it very easy to do things that used to be hard, for example, now we can display input error messages in the very form where the invalid input occurred, something which should be easy if you lay things out right, but I hadn’t laid things out right when I was learning ASP programming way back when.
    Dit autrement, j'ai expérimenté. Quand tu as un code qui marche comme il faut que tu dois refactorer, la méthode Spolsky marche, objet ou pas.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  4. #24
    Membre expérimenté
    Bonjour,

    À ma petite hauteur, je dirais que le refactoring de ses propres "logiciels" peut-être intéressant, on en apprends tout les jours et se perfectionne dans sa manière de travailler/coder/appréhender les besoins actuels et futurs.

    Pour ce qu'y est de faire du refactoring de programme que d'autres ont développé , c'est souvent loin d'être évident, surtout quand les bonnes pratiques ne se sont pas mise en place, et le code non documenté (l'exemple du stagiaire chapeauté par un stagiaire de niveau 2 donné par Pierre F.) .
    Dans ce cas s'il s'agit de petit soft, je préfère reprendre de 0, à ma sauce, le reverse engineering, refactoring, debogage prenant souvent plus de temps ( et le temps c'est de l'argent pour mon boss).

    Pour les "gros" logiciels, la société a pris la décision d'externaliser le développement et la gestion des programmes ( système de leasing) ce qui nous met à l'abri de devoir reprendre des projets essentiels au bon fonctionnement de l'entreprise , et dont les rouages, si fait en interne, ne seraient connus uniquement de celui/celle qui aurait mis en place le programme.

    Bav,
    Michaël

    Si mon aide/avis vous a été profitable , n'hésitez pas à cliquer sur , ça fait toujours plaisir...
    _________________________________________________________________________________________________________________

    "Tout le monde est un génie. Mais si on juge un poisson sur sa capacité à grimper à un arbre, il passera sa vie à croire qu'il est stupide..."
    Albert Einstein

  5. #25
    Membre confirmé
    Réécrire un module oui.
    Réécrire un logiciel non.
    Développer un nouveau logiciel oui.
    Refactorise tout ce que tu veux.

  6. #26
    Membre éclairé
    Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.

    Dans ce genre de boites, les devs n'ont pas le temps de faire les choses proprement, en respectant les bonnes pratiques, en suivant tous les standards (ni même de les apprendre), etc. et c'est remis à plus tard, quand on aura le temps... les années passent et on se retrouve avec une dette technique d'au moins autant d'années, à force d'empiler rustines sur rustines.

    À un moment, ça devient intenable et si, par chance, les décideurs admettent qu'il est temps de de reprendre ça en main, il est souvent bien plus simple de tout reprendre de zéro.

    Alors, oui, je suis vraiment étonné, car en plus de 15 ans d'entraide, sur différents sites, l'excuse du "pas le temps" représente 99.999% de celles invoquées pour ne pas faire les choses comme il faudrait.
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

    Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
    (Contributions bienvenues)

  7. #27
    Expert éminent sénior
    Citation Envoyé par Lcf.vs Voir le message
    Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.
    il n'y a pas vraiment d'adeptes du refactoring,il faut être pragmatique ; au besoin le refactoring peut être utile sinon le logiciel est très coûteux à maintenir.
    On parle de dette technique un concept déjà mentionné sur ce forum
    Ensuite je suis bien d'accord qu'il y ait des entreprises où les deadlines sont trop courtes mais ce sont des entreprises qui n'ont pas toujours les moyens en ressources humaines pour constituer des équipes conséquentes.
    D'une manière ou d'une autre développer un logiciel cela représente tout un coût en entreprise.
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  8. #28
    Expert éminent sénior
    Citation Envoyé par Lcf.vs Voir le message
    Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.
    pro-tip : quand on travaille plus proprement on est plus productif. Souvent dès la première itération. Le simple fait d'avoir pris le temps de penser correctement son architecture fait gagner un temps fou.

    Citation Envoyé par Lcf.vs Voir le message
    Dans ce genre de boites, les devs n'ont pas le temps de faire les choses proprement, en respectant les bonnes pratiques, en suivant tous les standards (ni même de les apprendre), etc. et c'est remis à plus tard, quand on aura le temps... les années passent et on se retrouve avec une dette technique d'au moins autant d'années, à force d'empiler rustines sur rustines.
    en effet, beaucoup de gens n'ont pas écouté on pro-tip. Il m'est arrivé, dans les exemples que je donne ci-dessus, que des chefs techniques prennent l’occasion d'un changement fonctionnel pour faire faire une refonte complète. Ce n'est pas fréquent, mais il se trouve que je me suis retrouvé plusieurs fois dans ce cas-là. Et là, se pose la question : "refactoriser ou repartir d'une feuille blanche?" Question intéressante et complexe.

    Citation Envoyé par Lcf.vs Voir le message
    À un moment, ça devient intenable et si, par chance, les décideurs admettent qu'il est temps de de reprendre ça en main, il est souvent bien plus simple de tout reprendre de zéro.
    Ben pas forcément, justement. Parfois, tu vas repartir de zéro pour un petit changement en fin de chaîne. Parfois tu vas juste refactoriser un monstre illisible. J'ai fait les deux. Dans les deux cas, il fallait considérer l'ensemble des contraintes pesant sur le projet, pas seulement de l'état du code. Un des trucs importants dits par Joel Spolsky, c'est que le vieux code pourri contient un tas d'astuces fonctionnelles dont la mémoire a pu se perdre par ailleurs. C'était mon cas quand j'ai fait un simple refactoring. Ca aurait été simple de tout reprendre à zéro, mais sans specs, tu fais comment? Alors qu'un refactoring systématique a permis de garder isofonctionnalité sur tous les éléments. Le code aussi atroce soit-il était la seule trace qui restait d'années de peaufinages. Ca a sans doute coûté plus cher...au départ. Le nombre de bugs au final était dérisoire.

    Citation Envoyé par Lcf.vs Voir le message
    Alors, oui, je suis vraiment étonné, car en plus de 15 ans d'entraide, sur différents sites, l'excuse du "pas le temps" représente 99.999% de celles invoquées pour ne pas faire les choses comme il faudrait.
    Et c'est une mauvaise excuse. Quand on fait les choses bien, on finit plus vite. Cela étant, faire vite n'est pas la seule cause de dette technique. Les maintenances qui s'empilent pendant des années sont une autre cause de dette technique, parfaitement acceptable, et qu'il faut pourtant parfois traiter.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #29
    Membre éclairé
    Citation Envoyé par el_slapper Voir le message
    pro-tip : quand on travaille plus proprement on est plus productif. Souvent dès la première itération. Le simple fait d'avoir pris le temps de penser correctement son architecture fait gagner un temps fou.
    Assurément mais encore faut-il qu'on te laisse ce temps de correctement le penser, analyser les besoins, les approches possibles, ce que ça peut impliquer dans l'existant, ... surtout alors que tu débarques déjà sur un monstre illisible.

    Citation Envoyé par el_slapper Voir le message

    Ben pas forcément, justement. Parfois, tu vas repartir de zéro pour un petit changement en fin de chaîne. Parfois tu vas juste refactoriser un monstre illisible. J'ai fait les deux. Dans les deux cas, il fallait considérer l'ensemble des contraintes pesant sur le projet, pas seulement de l'état du code. Un des trucs importants dits par Joel Spolsky, c'est que le vieux code pourri contient un tas d'astuces fonctionnelles dont la mémoire a pu se perdre par ailleurs. C'était mon cas quand j'ai fait un simple refactoring. Ca aurait été simple de tout reprendre à zéro, mais sans specs, tu fais comment? Alors qu'un refactoring systématique a permis de garder isofonctionnalité sur tous les éléments. Le code aussi atroce soit-il était la seule trace qui restait d'années de peaufinages. Ca a sans doute coûté plus cher...au départ. Le nombre de bugs au final était dérisoire.
    Oui, là, je parlais vraiment d'un cas que j'ai connu où par-dessus un monstre illisible, tout ce qu'on te faisait faire, c'était ajouter des fonctionnalités reposant sur un truc déjà impossible à maintenir, j'avais averti, avant d'engager d'autres

    Citation Envoyé par el_slapper Voir le message

    Et c'est une mauvaise excuse. Quand on fait les choses bien, on finit plus vite. Cela étant, faire vite n'est pas la seule cause de dette technique. Les maintenances qui s'empilent pendant des années sont une autre cause de dette technique, parfaitement acceptable, et qu'il faut pourtant parfois traiter.
    Là aussi, je te rejoins mais essaie de leur dire , dans ce genre de cas, les réactions des interlocuteurs sont souvent assez étonnantes :
    • on te dit qu'osef, ça marche quand même
    • on te cherche plein d'exemples sur le net de gens qui font comme eux
    • on te fait comprendre que la spécification est subjective
    • on te dit que ça demanderait trop de taff et/ou de maîtriser trop de choses
    • on te prétend que les best practices ne sont pas possibles à mettre en oeuvre
    • on invoque que ça coûterait trop cher pour le client
    • on fait un max pour tenter de te décrédibiliser
    • ...


    Les gens ont une inventivité folle pour ne pas devoir mieux faire ou pour ne simplement pas changer d'habitudes.
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

    Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
    (Contributions bienvenues)

  10. #30
    Membre expérimenté
    Réécrire un projet entièrement ne garanti pas les bonne pratiques, ni que le suivi sera correct...

    Désole de vous choquer, mais réécrire une application demande de comprendre le fonctionnement de l'application existante, y compris de ses bugs. Plus d'une fois un client m'a demande de reproduire les anciens bugs, car cela permettait une 'certaine' utilisation du produit.

    Donc il faudra écrire des tests de non régressions, pour comparer les applicatifs, et au final on se retrouve avec les moyens de faire un refactoring efficace.

  11. #31
    Expert éminent sénior
    Citation Envoyé par mermich Voir le message
    Plus d'une fois un client m'a demande de reproduire les anciens bugs, car cela permettait une 'certaine' utilisation du produit.
    merci pour l'info mais ça c'est un problème de conception c.a.d que l'analyse conceptuelle du projet est défaillante ou insuffisante.
    Sans faire des spécifications, de l'analyse métier le projet risque de mal tourner.
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  12. #32
    Expert éminent sénior
    Citation Envoyé par Mat.M Voir le message
    merci pour l'info mais ça c'est un problème de conception c.a.d que l'analyse conceptuelle du projet est défaillante ou insuffisante.
    Sans faire des spécifications, de l'analyse métier le projet risque de mal tourner.
    C'est le cœur du sujet, encore une fois. Repartir d'une feuille blanche, ça n'est possible que si on a toutes les fonctionnalités documentées. Il est fréquent (mais pas systématique) que le vieux code soit la seule source de documentation à ce sujet. D’où l’intérêt du refactoring : on ne perd pas de savoir faire qu'on ignore avoir. Après, si on a un nouveau set de specs qui ne colle pas à l'existant, la situation est tout à fait différente. Mais il faut savoir ou on se situe.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  13. #33
    Membre extrêmement actif
    S'ils n'avaient pas de chemin pour une mise à jour de la version d'Angular... bah c'est qu'ils faisaient de l'AngularJS, pas de l'Angular.
    Citation Envoyé par Un expert en programmation
    D'ailleurs il croit toujours que le JS c'est de la POO

  14. #34
    Membre confirmé
    Dans tous cela on discute de la pertinence d'un point de vue technique et effectivement tout dépend. En tout cas si c'est pour tout refaire parce que l'on n'a pas de spec mais que l'on n'en crée pas au passage c'est un peu comme proposer l'aile ou la cuisse au client.
    J'ai des connaissances pour qui corriger un bug d'une ligne coutent 3 semaines de doc à justifier les modifications, proposer les tests à réaliser, etc...
    Moi-même j'ai du faire face a certaines incompréhensions : le CdP qui me demandait de ne pas intégrer l'usine à gaz existante, et le commercial qui me demandait des fonctionnalités basées sur un existant pour lequel il n'y avait aucune spec de donnée, que j'ai zappées. Heureusement que la reprise avait donné de meilleurs résultats.

    Il faut que la direction soit ouverte à la discussion sur le coût d'une reprise complète, et souvent on nous tiendra le discours : "Ca marche pas mais tout est fait alors tu n'en as pas pour longtemps..."
    Selso.
    Ingénieur/CdP développement systèmes embarqués &

  15. #35
    Expert éminent sénior
    Je crois que la réponse la plus simple, qui est la plus évidente, a été donnée par el_slapper : ça dépend.
    Actuellement sur mon projet, en posant le stylo et en s'assurant que tout le monde a bien compris, on aurait pu mettre un focus sur les points importants mais peu onéreux (la fameuse loi de Pareto, 20% de cause pour 80% de conséquences... donc 20% de code pour 80% de performance minable sur nos temps de traitement).

    Bon heureusement on met le point dessus alors qu'on est sur la fin de la première itération de dev. Du coup j'ai réussi à vendre des optimisations qui ne sont plus ni moins que des bonnes pratiques.
    Le truc aberrant qui aurait dû être présent au début du projet (rajouter une tâche de datacleansing pour toutes les tables en entrée... j'imagine que l'argument c'était qu'on pouvait rajouter des tables à traiter... Bah tu automatises ta tâche pour qu'ils tapent sur une table de paramètres et tu rajoutes à chaque fois une nouvelle table...).

    Bref c'est hallucinant et évidemment, ça ne va pas en s'arrangeant. Je veux bien que "la meilleure doc soit le code", encore faut-il qu'il soit commenté. J'ai l'impression d'être il y a 10 ans quand j'avais deux ans d'expérience et que je chapotais un junior :
    - T'as testé ?
    - CA compile.
    - Oui mais le résultat ?
    - J'ai une ligne en entrée et une ligne en sortie.
    - Oui mais le contenu ?
    - On verra en recette.
    - Et les commentaires avec la règle de gestion complexes qu'on a vu avec la MOA pour le calcule de la date fin, t'as commenté ?
    - Oui.
    J'ouvre dans le framework l'objet impacté : "Cette fonction calcule la DATE_FIN".
    - Heu, c'est pas un commentaire pour moi.
    - Roh, je ferai une doc quand je partirai !
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  16. #36
    Expert éminent sénior
    Glutinus, ton stagiaire me fait penser à une réflexion de notre administrative. Elle m'a dit hier qu'au lieu d'envoyer un mail au gens pour dire "ton colis arrivera dans trois jours à 14h00", elle se met un rappel à 14h00 trois jours plus tard, et là seulement elle envoie la notification. C'est un tout petit peu plus de travail pour elle...mais ça lui évite d'avoir à courir après les gens et les colis pendant des jours parce-que les gens ont oublié d'aller chercher leur colis. Et au final, ça lui fait bien moins de boulot (et du boulot particulièrement canulant, en plus).

    Ce petit travail en plus au départ qui fait en fait gagner plein de temps, la plupart des gens ont la flemme de le faire. Ca se retourne contre eux, et ils ne retiennent pas la leçon. Je dois avouer que deux ou trois fois dans ma carrière, j'ai eu la flemme aussi. A chaque fois, ça s'est retourné contre moi. De manière brutale, rapide et sanguinolente. J'ai retenu la leçon. Elle aussi. Ton stagiaire, de toute évidence, non. Le problème, c'est qu'on croise plus de gens comme ton stagiaire que comme mon administrative.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  17. #37
    Expert éminent sénior
    Pour être précis c'était un jeune diplômé, qui plus est sorti d'une école de commerce et reformé par Choupa-Stevia. Il cherchait très activement un taf dans un autre domaine pour démissionner, donc développer ne l'intéressait pas. Il n'était pas mauvais, mais il ne voulait pas apprendre des bonnes pratiques, capitaliser de ses erreurs. Et surtout, que ça fonctionne ou pas derrière, il s'en battait les ballons. Par contre, des choses comme commenter ou mettre une info pertinente dans le gestionnaire de conf, ça aurait pu l'aider par la suite.

    C'est une chose que j'ai tendance à remarquer sur l'ensemble des projets que je fais - malheureusement, j'arrive toujours dans le second round, quand les premiers ont fait bien de la merde pendant deux ans. Enfin, quand on regarde la quantité / qualité (ou équivalent avec les ETL pour moi) produit en deux ans il y a eu beaucoup de tournage de pouces. Il y a peu de réunion de cadrage, a minima entre les développeurs, et au mieux entre développeur et MOA / AMOA /Business Analysts voire utilisateurs. Limite, les deux premières semaines d'un projet from scratch de 6 mois devraient être des ateliers sur à peu près tous problématiques qu'on a. Mais au final je vois toujours des rajouts de dernière minute depuis des dernières années, et ce sur des problématiques communes à tous les projets décisionnels (rajout d'index, passage de stats, audit...)



    Source : commitstrip

    Je suis toujours adepte d'à défaut d'une optimisation, d'une boite à outils (éventuellement transportable de client en client quitte à être un peu repensée) pour automatiser des choses. Et toujours friand d'une petite anecdote (toujours sur cette mission il y a dix ans où j'ai beaucoup appris) où j'avais pris du retard pour le début des devs, tous mes collègues avaient fait un headstart et j'ai passé mon temps à tout checké, vérifier minutieusement que source et cible ont les mêmes datatypes, les produits cartésiens, un générateur de fichier de paramètres etc. au final à l'issue de ma conception j'ai fini mes devs avant les autres et les retours sur anomalies étaient bien meilleurs ^^

    Après, pour revenir sur le début du refactoring, la meilleure optique est de se remettre autour d'une table. En général, l'idée du refactoring n'est pas un projet en soi, puisque le produit est en run. Il apparaît généralement pendant une migration, une évolution très forte qui fait changer le paradigme. C'est l'occasion de faire un tour de table pour savoir 1/ quelles ont été les embûches (mais généralement, l'équipe de base est partie à la cloche de bois et ne pourront fournir de REX...) 2/ quels sont les actuels problèmes (performances ? Source ? Cible ? Tels traitements).

    Sur mon projet actuel j'ai identifié quelques points clés :
    - Le modèle source est merdique, mais je sais qu'avec les idiots de MOA en face ça va être quasi impossible de faire fléchir. Tant pis...
    - On change le sourcing de SQL Server à Oracle, en changeant de paradigme de lecture. Je vais en profiter pour rajouter ma fameuse fonction de datacleansing, rajouter des index pour déporter la logique de l'ETL vers le SGBD (et virer les objets qui prennent trop de cache dans l'ETL).

    Bref, Expérience + simple constat de ce qui va pas + on va se concentrer et faire un effort poussé mais sur des tâches minimales, et le tour sera joué
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

###raw>template_hook.ano_emploi###