Qu'est ce qu'un logiciel ?
Quand j'étais petit que ce soit pour le commodore 64, les premiers PC, et la HP 48, j'étais une figure incontournable de la fourniture de logiciels divers et souvent piratés...
Donc je sais ce qu'est un logiciel : un fichier fournit par n'importe quelle méthode (dont les disquettes, kermit, ...) qui est utilisable pour l'utilisateur une fois installé. C'est aussi des paquets pypi, des liens sur un site web ou des paquets debian qu'on installe. L'informatique est très diverses dans sa manière de « livrer » les habits informatiques et c'est ce que l'on pourrait appeler coutures.
Et, prenez des gants genre en cuir : pour être élégant on porte les coutures vers l'intérieur (ce qui peut faire mal), pour le confort on les porte retournées.
La notion de couture en informatique mérite qu'on s'y arrête : le tissu du logiciel c'est le code. Ce qui distingue la pratique des uns et des autres, « le professionalisme », c'est l'art de la couture ; de comment on fait tout tenir ensemble et que la couture ne détruise pas l'habit, et que l'habit tienne sans que la couture devienne une perte de confort pour l'utilisateur.
Logiciel avec ou sans couture pour l'utilisateur ?
Imaginons que je veux juste un téléphone qui téléphone et joue de la musique. Quand le fournisseur de telecom livre une nouvelle fonctionnalité sur son réseau, j'ai pas envie que mon téléphone soit inactif le temps que je le mette à jour. Et j'ai pas envie de mettre à jour le téléphone. Je veux ma livraison de logiciel sans couture (surtout le coté serveur). Même chose si je suis un joueur, je préfère jouer qu'être ennuyé par le déploiement de patch et de bugfix.
Logiciel avec couture
Imaginons que je suis administrateur système en train de déployer une couche critique (authentification (ldap), transport (serveur web), téléphonie (asterisk), moi, au contraire je veux avoir un logiciel avec couture ; que j'installe volontairement en suivant une liste de critère (stabilité, sécurité, niveau de fonctionnalités plus ou moins étendus selon que ma compagnie est dans le « bleeding edge » de l'innovation (ce qui nécessite beaucoup de mise à jours dont sécurité), ou dans le « plan plan » où moins on a besoin d'opérateurs pour maintenir un logiciel mieux on se porte.
La couture du logiciel définit tout ce qui n'est pas logiciel mais qui au final correspond à une manière de livrer.
Aussi, certains aiment cliquer dans des « apps store » pour choisir en fonction de l'icône qui est la plus jolie.
Il n'existe pas de « bonne couture universelle » dans le domaine informatique, c'est au cas par cas.
Ce qui implique qu'il y ait une manière originale pour chaque développeur. Quand on dit manière, on accepte implicitement qu'il existe une manière originale de le faire: l'Art. L'art étant souvent ce que la pratique industrielle prétend adopter. Moi, je dis que l'industrie est plus comme un singe qui mime ce qui se fait et est en position de suiveuse qu'en position de meneuse.
Le monde de la couture logicielle pratique
Le monde de l'informatique moderne est truffé de sources primaires de logiciels (dépôts git par exemple ou mercurial) qui ruissellent en source de distributions secondaires (genre les paquets python pypis, perl CPAN), tertiaires (souvent un logiciel étant un assemblage de logiciels existants on le retrouve sur un dépôt), et en produit finis (paquets de distribution, logiciels à télécharger sur une plateforme d'éditeur ou un site web lambda). Chaque étape apporte son lot de coutures. L'art du développeur est de factoriser et d'essayer de faire disparaître au maximum les coutures entre les logiciels mélangés d'infrastructures (serveur de base de données, web...) et le « code ». Le tisssu du logiciel.
Ça veut dire que le mode de livraison que ce soit une archive de code (zip, tarball) avec un manuel d'intallation, un fichier de composition de container (docker compose), une « app » dans un store est non une évidence mais un choix autant esthétique, technique que politique.
Par exemple, j'ai choisi de ne pas faire d'application android ou apple car je ne veux pas suivre les coutures imposées qui merchandisent le logiciel tout en donnant trop de pouvoir à l'éditeur.
La couture la plus simple
Le logiciel le plus simple actuellement dans une forme de livraison comme un sac patapouf, c'est un bête lien vers un serveur de page web, un numéro de version et une manière indiquant comment vérifier l'intégrité du paquet.
C'est ce que j'appelle le logiciel SAC : juste un fil appelé version et un gros sac où l'on met tout dedans.
Mes standards en tant qu'administrateur système minimaliste sont un peu plus élevé. Je vais devoir installer et opérer la solution : je veux de la documentation.
Pareil pour le développeur qui fait des logiciels.
Par contamination de pratiques, nous développons un art de la couture logicielle qui reflète notre communauté de pratique et sans la pratique face à un paysage qui change en permanence il est impossible de « coudre » dans le sens du bois.
La tradition des versions et changelog
Une pratique s'est imposée sur le fait d'avoir des numéros de versions, leur donner un sens de préférence monotonique et monotone pour éviter les surprises.
On a tendance à faire croitre les versions, et ajouter des significations aux chiffres, genre les versions majeures sont signes de changements disruptifs, et mineurs qui indiquent que mis à part les corrections de bogues on le logiciel reste inchangé dans son fonctionnement.
Aux bugs, quand on a un outil de gestion de version intégré on fait correspondre des tickets d'anomalie, et on étoffe le changelog avec les modifs pour qu'un lecteur mordu par un bug sache dans quelle version c'est résolu.
Au bug correspond un test appliqué automagiquement par le gestionnaire de version (ce qui est appelé intégration continue) pour surveiller si il réapparaît (on sait jamais). C'est pas nécessaire, mais ça évite de fournir un logiciel qui a une déchirure :D et quand on est une entreprise qui développe son logiciel pour ses besoins au lieu de passer par la case mise à disposition du logiciel, on évite les coutures et on déploie automatiquement.
La couture propre comme art
La spécificité de chaque développeur réside dans la taille des unités de code qu'il pousse.
Quand je code à la maison, souvent interrompu, mon unité de code préférée est la plus petite possible car je ne suis pas résistant au multi tasking qui pète ma mémoire. Donc, je couds à petite maille. Des tickets de bugs non coupables en plusieurs tickets : atomiques.
Par curiosité subie, il m'est arrivé de faire des mailles larges et de m'en mordre les doigts : quand t'as une pile de modifs non commitées énorme et que tu découvres un bug critique tu es bien ennuyé à pousser ta correction mélangée avec du code en cours non validés, testés.
Si mon grand père maçon m'a appris une chose ce n'est pas qu'un bon ouvrier se reconnaît à ses outils, mais surtout à la propreté de son chantier.
La propreté n'est pas qu'esthétique et du domaine de la fierté, elle est surtout là pour éviter les accidents.
Travailler à petite maille, c'est faire beaucoup de points fins, et donc s'assurer que l'état de son code « sur l'établi (sa machine) » est le plus proche de celui dans le dépôt possible.
Si t'as un accident majeur sur ton chantier (ta baraque et ton ordi crame), tu dois pouvoir reprendre le plus facilement possible ta tâche.
Ce qui semble de la friction, du travail accessoire (gérer les tickets, les versions, documenter les changements) est pourtant essentiel à minimiser les accidents coté développeurs et utilisateurs et au final à maximiser le temps de plaisir à coder. Celui qui veut la paix se prépare au pire.
Cette réflexion est une alternative à la logique qui définit le codeur par ses outils, et sa capacité à les forger. Je prétends que ce qui fait le bon ouvrier informaticien n'est pas sa facilité ni sa virtuosité à utiliser/faire des outils, mais au contraire à oublier les outils pour se concentrer sur la production d'artefacts pertinents bien qualifiés.
