profession développeur

Ce document est complémentaire de mon cv.

J'y expose ce que je crois du métier de programmeur et mes motivations personnelles.

Mes premiers contacts avec l'informatique eurent lieu en 1981 avec un AppleII sur lequel j'écrivais en basic. Plus récemment, j'ai renoué avec cette réelle vocation grâce à une formation suivie au CNAM en 1999: le DPCT de Génie Informatique à Toulouse fut une deuxième révélation ou j'ai confirmé mes prédispositions.

Depuis j'ai exercé mon activité lors de différents projets, tous sur plateforme unix, libre (gnu/linux, openBSD) ou non (AIX, Solaris).

Je reste très attaché à ce métier: je souhaite continuer à évoluer dans ses techniques et compte m'orienter vers de la conception d'architectures.

-- «Rhhhaaaa, mais pourquoi ce besoin de l'informaticien à
    pondre des explications à tour de bras» ?
-- «Parce qu'il aime écrire» ?

Langages

Les langages de programmation sont constitutifs de notre activité quotidienne: le programmeur est d'abord celui qui écrit dans un langage donné.

Rapidement il devient important de bien en connaitre plusieurs; suffisamment pour savoir lequel est le plus adapté à tel ou tel projet.

Finalement, on doit être polyglotte. Mais la métaphore humaine s'arrête au fait culturel et social ... quoi que, on verra vite que c'est faux: nous ne sommes pas que des solitaires noctambules, mais aussi des être sociaux ;).

Styles

L'écriture, forcément, est notre pratique continuelle: on écrit en C ou en python.

Certain pissent du code, d'autre le cisellent. En tous les cas, on reconnaitra toujours la personnalité de l'auteur, ou même d'une communauté qui se remarquera par l'emploi d'expressions idiomatiques.

On ira même jusqu'à personnaliser la mise en forme du code source, standardiser tel type d'indentation.

Certaines tentatives calligraphiques sont particulièrement réussies.

Écrire n'est pas anodin, même quand il s'agit d'un programme informatique.

On y met une partie de soi, pour le plaisir du texte, et aussi parce qu'on laisse une trace quelque part.

Et justement, on ne doit pas perdre de vue qu'on sera (peut-être) lu, et donc que l'on doit être lisible par les autres !

C'est l'assurance que le code sera maintenable et indépendant de ses concepteurs originaux.

mots-clefs

Textes

On vient de le voir, c'est le média de communication avec la machine; en tout cas le plus humainement intelligible puisqu'il nous sert aussi à communiquer avec les autres hommes (euh, lire programmeurs ;).

Plus précisemment, tant que nos interactions avec la machine restent textuelles, nous conservons la compréhension et donc le contrôle du système.

Si les configurations deviennent trop ésotériques on perd en autonomie, et finalement en liberté.

C'est exactement pour cette raison que j'ai fait le choix unix: toute la configuration du système repose sur des fichier au simple format txt que l'on pourra toujours modifier à la main (tout en rendant possible l'usage d'outils graphiques).

Outils

Quand on dit «à la main» on ne croit pas si bien écrire: certains programmeurs se veulent artisans sinon artistes.

Ils ont donc besoin de cet objet propre à l'homme: l'outil, qui prolonge son cerveau via la main.

On pense bien sûr au clavier (que certains virtuoses choisissent avec soin), mais l'accessoire indispensable, la rareté objet de toutes les convoitises, c'est l'éditeur de texte !

Le choix en est si primordial que naissent les chapelles, pour ne pas dire les religions, et leur cortège de trolls: dans un monde unix, par exemple, on distinguera clairement les VIMistes et les EMACSiens.

Personnellement (vim) je (vim) n'ai (vim) pas (vim) de (vim) préférence (vim powered ;).

Mais cela n'est pas suffisant, car l'on a aussi besoin de débogueurs, navigateurs de source, et autres gestionnaires de configuration.

Ces outils sont souvent propres au langage utilisé, et l'on trouve des produits offrant l'ensemble des fonctionalités en un: c'est l'IDE.

Personnellement, je préfère l'agrégation manuelle de logiciels indépendants; là aussi c'est un luxe qu'autorise le système unix: l'interopérabilité des différentes commandes par l'intermédiaire de ce format tout simple qu'est le texte (ah? je l'ai déjà dit? ;).

Ainsi

Mais le grand intérêt de ce système est que chacun de ses éléments est interchangeable à loisir.

mots-clefs

Documentation

    -- «Hey, mais quand c'est qu'on programme» !?
    -- «Dès que tu auras écrit la doc petit
    scarabé».

C'est encore et toujours la même problématique: rester accessible à l'autre. Car même si on peut concevoir le hacker comme un ours solitaire, le développement logiciel est une activité éminemment sociale: on est en contact (virtuel) permanent avec la communauté de ceux qui font

La relation s'établit par l'écrit (encore !), et la sacro-sainte documentation est l'un des pilliers de cette communication.

Dans l'idéal, on écrit en effet la documentation avant le programme. Ce devrait au moins être le cas du document destiné aux utilisateurs: c'est un produit qui est issu du cahier des charges, donc préléminaire à tout codage.

Ultérieurement il subira des modifications, parallèles à l'évolution du code, mais on doit entamer sa rédaction le plus tôt possible: sinon aprés,

Et puis il y a aussi les pairs, ceux qui veulent savoir comment ça marche, ou même ceux qui vont intervenir sur le code, pour la maintenance ou pour contribuer. Pour ceux là on peut aussi écrire un pavé spécifique, mais l'usage est au code bien écrit et documenté. Et puis il y aura la doc de conception, les spécifications, elles aussi très en amont dans le processus de développement.

mots-clefs

Méthode

Un petit utilitaire peut sûrement s'écrire d'une traite, comme ça, au fil de ses idées, pour peu que l'on ait une bonne pratique.

On aura quand même pris soin de nommer ses variables avec bon sens; et puis celles-ci auront été déclarées correctement, avec les bonnes portées; il n'y aura pas non plus de code copié/collé (arghhh), mais des fonctions judicieusement conçues.

Mais cette méthode n'est pas suffisante quand on s'attaque à des projets à peine plus conséquents.

On découvre vite les avantages de l'approche modulaire, où le code est réparti sur plusieurs fichiers et aboutit à la construction de bibliothèques, au moins locales au projet. Merci à makefile qui me permet de ne compiler que les fichiers modifiés !

Et puis les demandes de modification arrivent, et l'on est content d'avoir un document de conception initial sur lequel revenir, pour mieux visualiser l'architecture globale du projet que l'on va remanier (sans compter que, le nez dans le code, tout ça est un peu perdu de vu ;).

Ah ! Le logiciel a du succés ! Et les demandes de nouvelles fonctionnalités arrivent (et leur chapelet de bugs !). Il faut intégrer d'autres développeurs qui vont travailler concurremment sur le même code !

    -- «Hey, mais tu as effacé toutes mes modifs» ?
    -- «meuh non, ya cvs».
    -- «ha, ouf, merci cvs».

Ainsi, on va faire appel à des techniques du génie logiciel pour maitriser le cycle de vie et toutes ses étapes correctement cadencées. Essayer d'en faire l'économie c'est au mieux décupler la complexité, au pire allonger démesuremment les délais, et parfois aboutir à l'échec pur et simple.

C'est inacceptable pour celui qui aime la belle ouvrage, pour l'artisan fier de la qualité fonctionnelle de son travail.

Il est donc nécessaire de faire appel à une méthodologie rigoureuse alliant la communication bien comprise avec les différents acteurs du projets (maitre d'oeuvre, utilisateurs, collaborateurs), la conception prudente (merci UML), et les techniques et outils de la programmation structurée.

Enfin, au delà d'une gestion de projet correcte, on garantit ici aussi la lisibilité du code: le logiciel y gagne en maintenabilité.

mots-clefs

Logiciel Libre

L'esprit du logiciel libre pousse ce concept de lisibilité à son maximum: la règle veut que n'importe qui ait accès au code source de tout programme s'exécutant sur la machine.

Le système devient alors entièrement connaissable, maitrisable: on est toujours assuré d'élucider les mécanismes sous-jacents.

Et puis de tels projets sont par nature destinés à être le plus largement visibles, alors on va soigner son style, car d'autres viendront, verront et jugeront si oui ou non on contribue. Cela milite aussi en faveur d'un code modulaire et bien documenté.

Mais on ne s'arrête pas à la maintenabilité du programme: le principe de mise à disposition maximale induit beaucoup d'autres phénomènes vertueux.

Ainsi les bugs sont-ils «remontés» trés rapidement par les utilisateurs aux équipes de développement, qui bien sûr vont les corriger, mais surtout mettre en place les bonnes techniques de suivi d'évènement (incluant les demandes de fonctionnalités).

Et puis on recevra aussi beaucoup de questions sur le fonctionnement du logiciel, et la doc utilisateur deviendra nécessaire, ne serait-ce que pour arrêter de faire 10 fois la même réponse par mail.

On en revient au principe initial: ce qui est fait par un homme est accessible (et maitrisable) par les autres.

La maintenabilité du logiciel est assurée, mais au-delà son extrème évolutivité. Et puis c'est une vrai production humaine, qui répond à un vrai besoin initial.

mots-clefs

Bibliographie