Ce site se verra mieux dans un navigateur qui supporte web standards, mais il est accessible à tous les navigateurs et terminaux Internet.

Je Bosse sur CityDesk (4)

[ Nav : Accueil > Traductions/JeBossesurCityDesk-2.html]

Joel Spolsky

29 Octobre 2001

Une brève de Joel sur le logiciel, http://www.joelonsoftware.com

Lien original de référence

Les gars, quel week-end terrible ! J'ai été laminé par un rhume. Fièvre. Nez qui coule. Etat patraque. Et WININET.dll.

WININET.dll, vous voyez, est une librairie fournie par Microsoft. Livrée avec Internet Explorer et toutes les versions de Windows depuis environ 1996, ça a été la bête noire de mon week-end. Et cela illustre de manière fascinante combien la vie quotidienne des développeurs de logiciels a changé au cours des dix dernières années.

Voici ce qui s'est passé. Vendredi en fin d'après-midi, j'installais de nouveaux serveurs Web afin de supporter la charge supplémentaire à laquelle nous nous attendions lors de la livraison de CityDesk. Une des premières choses que j'ai faite a été d'essayer d'utiliser CityDesk pour copier des dossiers vers les nouveaux serveurs en utilisant le protocole FTP. Or nous avons fait installer un coupe-feu qui empêche les accès ftp. CityDesk s'est bloqué.

"Pas grave," me dis-je, "je vais utiliser le mode-passif, puisque c'est prévu pour passer la barrière du firewall."

C'est alors que je constatais que CityDesk ne gérait pas le mode passif de FTP.

"Ok, ça ne doit pas être très difficile à mettre en place. C'est probablement disponible sous la forme d'une option dans la librairie de transfert de fichier que nous employons." Une case à cocher et le tour sera joué.

Mais... où trouver cette case à cocher ?"

Pas la moindre trace de celle-ci dans la documentation.

Une recherche dans le fichier exécutable lui-même ne donnait rien du tout.

J'ai recherché dans les Groupes Google qui s'appelaient auparavant DejaNews. Toutes les discussions USENET y sont archivées. C'est là que les développeurs se contactent pour les questions les plus bizarres. Comme je le disais à l'époque à Babak : il y a tant de monde là-dedans qu'on n'est jamais le premier à y avoir rencontré un problème.

Après environ cinq minutes de recherche, la conclusion était indéniable. Notre librairie de transfert de fichiers, que Microsoft offre gratuitement avec le compilateur Visual Basic, ne peut pas faire de FTP en mode passif.

OK, retour à la planche à dessin. Quelles étaient mes alternatives ? Je dressais une liste :

  1. Continuer sans "FTP en mode passif". Ceci rendrait CityDesk moins utile à un grand nombre de personnes, quelque chose que je n'étais pas disposé à faire.
  2. Acheter une librairie FTP commerciale. Honnêtement, j'ai toujours joué de malchance avec les librairies commerciales, ayant découvert bon nombre de fois que la qualité de leur code n'était que rarement conforme aux niveaux des standards pointilleux que nous fixons chez Fog Creek. Quand je consultais les groupes de discussion où les développeurs parlaient d'autres librairies FTP, ils semblaient toujours rencontrer des bogues effrayants que je n'aurais pu supporter.
  3. Employer l'autre librairie de transfert de fichiers de Microsoft, l'ignoble WININET.dll. C'est en fait ce qui est employé par Microsoft Internet Explorer pour transférer des fichiers, et, malgré sa triste réputation, il est si répandu que j'ai raisonnablement considéré qu'il devait être sans bogue (à ce jour, du moins). Quoi qu'il en soit, un bon nombre de développeurs emploient WININET.dll et si je rencontre des difficultés je suis certain de trouver suffisamment de discussions sur ces problèmes sur DejaNews, heu, dans les Groupes Google.

Je pensais que le point n°3 serait assez facile. En fait j'utilisais déjà WININET.dll quelque part ailleurs dans notre code pour importer des pages Web, en utilisant le protocole HTTP.


Une recherche dans la base de connaissance en ligne de Microsoft indiquait qu'il n'était pas vraiment possible d'utiliser WININET.DLL pour faire du FTP à partir de VisualBasic ; cela nécessite des trucs compliqués au niveau des processus si bien que vous devez l'appeler en C ou en C++. Je pensais que le plus simple serait d'écrire mon propre contrôle FTP en  C++, lequel communiquerait avec WININET. Je décidais d'utiliser la librairie ATL de Microsoft pour créer mon contrôle personnalisé, parce qu'elle produit les plus petits fichiers. ATL est l'environnement de programmation le plus compliqué au monde, exigeant un cerveau de la taille du Colorado et 10 solides années d'expérience pour comprendre de quoi il retourne. J'ai étudié ATL à fond, peut-être trois ou quatre fois dans ma carrière et je ne peux jamais me souvenir du bordel de modèles tarabiscotés qu'on y trouve. Personne n'y arrive.

Eh oui, en Virginie, il est possible de créer un environnement de développement de logiciel qui est si difficile à utiliser qu'aucun être humain ne puisse y parvenir. ATL et COM+ en sont mes deux exemples préférés (le dernier est si compliqué qu'un seul homme au monde, Don Box, comprend réellement tout ce qui s'y passe). C++ quant à lui les talonne de très près. Mais la plupart des programmeurs sont bien trop machos pour vouloir l'admettre.

Heureusement, Microsoft fournit avec ATL quelques wizards qui écrivent tout le code compliqué pour vous. Si vous voulez faire quelque chose de spécial, vous devez vous débrouiller seul,  c'est pourquoi mon mot d'ordre était "Rien de Spécial". Pas de caprice. Juste ajouter quelques méthodes et des événements simples et se tenir éloigné de l'enfer, si possible sans m'y prendre la tête.

À un moment, après avoir écrit presque la moitié du code, j'ai découvert que je m'étais trompé en sélectionnant une des cases à cocher du wizard qui générait à ma place l'obscur code ATL. Mais une fois que le code est écrit, il est écrit. Je ne pouvais absolument pas comprendre ce que la case à cocher avait provoqué et dans quelle partie du code le modifier. J'ai recherché sur MSDN (un gigaoctet de documentation sur la programmation de Windows que je conserve sur mon disque dur), la base de connaissance en ligne, et finalement sur tout Internet en utilisant Google, et n'ai pas trouvé une méthode facile pour le modifier. Si bien que j'ai créé deux projets entièrement nouveaux grâce au wizard, en sélectionnant la case à cocher dans un cas et pas dans l'autre, puis j'ai lancé WinDiff, qui compare deux répertoires complets en énumérant toutes les différences, pour trouver ce que la case à cocher modifiait vraiment de telle sorte que je puisse le changer dans mon code. (A un endroit, j'ai dû remplacer un nombre codé en dur à 131473, parce que je voulais que mes contrôles soient visibles durant l'exécution. Une illustration parfaite du fait que la programmation COM n'est pas conçue pour les humains.)

La documentation de Microsoft pour WinInet était assez correcte, comme ces choses peuvent l'être, mais pas suffisamment juste. Dans la page documentant FtpOpenFile , vous trouvez deux phrases se contredisant l'une l'autre :

  1. "Aucun pointeur de fichier n'est renvoyé"
  2. "Valeur de retour : Renvoie un pointeur de fichier en cas de succès"

Soit, que croire ? Empiriquement, ça ne renvoie pas de pointeur de fichier.

La chose suivante que j'ai découverte est que s'il y a un filtre de paquets (une forme simple de firewall) quelque part entre vous et le serveur, le code plante en essayant de copier des fichiers. C'est normal ; c'est la façon de faire sur Internet ; vous n'y pouvez rien. Après un instant, WinInet se rendra compte que les paquets ne passent pas et s'interrompra. Mais il y a fort à parier que l'utilisateur se soit impatienté et qu'il ait déjà cliqué sur le bouton Annuler.

Quand vous cliquez sur le bouton Annuler, mon code signale à WinInet d'abandonner et de fermer la connexion. Mais comme je l'ai découvert, si vous faites cela en cas de filtrage par paquet, WinInet se plantera simplement, plantant votre programme avec lui. C'est clairement un bogue dans le code Microsoft. Une recherche approfondie dans toutes mes sources Internet m'indiquait l'existence d'autres personnes rapportant le même comportement de plantage, mais personne n'avait de solution.

Comment était-ce possible ? Je réfléchissais. Puisqu'Internet Explorer emploie exactement le même code, est-ce qu'il ne devrait pas planter dans la même situation ?

J'ai vérifié. Ce que j'ai découvert c'est qu'Internet Explorer ne plante pas dans cette situation -- il affiche un sablier et attend pendant quelques minutes la fin du délai qu'il sait inévitable. Ceci démontre que les programmeurs de Microsoft étaient au courant de ce bogue dans WinInet et l'ont contourné, au lieu de simplement corriger le code en priorité. Stupide stupide stupide. Pour la nième fois, je me retrouvais dépendant d'une librairie de code qui avait un bogue bloquant inacceptable dans du code que je livrais. Qu'est-ce que vous êtes censé faire si vous êtes chef aux Halles et que votre poissonnier vous livre des poissons qui sentent ?

Deux nouvelles heures d'investigations et d'expérimentations. Finalement je décidais que dans ce cas, quand l'utilisateur clique sur le bouton Annuler, au lieu d'attendre comme dans Internet Explorer, je cacherai simplement la fenêtre de transfert de fichiers de telle sorte qu'il semble que l'opération soit annulée. En tâche de fond,  invisible pour l'utilisateur, j'attendrai que la fin du délai se produise.

Ainsi, comme je l'ai dit, la vie des développeurs a changé. Je n'ai pas pu dormir de tout le week-end. Tournant et retournant dans mes draps détrempés par la sueur, j'ai eu des cauchemars fiévreux au sujet d'ATL. Dimanche je me suis levé à 3 heures du matin et j'ai codé pendant 4 heures juste pour éviter de faire de mauvais rêves sur la Gestion Structurée des Exceptions.

Il y a dix ans, pour écrire du code, vous deviez connaître un langage de programmation, et vous aviez besoin de connaître une librairie de peut-être 50 fonctions que vous employiez régulièrement. Et ces fonctions marchaient, à tous les coups, même si certaines d'entre elles ( gets ) ne pouvaient pas être utilisées sans occasionner des failles de sécurité.

Aujourd'hui, vous devez savoir comment travailler avec des librairies de milliers de fonctions, impliquant du code bogué écrit par d'autres. Il n'est pas possible de toutes les connaître, et la documentation n'est jamais suffisamment bien faite pour écrire du code robuste, ainsi vous apprenez à utiliser des ressources en ligne comme Google, DejaNews, MSDN. (Je suis devenu beaucoup plus productif après qu'un collègue chez Google m'ait montré qu'il est préférable d'utiliser Google pour chercher dans la base de connaissance de Microsoft plutôt que d'utiliser le lamentable moteur de recherche fourni par Microsoft). Dans ce nouveau monde, il est préférable d'utiliser des langages classiques comme Visual Basic et des librairies standards comme WinInet, parce que tellement d'autres personnes les utilisent qu'il est très facile de trouver la correction des bogues et des exemples de code sur le Web. La semaine dernière, Michael a ajouté un dispositif à CityDesk pour vérifier quelle est la version d'Internet Explorer installée. Ce n'est pas du code compliqué à écrire, mais pourquoi s'en préoccuper ?  Cela lui a seulement pris quelques secondes pour trouver le code VB sur le Web, le couper et le coller.

Nous avions l'habitude d'écrire des algorithmes. Maintenant nous appelons des APIs.

De nos jours un bon programmeur passe beaucoup de temps à faire du codage défensif, contournant les bogues d'autres personnes. Il n'est pas rare de mettre en place une gestion d'erreurs pour éviter que votre code plante quand votre putain de librairie s'est vautrée.

Les temps ont changé. Bienvenue dans un monde où le développeur qui sait comment piocher dans le cerveau et l'expérience d'autres personnes en utilisant Internet possède un avantage décisif.

Je Bosse sur CityDesk : 1 2 3 4 5 

Les teneurs de ces pages représentent les avis d'une personne.
Tout le copyright 1999-2002 de contenu par Joel Spolsky. Tous droits réservés.

Valid HTML 4.01!
Human To Human

Ce site sera plus agréable avec un navigateur supportant les standards du web, mais il est quand même accessible par tous les navigateurs.


via FreeFind
[page faite avec CityDesk] site meter