Comment On On optimisera plus tard (T)

Les règles de l'optimisation logicielle sont simples. Règle 1 : N'optimise pas. Règle 2 (réservé aux experts) N'optimise pas pour l'instant.

Ces règles ont été énoncées par Michael A Jackson (celui des diagrammes de Jackson pas le chanteur) dans son livre de 1975 "Principles of Program Design" . C'est une lecture intéressante mais déprimante, elle nous rappelle à quel point on maitrisait les bonnes pratiques de développement à l'époque et à quel point on les a oubliées. A vrai dire, trois décennies et une infinité de puissance de calcul plus tard, peu de développeurs se souviennent encore de ces règles. Et parmi ceux qui arrivent à s'en souvenir, beaucoup ne savent même plus ce que "optimisation" signifie.

En tant que responsable technique de sa société, Chris était en charge de l'achat et de la maintenance du serveur de base de données demandé par l'équipe des développeurs. Bien qu'ils recommandaient un serveur plutôt banal, Chris savait que la compagnie était en phase de croissance et voulait être sûr que le matériel tiendrait la charge. Il acheta donc un Dual Xeon 2.8Ghz avec 4Gb de mémoire et un 3*36G 15K SCSI RAID5.

Les développeurs avaient besoin du serveur pour le tout nouveau système de gestion applicative qu'il développaient. Le système existant, bien que toujours vital à la société, fut développer à peu près à la même époque que le livre de Jackson et n'avait pas vraiment bien vieilli. Chacun dans l'entreprise - Chris inclus, il était en charge de la maintenance de l'ancienne application - était pressé de basculer sur la nouvelle.

Le nouveau système était bâti sur les mêmes pratiques que celles utilisées par l'équipe originale : les mauvaises. Dans la base de données, chaque colonne était définie en tant que VARCHAR(100). Bien sûr, les INT et les DateTime sont pratiques pour enregistrer des entiers et des dates, mais de cette façon, les développeurs avaient seulement à se souvenir d'un seul type de données. En quelques mois, la base de données flirtait avec les 10GB. Plusieurs tables étaient au dessus de 1GB en taille avec seulement 100,000 enregistrements.

Chris remonta le problème à son supérieur et lui suggéra de corriger les types de données partout dans le système. "Non, terminer les développement est la priorité pour l'instant. On optimisera plus tard." En considérant la complexité inhérante au changement du type de tous les champs VARCHAR vers leur type adéquat, Chris su que les VARCHAR(100) étaient là pour durer.

Le système était déjà en production et la société de Chris en était complètement dépendante. Les utilisateurs devaient être en mesure d'exécuter des rapports pour mener à bien leurs tâches quotidiennes. L'exécution de rapport pouvait faire tourner le serveur pendant presque 30 minutes sans aucun retour pour l'utilisateur. Encore une fois, Chris remonta le problème à son supérieur, lui demandant d'ajouter une barre de progression affichant l'avancée du rapport. Encore une fois, ce n'était "pas le moment pour l'optimisation"!

Malgré tous ses efforts, Chris fut blamé pour n'avoir pas réussi à optimiser la base. Il tenta les indexes(pas très utiles avec un VARCHAR), l'optimisation de requêtes, et même les tables en mémoire. Rien ne fonctionna. La plupart des tables avaient atteint leur taille de ligne maximale et toutes les conversions étaient faites par le serveur de base de données lui même. Et oui - même pour la plus simple récupération de données (par exemple, un petit jeu de données à une période précise), SQL Serveur devait lire chacune des lignes, convertir la colonne "date" en DATETIME, et ensuite effectuer la comparaison. Tout ce traitement ajoutait au stress incessant que subissait la base. Au final, le serveur pouvait à peine rester debout.

Chris ne travaille plus dans cette société depuis longtemps, le système lui est toujours utilisé. A vrai dire, s'il avait cliqué sur "Lancer le rapport", le jour de son départ, le traitement serait aujoud'hui presque terminé.