Mots-clé : gestion de projet

Pourquoi les formats de fichiers de Microsoft Office sont si compliqués ? (Et quelques moyens de contourner les problèmes)

Cet article est apparu sur la page principale de Joel on Software le mardi 19 février 2008.

La semaine dernière Microsoft a publié le format des fichiers binaires d’Office. Ces formats apparaissent à première vue à la limite de l’insulte. Rien que le format de fichier pour Excel 97-2003 est un fichier PDF de 349 pages ! Attendez, ce n’est pas tout ! Il y a, dans ce document, quelques commentaires intéréssants :

Chaque collection de tableaux Excel (workbook) est stocké dans un fichier qui est une « compilation d’objets ».

Oui, vous voyez, les fichiers Excel 97-2003 sont des « compositions » de documents OLE, qui sont principalement plusieurs fichiers réunis en un seul. C’est tellement compliqué qu’il vous faut lire au minimum 9 pages de spécifications pour réussir à comprendre ça. Et ces « specs » ressemblent plus à des structures en C (« struct« ) que ce à quoi on s’attend normalement quand on lit des spécifications. C’est en réalité un système complet hiérarchique de fichiers.

Si vous avez commencé à lire ces documents avec l’espoir de passer le week-end à écrire rapidos un code qui importe des documents Word dans votre système de blog, ou qui crée des tableaux Internet qui contiennent vos données de comptes bancaires, formattés comme les feuilles Excel de votre suivi personnel, la complexité et la longueur des spécifications vous ont très certainement guéri de ce violent désir. Et vraisemblablement très rapidement. D’ailleurs un développeur normal concluerait que les formats binaires des applications Office :

  • sont volontairement obscurcis ;
  • sont le produit d’un cerveau démentiel ;
  • ont été crée par des développeurs anormalement incompétents ;
  • et sont impossibles à lire ou écrire correctement.

Vous auriez tort sur tous les points. En creusant un peu, je vais vous montrer comment ces formats de fichier sont devenus incroyablement compliqués, pourquoi cela ne reflète pas l’idée qu’on imagine de la « mauvaise programmation made in Microsoft », et ce que vous pouvez faire pour contourner ces problèmes.

La première chose à intégrer est que les formats binaires ont été conçus avec des objectifs complètements différents de ce qu’on imagine aujourd’hui (HTML). Voici ces objectifs, vous allez ainsi mieux comprendre pourquoi les spécifications sont aussi longues :

  • Ils ont été spécifiquement conçus pour être rapides sur les vieux ordinateurs. Dans les premières versions d’Excel pour Windows, 1 méga-octets de RAM était une taille normale de mémoire vive, et un PC 80386 à 20 MHz devait faire fonctionner Excel de manière confortable. Il y a donc plein d’optimisations dans les formats de ces fichiers qui ont pour objectif de les ouvrir et de les fermer beaucoup plus rapidement.
  • Ce sont des formats binaires, donc charger un enregistrement n’est qu’une question de copier directement (« blit ») une séquence d’octets, du disque dur vers la mémoire vive, où vous finissez immédiatement avec un structure de données de type C (« struct« ) qui est utilisable. Il n’y a pas besoin d’analyser ou de parcourir quoi que ce soit lors du chargement. L’analyse syntaxique et le parcours d’un enregistrement sont incomparablement, énormément, atrocement plus longs qu’un simple « blit ».
  • Le format de fichier est un peu tordu là où c’était nécessaire, là où on fait toutes les opérations habituelles, et cela à des fins de rapidité. Par exemple, Excel 95 et 97 ont quelque chose appelé « Sauvegarde Simple » qu’ils utilisent parfois parce que c’est une variante plus rapide sur une partie spécifique du format OLE, parce que dans les cas de sauvegarde normales, ce n’était pas assez rapide. Word a un menu appelé « Sauvegarde Rapide ». Pour sauver rapidement un long document, 14 fois sur 15, seuls les changement sont ajoutés en fin de fichier, au lieu de réécrire entièrement le document en partant de zéro. Sur les disques durs de l’époque, cela se traduisait par le fait qu’un gros document était sauvé en une seconde au lieu de trente. (Cela signifiait aussi que les données effacées dans un document ne l’étaient pas vraiment et étaient toujours présentes dans le fichier. Ce que beaucoup de gens par la suite n’ont pas apprécié).
  • Ils étaient crées dans le but de pouvoir utiliser des librairies. Si vous voulez écrire un « importateur » binaire, vous devez prendre en compte des choses telles que le format de métafichiers Windows (« Windows Metafile Format ») (pour dessiner des formes) et la gestion d’objets OLE embarqués (« OLE Compound Storage »). Si vous êtes sous Windows, il y a une librairie qui gère déjà tout ça et rend les choses triviales…. d’ailleurs, s’en servir a procuré un bon gain de temps à l’équipe de Microsoft. Mais si vous faites tout du début à la fin, vous devrez tout faire vous-même.Office s’accomode parfaitement avec tout ce qui est documents embarqués, par exemple, vous pouvez embarquer une feuille Excel dans un document Word. Un déchiffreur parfait de format Word devrait donc aussi être capable de faire quelque chose avec cette feuille embarquée.
  • Ils n’ont pas été crées avec le mot « interopérabilité » en tête. La supposition à l’époque, et c’était relativement raisonnable de penser ainsi, était que le format Word ne devait être lu et écrit que par Word lui-même. Cela impliquait que lorsqu’un développeur de l’équipe de Word devait prendre une décision sur des changements dans le format du fichier, la seule chose à laquelle il devait faire attention était que ces changements soient (a) rapides à lire et écrire et (b) prennent le moins de code possible dans le programme exécutable Word. Les choses telles que des formats standardisés SGML et HTML, n’ont jamais été pris en compte jusqu’à ce qu’Internet rende indispensable le fait de pouvoir échanger des documents qui soient compatibles entre eux. Et cela, c’est une dizaine d’années après que le format binaire de Microsoft Office n’ait été inventé. De toute façon, il était possible d’utiliser des « importeurs/exporteurs » pour s’échanger des documents. En réalité, Word a vraiment un format crée spécifiquement pour des exports destinés à d’autres programmes, appelé RTF, qui existe d’ailleurs depuis presque le début, et qui est toujours supporté à 100%.
  • Ils devaient pouvoir intégrer toute la complexité du logiciel. Chaque boîte à chocher (« checkbox »), chaque option de formattage, bref, toutes les possibilités offertes par Microsoft Office doivent être représentées quelque part dans les formats de fichier. Cette boîte à chocher (« checkbox »), dans le menu de Word appelée (« Paragraphe solidaire ») qui force un paragraphe à être automatiquement déplacé sur la page suivante si nécessaire afin de rester associé avec le paragraphe qui le suit ? Cela doit être présent dans le format du fichier.Et cela veut dire que si vous voulez développer un clone parfait de Word, qui peut lire correctement les documents Word, vous devez implémenter cette possibilité. Si vous voulez créer un programme destiné à écrire, qui soit compétitif, et qui a la possibilité de charger des documents Word, cela peut vous prendre une minute pour écrire le code qui va charger ce bit dans le fichier proprement dit, mais cela va certainement vous prendre des semaines à réussir à transformer tout l’algorithme de votre affichage pour que ce dernier s’adapte à ce fameux bit. Si vous ne le faites pas, les clients qui voudront ouvrir leurs documents Word dans votre clone vont voir toutes les pages sens dessus-dessous.
  • Ils ne peuvent que refléter l’histoire des applications. La plupart des choses compliquées dans ces formats de fichiers concernent des possibilités ou des options qui sont vieilles, compliquées, pas appréciées et rarement utilisées. Elles sont toujours là par souci de compatibilité, et parce que cela ne coûte rien à Microsoft de laisser du code. Mais si vous voulez vraiment faire un boulot complet et dans le moindre détail, et que vous voulez lire et écrire dans ces formats, vous allez devoir aussi faire le travail qu’un interne de chez Microsoft a fait il y a 15 ans en arrière. Le pire de tout c’est qu’il y a des centaines d’années-homme de développement qui se trouvent à l’intérieur de Word de d’Excel, et si vous voulez clôner ces applications complètement, vous allez devoir faire ces centaines d’années de travail. Un format de fichier et juste un résumé très concis de toutes les possibilités qu’offre une application.Juste pour le fun, voyons un exemple minuscule en détail. Un onglet Excel est un paquet d’enregistrements BIFF de types différents. Je ne vais parler que du premier enregistrement BIFF des spécifications. C’est un enregistrement appelé 1904.

    Les spécifications du format de fichier Excel sont remarquablement obscures sur cet enregistrement. Elles précisent juste que l’enregistrement 1904 indique « si le système de date 1904 est utilisé ». Ah. Super. Un exemple classique de spécification complètement inutilisable. si vous être un développeur qui travaille sur le format Excel, et que vous lisez ça dans les spécifications, vous pourriez tout à fait en conclure que Microsoft essaie de cacher quelque chose. En effet, vous n’avez pas assez d’information. Il vous faut plus de connaissances pour comprendre tout cela, mais je suis gentil et je vais vous l’expliquer. Il y a deux types de feuillets Excel : ceux qui se basent sur la date de base qui est le 1/1/1900 (avec un bogue d’années bissextiles volontairement crée afin d’être compatible avec Lotus  1-2-3, mais c’est trop ennuyeux pour en parler ici), et ceux dont la date de base est le 1/1/1904. Excel supporte ces deux types de dates parce que la première version d’Excel pour Mac se servait de la date de base du système d’exploitation (c’était le plus facile), mais Excel pour Windows devait impérativement pouvoir importer les fichiers Lotus 1-2-3, qui se servaient de la date de base au 1/1/1900. Déjà rien que ça devrait vous faire pleurer de consternation. Tout au long de cet histoire affligeante, pas un seul développeur n’a pensé à faire quelque chose de correct, mais bon voilà : vous avez la chose ici, et il vous faut faire avec.Vous trouverez vraiment ces deux types de fichiers, 1900 et 1904, un peu partout, selon que le fichier soit originaire de Windows ou de Mac. Les convertir de manière silencieuse peut éventuellement générer des problème d’intégrité des données, donc Excel ne changera jamais le type pour vous. Si vous voulez parcourir des fichiers Excel il faut faudra savoir gérer les deux. Ce n’est pas juste une simple question de charger ce petit bit à partir du fichier. Cela veut dire aussi que vous allez devoir réécrire entièrement tout l’affichage des dates avec un paramètre supplémentaire pour pouvoir prendre en compte ces deux types de date de base (epochs). Comptez au minimum plusieurs jours.

    Bien évidemment, lorsque vous travaillerez sur votre clone Excel, vous découvrirez plein de petits détails subtils sur la gestion des dates. A votre avis, quand est-ce qu’Excel fait la conversion de nombres en dates ? Comment fonctionne le formatage ? Pourquoi est-ce que « 31/1 » est interprété comme le 31 janvier de l’année en cours, alors que « 1/50 » est considéré comme le premier janvier de l’année 1950 ? Toute ces petites choses très subtiles qui concernent les comportements ne peuvent pas être complètement documentées à moins d’écrire un document pratiquement aussi long qui le code source d’Excel lui-même.Et c’est juste le premier enregistrement BIFF, alors qu’il y en a plusieurs centaines que vous devrez gérer. Et pour ne rien vous cacher : celui-ci est l’un des plus simples. La plupart des BIFF feront pleurer de rage un développeur expérimenté.

Une seule conclusion s’impose : c’est très gentil à Microsoft de fournir officiellement un document décrivant le format de leurs fichiers Office, mais ça ne va pas pour autant vous rendre la vie super facile si vous décidez d’écrire quelque chose qui importera ou sauvera sous le format Office. Ces applications sont affreusement complexes et subtiles, pleines de possibilités et vous ne pouvez pas simplement implémenter 20 % des fonctions les plus populaire et espérer que 80 % de votre clientèle sera satisfaire. La spécification du format binaire vous aidera à gagner quelques minutes, tout au plus quelques jours, et vous évitera de faire du reverse engineering. Rien de plus.

OK, je vous ai promis quelques solutions de contournement. La bonne nouvelle c’est que pour la plupart des applications qui veulent lire ou écrire au format Office ne font pas un bon choix. Il y a deux alternatives qu’il vous faut immédiatement étudier : soit laisser Office faire ce travail, soit écrire dans un format plus facile (ce qui ne veut pas dire moins puissant).

Laissez Office faire le boulot pour vous. Word et Excel ont des modèles objet extrêmement complets, disponibles via l’automation COM, qui vous donne la possibilité de faire tout par programmation. Dans plein de cas il est beaucoup plus pertinent de réutiliser le code dans Office plutôt que d’essayer de le ré-implémenter. Voici quelques exemples.

  1. Vous avez une application Web qui doit transformer des documents Word en PDF. Voici comment je le ferais : quelque lignes de VBA Word pour charger le fichier et le sauver au format PDF en utilisant le convertisseur PDF intégré de Word 2007. Vous pouvez appeler ce code directement, même en ASP ou ASP.NET sous IIS. Cela fonctionnera. La première fois, il y aura un chargement de Word et ça prendra quelques secondes. Les fois suivantes, Word sera gardé en mémoire par le sous-système COM pendant quelques minutes au cas où vous en auriez besoin. C’est suffisamment rapide pour n’importe quelle application Web de taille moyenne.
  2. Même chose que précédemment, mais vous êtes hébergé sur du Linux. Achetez un serveur Windows 2003, installez une copie de Word avec une licence pro, et mettez en place un petit Webservice qui fait ce travail. Une demi journée de travail avec C# et ASP.NET.
  3. Même chose que précédemment, mais il vous faut être plus réactif : votre application a grossi. Mettez un « load balancer » en face de plusieurs PC que vous aurez mis en place de la même manière qu’à l’étape précédente. Aucun code supplémentaire.

Ce type d’approche pourrait fonctionner si vous avez pour objectif de faire dans vos applications des appels simples et communs à des objets Office. Par exemple :

  • Ouvrir une fiche  Excel, mettre des informations dans les cellules, recalculer, et extraire des résultat des cellules ;
  • Utiliser Excel pour générer des diagrammes au format GIF ;
  • Extraire presque n’importe quel type d’information de n’importa quelle feuille Excel sans perdre une seconde à réfléchir au format de fichier qu’il y a derrière ;
  • Convertir un fichier Excel au format CSV tabulaire (une autre méthode pratique serait d’utiliser le drive ODBC d’Excel pour aspirer suck data out using SQL queries).
  • Editer des deocuments Word ;
  • Remplir des fiches Word ;
  • Convertir des fichiers entre tous les formats supportés par Office (il y a plein d' »importateurs » qui savent lire les formats de programmes de traitement de texte et de feuilles de calcul).

Dans tous les cas, il y a des façons de dire aux objets Office qu’il ne sont pas en dans une applications interactive, et qu’ils ne doivent pas s’occuper de rafraîchir l’écran et qu’ils ne doivent en aucun cas essayer d’ouvrir une boite de dialogue. Au fait, si vous choisissez cette solution, il y a quelques petites astuces et particularités qu’il faut bien avoir en tête, qui ne sont pas officiellement supportées par Microsoft. Parcourez la base de connaissance de Microsoft sur le sujet avant d’aller plus loin.

Utilisez un format de fichier plus simple pour écrire des fichiers. Si vous devez générer des documents Office par la programmation, il y a presque toujours une façon plus facile et plus pratique que le format binaire Office, que vous pouvez utilisez, et que Word et Excel ouvriront tout de même sans problème, le tout sans rien perdre de vos objectifs.

  • Si vous devez tout simplement générer des données tabulaires pour les ressortir dans Excel, utilisez CSV ;
  • Si vous avez absolument besoin de formules de calcul que CSV ne supporte pas, le format WK1 (Lotus 1-2-3) est incroyablement plus simple que celui d’Excel, et Excel saura le lire ;
  • Si vous devez vraiment, absolument, générer des fichiers natifs Excel, commencez par une très vieille version d’Excel… Excel 3.0 est un bon compromis (c’est le format juste avant que tout ces trucs imbriqués dans des trucs imbriqués n’apparaissent), et sauvez un fichier minimal qui contient uniquement les choses dont vous voulez vous servir. Utilisez ce fichier pour voir le nombre minimal d’enregistrements BIFF que vous devrez ressortir et concentrez vous, dans les spécifications, uniquement sur ces parties ;
  • Pour des documents Word, pensez au format HTML. Word les ouvrira de manière parfaitement transparente.
  • Si vous voulez vraiment générer des documents Word avec des choses particulière et originales dedans, le meilleur moyen sera presque toujours de générer un fichier RTF. Tout ce que Word peut faire peut être écrit dans un fichier RTF, et ce format est un format text simple, pas binaire, et vous pouvez même changer à la main des choses dans le fichier, et Word l’ouvrira toujours certainement sans problème. Vous pouvez créer un document sympa formatté comme vous le désirez, avec des mots-clé que vous voulez remplacer, vous demandez ensuite à Word de sauver le document au format RTF et vous remplacez à la main (ou par programmation) directement dans le fichier RTF ces champs avec les mots-clé à la volée. Et ce document, vous pourrez l’ouvrir sous Word sans aucun problème.

Pour conclure, à moins que vous ne vouliez créer un concurrent d’Office qui peut lire et écrire tous les fichiers Office parfaitement, auquel cas vous aurez des centaines d’années de travail devant vous, il y a de fortes chances que, quel que soit le problème que vous vouliez résoudre, le plus gros de votre travail soit de lire et d’écrire des fichiers Office.

Trello : encore une innovation géniale de Joel Spolsky

Voilà l’idée derrière la chose : pour tous les projets, on a juste des idées. Ces idées, ils proposent de les matérialiser sous forme de « cartes ». Et de faire des tas de cartes. Après, on organise ces cartes, et quand on clique sur ces cartes, on a évidemment plein de détails : qui l’a créée, des commentaires, des modifications, etc.

Il s’appelle Trello.

Bref c’est un outil très novateur, et qui de côté tout ce qui est priorité (enfin il ne le met pas de côté, disons qu’il le cache : c’est en réalité dans l’organisation des cartes qu’on peut gérer les priorités).

Vos projets deviennent plus lisibles et ça ressemble beaucoup aux post-it qu’on a tendance à coller un peu partout quand on veut faire des choses.

Et si vous voulez, carrément, avoir une idée concrète de comment se gère un projet ainsi, vous pouvez le voir avec Trello dans Trello

Trello

Le plus impressionnant, c’est que tout est sur le Web, et que ça tourne parfaitement, et que tout se synchronise automatiquement ! Exemple concret : vous ouvrez votre tableau sur lequel il y a vos cartes, et un collaborateur aux Etats Unis ouvre le même tableau, et lorsqu’il applique des modifications, elles se répercutent automatiquement sur votre tableau, en temps réel ! Par contre, ne me demandez pas d’entrer dans les détails : si jamais deux personnes travaillent sur la même carte au même moment, je ne sais pas du tout ce qu’il se passe.

Vraiment une bonne idée, que je suis en train de tester, et tout se passe de manière naturelle. Joel Spolky est vraiment toujours très novateur !

Les choses que vous ne devriez jamais faire

Par Joel Spolsky, le 6 avril 2000.

Vous trouverez l’original ici

Netscape 6.0 est sur le point de publier sa première version beta. Il n’y a jamais eu de version 5.0. La derniere version majeure était la 4.0, dévoilée il y a presque trois ans. Trois ans, c’est une durée horriblement longue dans le monde Internet. Pendant ce temps, Netscape était assis, sans rien pouvoir faire d’autre que de voir leurs ventes s’écrouler.

C’est un peu ingrat de ma part de les critiquer sur le temps d’écart entre les versions principales. Ils ne l’ont pas fait volontairement, n’est-ce pas ?

Eh bien si, c’était volontaire. Ils ont fait la seule et unique, la pire erreur stratégique qu’une entreprise puisse faire :

Ils ont décidé de réécrire le code en entier.

Netscape n’était pas le première société à faire cette erreur. Borland a fait la même erreur lorsqu’ils ont acheté Arago et essayé de l’intégrer dans dBase pour Windows, un projet maudit qui a pris tellement de temps que Microsoft Access a mangé leur déjeûner, et puis ils l’ont recommencé avec Quattro Pro, en repartant à nouveau de zéro, en épatant les gens sur le nombre impressionnant du peu de possibilités qu’il avait. Microsoft a fait presque la même erreur, en essayant de ré-écrire Word pour Windows à partir de zéro, dans un projet lui aussi maudit appelé Pyramid qui a été stoppé, jeté, balayé et caché sous le tapis. Par chance pour Microsoft, ils n’ont jamais cessé de travailler sur le vieux code, donc ils ont eu quelque chose à vendre, transformant tout ça simplement en un désastre financier, et non pas un désastre stratégique.

Nous sommes des développeurs. Les développeurs sont, au plus profond d’eux-mêmes, des architectes, et la première chose qu’ils veulent faire quand ils arrivent dans un chantier est de tout raser, et de faire quelque chose de grand. Nous ne sommes pas excités par la rénovation incrémentale : le bricolage, l’amélioration, et planter des parterres de fleurs.

Il y a une raison subtile qui explique pourquoi les développeurs veulent systématiquement tout jeter et recommencer. La raison est qu’ils pensent que le vieux code est bordélique. Est c’est là que vient une observation intéréssante : ils se trompent très certainement. La raison pour laquelle ils pensent que le code est un bazar, est dûe à une loi de programmation simple, cardinale et fondamentale :

C’est toujours plus dur de lire du code que de l’écrire.

C’est pourquoi réutiliser du code est si difficile. C’est pourquoi dans votre équipe, chacun a sa propre fonction, unique, qu’il aime utiliser pour casser des chaines en tableau d’autres chaines. Ils écrivent leur propre fonction parce que c’est plus facile et plus sympa à faire que d’essayer de comprendre comment on se sert de la vieille fonction.

Un corollaire de cet axiome est que vous pouvez demander à pratiquement n’importe quel développeur aujourd’hui ce qu’il pense du code qu’il sur lequel il travaille. « C’est un bordel total, » vont-ils vous dire. « La seule chose que j’aimerais vraiment est de tout jeter et recommencer proprement. »

Pourquoi est-ce un foutoir ?

« Eh bien, » vous disent-ils, « regarde cette fonction. Elle s’étale sur deux pages ! Il n’y a rien dedans qui appartient réellement à la fonction ! Je ne sais même pas à quoi sert la moitié des appels faits aux API. »

Avant que la nouvelle brochure de Borland pour Windows ne sorte, Philippe Kahn, le fondateur très coloré de Borland, a été cité souvent dans la presse en vantant à quel point Quattro Pro serait meilleur que Microsoft Excel, parce qu’il avait été entièrement ré-écrit. Que du nouveau code source ! Comme si le code source pouvait rouiller.

L’idée qu’un code nouveau est meilleur qu’un code ancien est foncièrement absurde. Le vieux code a été utilisé. Il a été testé. Plein de problèmes ont été soulévés, et ils ont été résolus. Il n’y a aucun problème avec ça. Il ne va pas créer de nouveaux bogues juste en restant assis dans le disque dur sans bouger. Au contraire, baby ! Est-ce qu’un programme est supposé être comme une voiture, il rouille inévitablement ? Est-ce qu’un programme est comme une peluche qui devient grossière et laide si elle n’est pas faite avec un nouveau matériel ?

Revenons à notre fonction qui s’étale sur deux pages. Oui, je sais, c’est juste une fonction très simple qui affiche une fenêtre, mais elle a un peu grandi et semble avoir grossi inutilement, et personne ne sait pourquoi. Eh bien je vais vous le dire, pourquoi : ce sont des résolutions de bogues. L’un deux résoud le problème que Nancy a eu lorsqu’elle a essayé d’installer le programme sur un ordinateur qui n’avait pas Internet Explorer. Un autre résoud ce bogue qui ne sort que dans les cas où on a très peu de mémoire. Un autre résoud le problème du fichier qui est sur un périphérique externe (disquette, clé USB) et qui se voit retirer en plein milieu d’une opération d’écriture. Cet appel à LoadLibrary semble pourri mais le code fonctionne aussi sur des anciennes version de Windows 95.

Chacun de ces bogues a pris des semaines et des semaines d’usage intensif en situation réelle avant qu’ils n’aient été trouvés. Le développeur peut avoir passé plusieurs jours avant de réussir à reproduire le bogue dans le laboratoire, et de l’avoir résolu. Si c’est comme la plupart des résolutions de bogues, la solution ne prend qu’une ligne, ou tout juste la modification de quelques caractères, mais un travail énorme a été fait dans ces « quelques caractères ».

Quand vous jetez du code et recommencez tout à zéro, vous jetez aussi toute cette connaissance qui va avec. Toutes ces corrections de bogues. Des années de travail de programmation.

Vous jetez en réalité ce qui fait que vous êtes en tête dans votre catégorie. Vous donnez, comme ça, gratuitement, un ou deux ans à vos concurrents, et croyez moi, c’est une durée énorme quand on parle de logiciels informatiques.

Vous vous mettez vous-même dans une position extrêmement dangereuse, dans laquelle vous allez continuer à livrer une vieille version avec du vieux code pendant encore quelques années, quelque chose qui sera donc voué à ne pas évoluer et à ne pas réagir à des nouvelles choses que le marché va demander, parce que vous ne pourrez pas intégrer un nouveau code. Si vous n’avez pas les reins solides, vous risquez carrément de couler et de fermer votre boîte.

Vous perdez une somme d’argent colossale à réécrire du code qui existe déjà.

Est-ce qu’il y a une alternative ? Il faut tout de même admettre que le vieux code de base de Netscape était vraiment très mauvais. Eh bien, dans tous les cas, il pouvait être mauvais mais vous savez quoi ? Il fonctionnait super bien sur un nombre impressionnant d’ordinateur différents, dans le monde entier.

Lorsque les développeurs vous disent que leur code est un bordel pas possible (c’est toujours le cas à un moment ou à un autre), il y a trois choses qu’il faut inspecter.

  1. Il y a des problèmes de conception. Le code n’est pas correctement conçu. Le code concernant les échanges réseaux ouvre ses propres boites de dialogue n’importe quand ; cela aurait dû être mieux géré, et surtout ailleurs. Ces problèmes peuvent être résolus, un par un, en déplacant le code avec précaution, en le mettant à jour, et en généralisant à un seul endroit l’affichage des boites de dialogue. Un seul et unique développeur qui travaille sérieusement et qui vérifie un à un, pas à pas, chacun de ses changements, peut faire cela. Je dis un seul, pour que les autres ne soient pas dans l’impossibilité de travailler. Même les changements majeurs d’architecture peuvent être faits sans changer complètement le code. Sur le projet Juno, nous avons passé plusieurs mois à ré-architecturer autour d’un point central : simplement déplacer le code, le nettoyer un peu, créer des classes de base dont le nom et le principe de fonctionnement soit logique, et créer des interfaces d’échanges claires et précises entre les différents modules. Mais on l’a fait précautionneusement, avec notre code de base, et nous n’avons généré aucun nouveau bogue, et cela sans jeter quoi que ce soit de notre vieux code.
  2. Les développeurs pensent que leur code n’est pas optimisé et qu’il est lent. Une rumeur disait que le moteur de rendu de Netscape était lent. Cela n’affectait qu’une petite partie du projet, qu’il était possible d’optimiser ou de ré-écrire. Il n’était pas nécessaire de tout ré-écrire. Lorsqu’on optimise pour la vitesse, 1 % du travail vous donne 99 % des résultats attendus.
  3. Enfin, le code est devenu, avec le temps, illisible. Un projet sur lequel j’ai travaillé avait un type de données appelée ChaineEnBordel. Un autre projet avait commencé en utilisant, par convention, l’écriture de toutes les variables membres par un underscore, puis a changé plus tard pour quelque chose de plus standard, « m_ ». Donc la moitié des fonctions commencaient par « _ » et l’autre moitié par « m_ ». Ce qui rendait le code difficilement lisible. Honnêtement, c’est le type de chose que vous résolvez en 5 minutes avec une macro dans Emacs, pas la peine de repartir de zéro.

Il est très important que vous vous souveniez de cela : lorsque vous repartez de zéro, il n’y a aucune raison de croire que vous allez faire un meilleur boulot que celui que vous avez fait la première fois. Premièrement, vous n’aurez peut-être pas la même équipe de développeurs à gérer. Si cela se trouve, ce ne sera même qu’une équipe de nouveaux développeurs, et donc il n’auront pas « plus d’expérience ». Vous allez dans ce cas refaire à nouveau les mêmes erreurs, et à l’inverse créer de nouveaux problèmes qui n’existaient pas dans la version originale.

Le vieux mantra « construirez en un puis jetez le » est très dangereux, et encore plus lorsqu’il concerne des grosses applications commerciales. Si vous écrivez du code de manière expérimentale, vous voudrez peut-être supprimer la fonction que vous avez écrit la semaine précédente, parce que vous venez de penser à un meilleur algorithme. Très bien. Vous voudrez peut-être factoriser une classe pour la rendre plus facile à utiliser. Très bien aussi. Mais jeter complètement programme est une folie furieuse, et si Netscape avait eu une hiérarchie, et une hiérarchie qui supervisait le projet de manière adulte, avec une expérience dans le domaine du logiciel industriel, ils ne se seraient peut-être pas tiré une balle dans le pied si violemment.

Qu'est-ce que le workflow ?

On appelle « WorkFlow » (traduisez littéralement « flux de travail ») la modélisation et la gestion informatique de l’ensemble des tâches à accomplir et des différents acteurs impliqué dans la réalisation d’un processus métier (aussi appelé processus opérationnel). Le terme de Workflow pourrait donc être traduit en français par Gestion électronique des processus métier. Un processus métier représente les interactions sous forme d’échange d’informations entre divers acteurs tels que :

  • des humains,
  • des applications ou services,
  • des processus tiers.

De façon pratique, un WorkFlow peut décrire :

  • le circuit de validation,
  • les tâches à accomplir entre les différents acteurs d’un processus,
  • les délais à respecter,
  • les modes de validation

Il fournit en outre, à chacun des acteurs, les informations nécessaires pour la réalisation de sa tâche.