Page suivante Page précédente Table des matières

2. Le courrier doit passer !

Depuis 1993, j'étais aux commandes du service technique d'un modeste fournisseur de services Internet proposant un accès libre, appelé Chester County Interlink (CCIL) et situé dans le West Chester, en Pennsylvanie (je suis l'un des co-fondateurs de CCIL et j'ai écrit notre unique logiciel de ``bulletin-board system'' (BBS, systèmes de discussions entre utilisateurs) multi-utilisateurs -- vous pouvez vérifier cela en accédant par telnet à locke.ccil.org. Aujourd'hui, ce service supporte presque trois mille utilisateurs sur trente lignes.) Ce travail m'a permis d'accéder au réseau 24 heures sur 24, à travers la ligne de 56K de CCIL -- en réalité, c'était presque une nécessité !

De cette manière, je m'étais habitué au courrier électronique instantané par l'Internet. Pour des raisons compliquées, il était difficile de faire fonctionner SLIP entre ma machine située à mon domicile (snark.thyrsus.com) et CCIL. Quand j'ai enfin réussi, j'ai trouvé que me connecter régulièrement à locke pour vérifier que je n'avais pas de courrier électronique était ennuyeux. Je souhaitais que mon courrier me parvienne sur snark de telle sorte que je sois averti dès son arrivée et que je puisse le traiter à l'aide de mes outils locaux.

Indiquer simplement à sendmail de faire suivre le courrier n'aurait pas fonctionné, parce que ma machine personnelle n'est pas sur le réseau en permanence et ne dispose pas d'une adresse IP statique. J'avais besoin d'un programme qui étende une main tentaculaire à travers ma connexion SLIP, et me rapporte mon courrier afin de le distribuer de manière locale. Je savais que de telles choses existaient, et que la plupart d'entre elles utilisait un simple protocole d'application (application protocol) appelé POP (Post Office Protocol, protocole du bureau de poste). Et bien sûr, le système d'exploitation BSD/OS de locke, incluait un serveur POP3.

J'avais besoin d'un client POP3. Alors je suis allé sur le réseau et j'en ai trouvé un. En fait, j'en ai trouvé trois ou quatre. J'ai utilisé pop-perl pendant un moment, mais il lui manquait une fonctionnalité qui semblait évidente, la possibilité de bidouiller les adresses sur le mail rapporté afin que les réponses fonctionnent correctement.

Le problème était le suivant: un dénommé `joe' sur locke m'envoyait du courrier. Si je rapportais le courrier sur snark et tentais d'y répondre, mon programme de courrier essayait en toute bonne foi de le faire parvenir à un `joe' sur snark, qui n'existait pas. Éditer les adresses de retour à la main pour leur ajouter `@ccil.org' est rapidement devenu assez pénible.

C'était typiquement le genre de choses que l'ordinateur devait faire à ma place. Mais aucun des clients POP existants ne savait comment faire ! Et ceci nous amène à la première leçon:

1. Tout bon logiciel commence par gratter un développeur là où ça le démange.

Ceci est peut-être une évidence (il est bien connu, et depuis longtemps, que ``Nécessité est mère d'Invention'') mais trop souvent on voit des développeurs de logiciels passer leurs journées à se morfondre à produire des programmes dont ils n'ont pas besoin et qu'ils n'aiment pas. Ce n'est pas le cas dans le monde Linux -- ce qui peut expliquer pourquoi la plupart des programmes issus de la communauté Linux sont de si bonne facture.

Alors, me suis-je précipité frénétiquement dans le codage d'un client POP3 tout nouveau tout beau, qui soutienne la comparaison avec ceux qui existent déjà ? Jamais de la vie ! J'ai examiné avec beaucoup d'attention les utilitaires POP que j'avais à ma disposition, en me demandant ``lequel de ces programmes est le plus proche de ce que je cherche ?''. Parce que

2. Les bons programmeurs savent quoi écrire. Les grands programmeurs savent quoi réécrire (et réutiliser).

N'ayant pas la prétention de me compter parmi les grands programmeurs, j'essaie seulement de les imiter. Une caractéristique importante des grands programmeurs est la paresse constructive. Ils savent qu'on n'obtient pas 20/20 pour les efforts fournis, mais pour le résultat obtenu, et qu'il est pratiquement toujours plus facile de partir d'une bonne solution partielle que de rien du tout.

Linus Torvalds, par exemple, n'a pas essayé d'écrire Linux en partant d'une page blanche. Au contraire, il a commencé par réutiliser le code et les idées de Minix, un minuscule système d'exploitation ressemblant à Unix tournant sur les 386. La totalité du code de Minix a été abandonnée ou réécrite complètement depuis -- mais tant qu'il était là, ce code a servi de tuteur à l'enfant qui deviendrait Linux.

Dans le même esprit, je me suis mis en quête d'un utilitaire POP raisonnablement bien écrit, afin de l'utiliser comme base pour mon développement.

La tradition de partage du code source du monde Unix a toujours favorisé la réutilisation de code (c'est pourquoi le projet GNU a choisi Unix comme système d'exploitation de travail, malgré de sérieuses réserves quant au système d'exploitation lui-même). Le monde Linux a pratiquement emmené cette tradition jusqu'à sa limite technologique; il dispose de téraoctets (millions de millions d'octets) de codes sources ouverts généralement disponibles. De telle sorte que passer du temps à chercher le ``presqu'assez bon'' de quelqu'un d'autre a plus de chances de donner de bons résultats dans le monde Linux que nulle part ailleurs.

Et pour moi, cela a marché. Avec ceux que j'avais déjà trouvés, ma deuxième recherche aboutit à un total de neuf candidats -- fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail et upop. Je me suis d'abord concentré sur le `fetchpop' de Seung-Hong Oh. J'y ai ajouté ma fonctionnalité de réécriture des entêtes, et j'ai fait un certain nombre d'améliorations que l'auteur a acceptées dans sa version 1.9.

Quelques semaines plus tard, cependant, je suis tombé sur le code de `popclient' par Carl Harris, et j'ai rencontré un problème. Fetchpop contenait des idées bonnes et originales (comme son mode démon), mais il ne pouvait gérer que POP3 et il était programmé d'une manière quelque peu amateur (Seung-Hong est un programmeur brillant mais inexpérimenté, et ces deux caractéristiques apparaissaient dans son travail). Le code de Carl était meilleur, assez professionnel et solide, mais son programme ne proposait pas certaines fonctionnalités de fetchpop, importantes et plutôt difficiles à coder (en particulier, celles que j'avais programmées moi-même).

Continuer, ou basculer ? Si je basculais, cela revenait à abandonner le travail que j'avais déjà réalisé, en échange d'une meilleure base de développement.

Une raison pragmatique me poussant à changer était la présence d'un support pour plusieurs protocoles. POP3 est le protocole de bureau de poste

NdT traduction littérale de POP
le plus communément utilisé, mais ce n'est pas le seul. Fetchpop et ses semblables n'étaient pas compatibles avec les protocoles POP2, RPOP, ou APOP, et j'envisageais déjà vaguement d'ajouter IMAP (Internet Message Access Protocol, protocole d'accès aux messages par Internet, le protocole de bureau de poste le plus récent et le plus puissant), rien que pour le plaisir.

Mais j'avais une raison plus théorique de penser que changer serait une bonne idée malgré tout, une raison que j'avais apprise bien avant Linux.

3. ``Prévoyez d'en jeter un, car de toute manière, vous le ferez.'' (Fred Brooks, ``The Mythical Man-Month'', chapitre 11)

``Le mythe du mois-homme'', traduction de Frédéric Mora, ITP, ISBN 2-84180-081-4, est un livre où il explique que l'ensemble des croyances relatives à l'unité de mesure ``mois-homme'' est un mythe.

Ou, dit autrement, on ne comprend souvent vraiment bien un problème qu'après avoir implanté une première solution. La deuxième fois, on en sait parfois assez pour le résoudre correctement. Ainsi, si vous voulez faire du bon travail, soyez prêt à recommencer au moins une fois.

Bien (me suis-je dit), les modifications à fetchpop furent un coup d'essai. J'ai donc basculé.

Après avoir envoyé à Carl Harris mon premier lot de modifications apportées à popclient, le 25 juin 1996, j'ai découvert qu'il avait pratiquement perdu tout intérêt pour popclient depuis quelque temps. Le code était un peu poussiéreux, et de petits bogues y subsistaient. J'avais de nombreuses modifications à apporter, et nous nous sommes rapidement mis d'accord pour que je reprenne le programme.

Avant même que je m'en rende compte, le projet avait monté d'un cran. Je n'envisageais plus d'apporter des modifications mineures à un client POP existant. Je m'engageais à maintenir un client POP dans son intégralité, et je savais que certaines des idées qui germaient dans mon cerveau m'amèneraient probablement à effectuer des modifications majeures.

Dans une culture du logiciel qui encourage le partage du code, il est naturel pour un projet d'évoluer ainsi. J'étais en train d'expérimenter le fait suivant:

4. Si vous avez la bonne attitude, les problèmes intéressants viendront à vous.

Mais l'attitude de Carl Harris était encore plus importante. Il comprit que

5. Quand un programme ne vous intéresse plus, votre dernier devoir à son égard est de le confier à un successeur compétent.

Sans même avoir à en discuter, Carl et moi savions que nous poursuivions un objectif commun: chercher la meilleure solution. La seule question d'importance pour chacun de nous était de nous assurer que le programme serait en de bonnes mains avec moi. Une fois que j'en apportai la preuve, il me fit place nette avec bonne volonté. J'espère agir de même quand mon tour viendra.


Page suivante Page précédente Table des matières