Disquettes

Le truc est que j'ai oublié de noter la raison de certains choix. C'est une erreur, d'autant qu'elle fait perdre du temps. C'est sensé découler de la logique, et ne pas à être signalé, mais on peut très bien passer devant en se demandant pourquoi cette chose étrange est là, et croire qu'on va la corriger.

*

Il arrive quand quand il y a un seul truc qui ne marche pas, ça révèle un parapluie d'erreurs qui mérite une attention spéciales.

*

C'est imaginaire de croire qu'on peut construire un logiciel en suivant des étapes bien établies et délimitées. Au lieu de faire 1, 2, 3, la réalité nous amène plutôt à devoir faire 1, 2, réviser 1, finir 2, 3, réviser 1, réviser 2, finir 3. Un truc du genre.

*

Les différents indicateurs des notes de dev sont : fix, add, reform, ehance,

*

Des fois tu passes la journée entière à faire que le truc marche comme tu croyais qu'il marchait le matin avant de faire ce que tu avais prévu.

*

On a l'impression que le logiciel nous parle. Quand on fait une trouvaille, c'est comme si l'ensemble du système se mettait soudainement à réclamer d'être en harmonie avec l'esprit de cette trouvaille.

*

Quand tu ne maintient pas un code depuis un certain temps, il te le fait bien sentir.

*

C'est dans mes entrailles des problèmes insolubles (facilement) que naissent les révolutions et les changements de paradigmes (qui vont coûter de la bande passante mais allons-y quand même)

*

Travailler dans la précipitation ne mène qu'à perdre du temps. Mieux vaut aller se promener et continuer demain.

*

Concernant les règles de nommage, la linguistique enseigne à distinguer la qualité de la description - ce qui ne se fait pas assez dans le langage courant. Un 'article' est une qualité, d'un objet qui se présente sous forme de texte. La séparation de la couche narrative doit être l'enjeu du système de nommage. Le vocable doit être situé à l'extérieur du code. C'est valable pour les messages d'alerte comme pour les notions du métier. Le code doit n'être que fonctionnel, on fait tel truc, on ne sait pas à quoi ça sert, mais ça marche comme ça. Cela ne sert à rien de savoir à quoi ça sert ou comment on le nomme dans telle ou telle région du monde. Il n'y a pas assez de place dans la tête d'un développeur pour en plus y mettre des notions psychopolitiques.

*

C'est con à dire mais : il ne faut jamais croire qu'on s'est trompé. Il faut toujours vérifier si on a eu raison.

*

Quand tu rencontres un problème, la première question à se poser est de savoir si on est d'humeur à résoudre un problème.

*

Non, on ne pense pas à toutes les choses d'un coup, de même qu'on ne pense pas à tout, du premier coup. C'est là que la passion ou la lassitude font la différence. C'est aussi une crévidence qui n'appartient qu'aux faibles d'esprit.

*

Ceux qui pensent en termes de revue de code, de Psr-4, et de conformité aux exigences de l'industrie (à décorer le code tel qu'on s'y attend) devraient au moins avoir la crainte sourde de très rapidement faire partie de la préhistoire.

*

La législation logicielle est une discipline inconnue et fuie par ceux qui croient que la simplicité existe. Ceux-là trouve bien ce qu'ils comprennent, mal ce qu'ils ne comprennent pas. Or plus on met d'intelligence dans la législation, plus on soulage le code. Elle pèse zéro et prend zéro processeur, donc la plus grande partie du logiciel doit reposer sur elle. On se rend compte de sa pertinence le jour où une innovation ne nécessite aucune ligne de code.

*

La doc d'un logiciel ne peut provenir que de deux sources, le logiciel, et ce qu'il ne peut pas dire. Le logiciel cite ses propres actions, elles sont descriptives. L'auteur explique la législation, pour donner les clefs de la compréhension générale.

*

D'une langue à l'autre il arrive qu'il y ait plusieurs manières de dire le même mot, ou au contraire un seul tesseract de significations. Les discernement servent la compréhension et évite les erreurs et les conflits. Plus un mot est « développé » plus il a de variations. Le développement est par essence le chemin évolutif vers la perfection.

*

Le terme qui a le plus besoin d'être développé, est celui de l'être, que je viens d'utiliser dans cette phrase. Ce « est » appartient au champ de la complétude. Il est démontrable, et objectif. L'autre « est » appartient au champ de l'incomplétude, il nécessite une construction psychologique pour être perçu, et reste subjectif, relatif. Les scientifiques ont fait beaucoup de confusions avec cette histoire de relativité qui leur échappe quand ils y pensent.

*

Contrairement à la Poo qui sert à / prétend permettre d'ajouter autant de fonctionnalités à la chaîne les unes des autres, le Composant structuré (Cs) offre une voie de développement en complexité à n'importe quelle fonctionnalité.

*

Si le but est de partir de zéro et de centraliser ensuite les tâches répétitives au fur et à mesure de l'augmentation en complexité, commencer sur la base de la Poo non-statique est déjà une complexité inutile. J'ai toujours cherché à faire le code le plus minimal possible en nombre de calculs et en complexité. C'est comme ça qu'est né le principe de législation logicielle, en plaçant dans la connaissance des éléments de l'application, de sorte qu'il ne reste que des maths. Chaque chose doit n'avoir lieu qu'une fois, et (ce n'est pas possible de se le représenter graphiquement) tous les processus passent par un seul endroit.

*

Si je n'ai jamais utilisé de Poo c'est parce qu'il n'y en a eu aucun usage. Les arguments en sa faveur sont de l'ordre de la confusion entre les procédures et la logique (la structure, ou le fait de déporter dans la connaissance des parties du logiciel). Le code n'est pas sensé parler de la logique, elle est sensée être connue ou reconnue. Et la Poo aujourd'hui consiste à légiférer sur une et une seule logique comme si c'était la seule, de sorte à exclure de sortir de ce schéma étroit, autant en terme d'innovation que de croissance en complexité. Ces arguments sont la maintenance et le fait que les gens s'y retrouvent. Mais la maintenance est un enfer, tout ce qu'on voit est vite désuet, et le fait de s'y retrouver n'est qu'une question de connaissance des structures existantes.

*

« Il faut absolument réprimer les développeurs et les conduire vers une tendance maniaco-dépressive axée sur le trouble obsessionnel compulsif, afin qu'ils accordent une importance démesurée aux choses factices et qu'ils relèguent la complexité à une autorité externe, et impossible à remettre en cause. Qu'ils se sentent impuissants et qu'ils se battent entre eux. Qu'ils soient remplaçables et dépersonnalisés. Si un inculte veut devenir développeur, accueillez-le comme au club Med. Si l'un deux commence à dire qu'il a réfléchit et qu'il a eu des idées, abattez-le, humiliez-le, discréditez-le. Il ne faut surtout pas que ces gens, qui ont un pouvoir immense entre leurs mains, s'en rendent compte, et qu'il leur vienne l'idée qu'ils pourraient rendre ce monde bien meilleur, et se débarrasser de nous, leurs maîtres ! »