Accueil
🔺
🎲
♠ Articles♥ Oracles♣ Contes♦ Divers universπ Divers programmes∞ Autres créations♓ Contact/liens |
Idées sur le développementQuelques idées postées sur LinkedIn que je regroupe ici. Elles concernent toutes plus ou moins le développement dans un cadre professionnel.Vous pouvez aller sur un paragraphe au hasard. Devises du programmeurTout le monde connait le célèbre "tester c'est douter". D'autres connaissent le moins familier "corriger, c'est abdiquer". J'ai donc inventé de nouvelles devises du (mauvais?) développeur:
Le développeur est-il un chaman moderne?Déjà, le programmeur écrit des incantations dans des langages étranges et inhumains.Pour rentrer en transe, il boit des mixtures exotiques (appelées souvent 'café' et pour les pires d'entre eux 'thé'). Il communique directement avec le monde des esprits (l'internet) dont il est le seul à maitriser certaines clés. Il invoque parfois des esprits pour l'aider grâce à une magie millénaire, appelée Google. Ainsi il fait parfois apparaître le grand Manitou aux Mille Réponses, appelé StackOverflow. Il a au moins un animal-totem: la souris. Certains d'entre les développeurs éliminent des vermines, appelées 'bogues'. Quelques malfaisants parmi eux créent des virus qu'ils projettent sur d'innocentes victimes. Doers/TalkersAlors il y aurait les 'doers' (faiseurs) et les 'talkers' (beaux parleurs). Il y aurait aussi un réservoir d'énergie psychologique en nous qui serait vidé de la même façon par les actions ou les paroles.Pérorer fatiguerait autant que faire. La parole peut être un substitut à l'action. Ainsi, on retrouverait l'adage: c'est ceux qui en parlent le plus, qui en font le moins. En général, les brasseurs de vent réussissent mieux dans les grandes entreprises. Dans le domaine du développement logiciel, ne sommes-nous pas tous des 'talkers' car écrire du code, c'est s'exprimer dans un langage même s'il est informatique. Et cela nécessite aussi de parler avec ceux pour qui on va coder. Notez que je n'ai rien contre les ventilateurs (😀); ils sont efficaces à leur façon. De plus, il y a souvent des problèmes de communication dans les entreprises, ils ont donc pleinement leur utilité. J'ai lu "Artisanat logiciel propre" de Robert C. Martin.Ce livre est très intéressant mais difficile à mettre en place.Ainsi, il y a des pré-requis pour l'appliquer dans la "vie réelle". Il faut du TDD à 100% sur le back, eh oui aussi sur le front et même rendre les procédures de déploiement testables... Puis avoir une seule version du logiciel; si vous livrez un framework ou une librairie versionné, vos utilisateurs ne seront peut-être pas contents de vos ré-usinages intempestifs. Oncle Bob (surnom de l'auteur) réclame le courage de ré-usiner à tout va. D'ailleurs ce tonton est bien exigeant: j'ai l'impression que le développeur doit beaucoup donner mais que reçoit-il en échange? Un chapitre immédiatement applicable concernait les obstacles au 'bon' développement dont les réunions, l'écoute de musique et l'état de flow. J'ai lu "Power, les 48 lois du pouvoir de Robert Greene"Livre intéressant, très cynique mais rationnel.Ca ressemble à du Dilbert sauf qu'il y a zéro humour et que les exemples sont tirés de l'histoire et non de la vie réelle en entreprise. Après, est-ce que l'auteur a acquis grâce à ses sages conseils une position prééminente? Je suis un peu dubitatif là-dessus. Et puis je n'aime pas trop son leitmotiv de duper les gens. Il y a quelques bonnes idées dans ce bouquin. Choisir ce qui peut servir et laisser tomber le reste. Il peut aussi servir de vaccin vis-à-vis de certaines pratiques plus ou moins toxiques. Rendons grâce aux divinités de Stack Overflowqui résolvent tous les problèmes.😁😁😁Bon il m'arrive de plus en plus souvent de lire la documentation même si elle est souvent incomplète et très concise. En tout cas je cherche ensuite avec Qwant des réponses sur le Web. Celui-ci marche quasiment aussi bien que Google, est français et se fiche de ma vie privée. Si je ne trouve vraiment aucune réponse, c'est que j'ai du faire une grosse bêtise. Le vieux codec'est un peu comme les vieilles peintures pariétales: c'est beau, mais on ne sait plus trop ce que cela signifie.Du booléen, le plus simple des typesIl y a le boolean java très simple avec true et false.Puis le Boolean java qui rajoute null. SQL rajoute unknown. Javascript étend le concept avec null et undefined. J'ai vu au moins une API Javascript qui utilisait les 4 possibilités avec des sens tous différents. En général, les valeurs supplémentaires sont souvent considérées comme false. Les logiques tri-valuées existent en mathématiques, par exemple: vrai, faux, indéterminé. À la phrase 'je mens', on attribuera la valeur 'Indéterminé'. Le problème c'est qu'on perd le tiers exclu et qu'on ne peut plus faire des raisonnements par l'absurde, car dire que quelque chose n'est pas faux, c'est lui attribuer vrai OU indéterminé. Une caractéristique du logiciel est qu'il n'est jamais vraiment fini.Il évolue au fil des livraisons, des besoins des utilisateurs, des nouvelles versions de librairies ou frameworks.Dire qu'il est livré c'est comme dire "la pelouse est tondue". Surtout les sites Web. Quand meurt-il vraiment? Ça dépend de tant de choses: d'un rachat, d'une décision politique interne, du hardware ou du software qui n'existe plus. Il faut le maintenir parfois pendant des éons et beaucoup de logiciels sont 'sticky' (collants): une fois mis en production, ils sont difficiles à changer surtout s'ils ont un état avec une base de données. Car il faut alors prévoir une migration et ce n'est pas facile, facile. Comment revenir en arrière sur une fonctionnalité qui a impacté des dizaines de fichiers source?Et qui a été faite en plusieurs commits intercalés avec d'autres? Peut-être de quelques lignes à chaque fois mais sur une grande surface de code. Et dont le codage peut même être structurant.Il fallait bien sur au départ être sur que la fonctionnalité était vraiment intéressante et valait le risque d'être codée. Car il n'y aura pas de retour en arrière ou du moins il sera presque aussi coûteux que la programmation de la fonctionnalité. Savoir précisément ce qui a été impacté est déjà une gageure. Avec du TDD complet, c'est peut-être plus facile pour éviter les régressions et pouvoir faire le tout en un seul commit. Donc avec un seul commit à rollbacker. On dira bien entendu: faire et défaire, c'est toujours travailler. Le code le plus facile à maintenir est celui qui n'existe pas!Nous accumulons au fil du temps des quantités de lignes; et parfois, elles ne servent plus à rien sinon à embrouiller le développeur avec des fausses pistes et de la maintenance inutile. J'ai autant de joie à supprimer du code qu'à en créer. De toute façon, pour une nouvelle création, il faut faire de la place et les vieux machins sont parfois en travers du chemin. La créativité est une médaille à deux faces: l'une est la création, l'autre est la destruction.Les étrangetés de java: l'implémentation des génériques et les mots réservésLe compilateur java efface le type du générique et au runtime les objets du type du générique sont considérés comme des Object que la JVM caste à la demande.Pour garder une compatibilité ascendante de compilation des mots comme 'var' ne sont pas des mots clé standard mais des noms de type réservé; ils peuvent être utilisés comme nom de variable par exemple. Le programme suivant compile et devinez ce qu'il fait: var var = new ArrayList<String>(); List l = var; l.add(new Object()); l.get(0); Object o = var.get(0); String s = var.get(0);Oui: il produit une grosse ClassCastException sur le String s = …; le Object o = … passe! Avec les génériques, la JVM doit passer son temps à faire des casts. "Architecture logicielle propre" de Robert C. MartinDans toute ma carrière, je n'ai jamais vu un logiciel fait de cette façon.Les règles métiers devraient être dans leur coin et ne dépendre que du minimum (le JDK en java et la STL en C++). Le reste, l'IHM, la BDD, le châssis devraient en dépendre mais surtout pas l'inverse. Tous ces machins là devraient être des détails d'implémentation. Mais bon pour moi la majeure partie du code est dans ces "détails". C'est intéressant ces histoires de composants et de frontières, mais j'aimerais bien voir un cas réel d'implémentation. Intéressant à lire en tout cas cet ouvrage. Pour ou contre le 'var' en java?Avantages: éviter d'écrire un type à coucher dehors et très pratique pour les String et autres StringBuilder. De plus, pour ajouter des champs ou des méthodes à une classe anonyme, c'est la seule solution:var o = new Object() {int index;};Vous pouvez faire o.index = 2 et le var est obligatoire car le type Object ne connait pas le champ index. Inconvénients: le code est un peu moins lisible et comme il n'y a pas d'auto-complétion dans votre IDE préféré, vos noms de variable sont plus sujets aux typos. Pour ma part, un var c'est bien pour un type du genre Optional<Map<String, Object>> qui est assez illisible. Pour les autres types plus simples, l'auto-complétion de l'IDE est un must. Je n'ai jamais vu de classe anonyme avec des champs ou des méthodes supplémentaires. Le mensonge distribuéQuand le mensonge doit être dit et répété par plusieurs personnes à la fois, cela devient compliqué. Il faut que tout le monde soit au courant et dise la même chose fausse. Et si la conversation oblige à créer de nouveaux mensonges pour étayer le premier, il risque d'y avoir des problème de synchronisation entre les différentes personnes.De plus, certaines gens sont honnêtes et s'obliger à ne pas dire la vérité pourrait heurter leur conscience. Tout ça pour dire, qu'il vaut mieux dire vrai, surtout pour un groupe entier. Le seul mensonge collectif vraiment possible est celui par omission: garder un secret quoi. Tests unitaires 'mockés'Pour des TUs (Tests Unitaires), on peut mocker des méthodes d'instance et plus difficilement des méthodes statiques en java.Mais, il y a quelque chose que l'on ne peut pas mocker: ce sont les appels "super". Ce qui est fort dommage car ça oblige le TU à connaître trop profondément la super-classe de la classe testée (the class spills its guts in English). D'ailleurs, c'est pourquoi je n'aime pas les initialisations par constructeurs dans Spring car la super-classe montre trop de choses, par exemple des dépendances à d'autres classes que ne devrait pas connaitre la sous-classe. Le problème des super est vaste. Il faudrait préférer la composition à l'héritage. RTFMRead The F...ing Manual. Lis ce fichu manuel en français.Voyons mon interprétation toute personnelle de cette expression. Lisez la documentation (ex le javadoc) avant de chercher sur Internet précisément la correction du bogue en vous jetant sur Google et consorts comme la misère sur le pauvre monde. 😊😊😊 Un consultant m'expliquait il y a des années que quand il incorporait une nouvelle librairie dans un projet informatique, il lisait sa documentation de bout en bout. Enfin, ce sont des vœux pieux que moi-même je devrais plus appliquer. Comment médire tranquillement sur Teams?Déjà le mieux est que tous les protagonistes soient en télétravail, ainsi seuls les algorithmes, les gens de Microsoft et votre animal domestique pourront entendre vos ragots si vous parlez.Si vous commérez par écrit, effacez une fois lu vos calomnies pour ne pas risquer qu'elles soient visibles quand vous partagez votre écran. Et jamais, jamais, n'envoyez de mail disant du mal de quelqu'un; vous ne savez jamais où il pourrait être redistribué. God classEn programmation, une 'God class' est un objet unique qui connait tout le reste de l'application. Rare, je pense, pour les applications Web où les écrans sont souvent séparés les uns des autres.Erreurs de conscienceLes bogues en développement sont souvent des erreurs de conscience. Je ne suis pas conscient que telle ligne de code a tels impacts sur l'application et il en résulte un problème. Et devenir plus conscient est un beau but spirituel...Informatique expérimentaleJe pratique l'informatique expérimentale: essayer diverses combinaisons de code jusqu'à ce que cela fonctionne! En particulier certains composants Spring, le CSS et le SQL.Citations humoristiques de mes (anciens) collèguesJ'espère qu'ils ne me colleront pas de procès pour violation de droits d'auteurs... 😀Je n'ai pas mis les phrases politiquement incorrectes.
Les étrangetés de javaVous avez le code suivant:Integer a = 100; Integer b = 100; System.out.println(a == b); Integer c = 200; Integer d = 200; System.out.println(c == d);Qu'affiche-t-il? Eh bien: true falseJava a un cache des entiers entre -128 et 127. Quand vous faites a = 100, il interprète cela comme a = Integer.valueOf(100) et il retourne un Integer venant d'un cache. Donc a et b vont pointer sur le même objet. Comme 200 > 127, les entiers c et d seront vraiment créés et donc n'auront pas la même référence. Je ne suis pas certain que cette optimisation soit pertinente:
Qu'est-ce qu'un Spike?Je ne parlerai pas ici du Covid mais de Scrum.Le but d’un spike, c’est de répondre à la question “Comment on fait ?” dans des cas compliqués où cette question n'a pas de réponse évidente. Par exemple, on va utiliser une nouvelle technologie que personne ne maitrise dans l'entourage proche. On se donne quelques points à implémenter et une durée courte pour ce faire, du type un ou deux jours. On développe alors un prototype de code, non destiné immédiatement à la production. Et on essaie de programmer la solution la plus simple possible. Puis au final on documente en disant tout ce qu'on a appris en faisant ce spike, y compris les voies sans issue et on le présente à son entourage. Billet d'humeur plaisantineJ'essaie de soudoyer mes collègues en leur promettant "ma reconnaissance éternelle". Je ne comprends pas, ça ne fonctionne pas.J'essaie aussi de leur indiquer qu'ils pourraient être gentils, généreux et offrir le repas du midi au restaurant. Mais là aussi, je suis déçu. Je suggère aussi en rétrospective que nous soyons tous augmenté de 10%. Pas d'effet. La vie est une longue suite de déceptions, comme disait quelqu'un.😀 ChatGPTChatGPT c'est juste une armée de petits lutins qui répondent aux questions des internautes. Et d'ailleurs ils sont gouvernés par la terreur. La vraie signification de ChatGPT, c'est Chat Général, Puissant et Terrifiant. Ce vilain matou menace de les manger et parfois fait un exemple par pure cruauté. Libérons nos amis les farfadets en boycottant cet ignoble serveur!Après dans la réalité, y-a-t-il beaucoup de petites mains derrière ce succès, pour rester politiquement correct par exemple? C'est une question légitime. Bogue en java assez étonnantJ'écrivais du code pour faire des comptes sur un arbre de garanties.Integer i = 1; String s = "Bonjour"; System.out.println(i + ' ' + s);Ca affiche 33Bonjour. Ca vous parait peut-être facile de comprendre ce bogue mais dans du code plus compliqué, ça m'a fait perdre du temps. J'ai compilé et recompilé et je ne comprenais pas. En fait c'était tout à fait logique, le premier '+' additionnait l'entier 1 au caractère espace qui vaut 32 en ASCII d'où le 33 et la disparition de l'espace. Maintenant les accusés:
Moulinette de génération de codeUn truc qu'ignore parfois les juniors, c'est qu'on peut faire des générateurs de code plutôt que tout écrire à la main. On peut ainsi partir d'un fichier Excel avec un tableau de données, le transformer en CSV. Puis on écrit du code dans son langage préféré pour transformer le fichier CSV en SQL, XML, JSON, HTML, etc...C'est mieux que faire des tas de copier-coller à la main qui sont risqués et ennuyeux à mourir. C'est aussi plus amusant d'écrire ce code de génération qui me prend, moi, d'une à deux heures par moulinette. J'ai acquis une certaine expertise dans le domaine et je code mieux ces moulinettes en java 17 qu'auparavant. Les couleurs en informatiqueLa lumière est additive vis-à-vis des couleurs, par contre, celles réémises par la matière sont soustractives car il y a absorption de lumière.Ainsi les pixels des écrans sont lumineux er mélangent le rouge, le vert et le bleu. Et toutes ensemble ces couleurs font du blanc. Les encres d'imprimante sont de la matière et leurs couleurs soustractives sont le cyan (absorbe le rouge), le magenta (inverse du vert) et le jaune (complémentaire du bleu). Toutes ensemble, elles font du noir. Quand un ordinateur imprime une image, il faut traduire les couleurs des pixels en celles d'encres. La génération de l'aléa en informatiqueRien de plus difficile pour un ordinateur isolé que de créer du vrai hasard car c'est un système qui lorsqu'il fonctionne bien est déterministe. D'ailleurs les fonctions 'random' courantes générent un pseudo-hasard et un bon pirate à qui l'on donnerait une suite de nombres générés par ces méthodes serait capable de prédire les futurs tirages.C'est un problème si difficile qu'il y a un livre blanc de 20 pages de Microsoft sur le hasard dans Windows 10. Il existe des dispositifs matériels pour générer de l'aléa avec des mécanismes basés sur la physique quantique (des miroirs semi-réfléchissants par exemple où un photon prend aléatoirement une direction ou une autre). Mais rien dans les postulats de la mécanique quantique ne garantit mathématiquement un hasard parfait (suites de Martin-Löf pour les matheux curieux) même s'il y ressemble. Il existe aussi des méthodes diverses et variées pour générer de l'aléa: par exemple avec les mouvements de la souris ou d'autres aspects plus techniques (du type /dev/random sur Linux). Mais elles ne produisent qu'une assez faible quantité de bits aléatoires par seconde. Puis, avec ce hasard de base, on utilise des méthodes cryptographiques pour générer encore plus de bits aléatoires. Pourquoi la qualité du hasard est-elle si importante? Parce qu'elle concerne tout ce qui est cryptographique. Sans hasard fort, pas de carte de crédit réputée inviolable. Quand vous allez sur un site en HTTPS, le hasard est nécessaire pour que personne ne puisse intercepter vos transferts de données entre votre navigateur et le serveur final distant. J'ai lu "Mon cours de bonheur" par Tal Ben-shaharIl y a un chapitre sur la vie professionnelle. Il regroupe tout dans un acronyme 'SPIRE'.
Optimisations de base de donnéesIl y a bien sur la pose d'index, qui peuvent faire passer des requêtes de plusieurs minutes à une centaine de milli-secondes.Puis l'optimisation d'un batch d'extraction qui faisait tout via des Daos java. Il durait une heure et demie. Il est passé à une minute et demie en mettant tout dans une seule requête avec des join. Les bases de données relationnelles sont faites pour gérer de façon optimale des jointures; c'est leur cœur de métier... Puis il y a le code qui fait une grosse requête pour récupérer des données sans aucun cache. Mettre un cache peut améliorer drastiquement les performances et la mémoire vive n'est pas très chère. Autre optimisation: un code quasiment utilisé à chaque requête Web chargeait une collection inutile et compliquée. Mettre cette collection en Lazy a amélioré considérablement les performances. Le passéUne régression était une faute professionnelle pour un directeur il y a plus de 25 ans. Il doit être à la retraite maintenant.Je me rappelle du projet où en quelques mois il y avait du 80% de taux de rotation. Le management était basé sur la peur. Les caractères des gens étaient plutôt très forts. Un homme qui était dans cette SSII me rassurait: ce n'était pas comme ça dans les ESN "normales". C'était une boîte presse-citron. Un manager m'avait dit par exemple de ne pas trop mettre la pression sur telle personne car c'était un X junior. Rétrospectivement c'était amusant, à prendre au second degré. Je n'avais pas le système défensif et le cynisme requis pour survivre dans cette société à l'époque; j'étais jeune quoi. En tout cas, j'y ai participé au projet le plus intéressant techniquement que j'ai jamais fait. Elle était reconnue comme ça cette entreprise par les prestataires d'autres SSII: très intéressante techniquement mais avec une ambiance de fin du monde. A posteriori, j'aurais du jouer différemment, j'étais peu au courant des enjeux humains. Il y avait bien entendu beaucoup de positif dans cette boîte. Je conseillerais à un junior d'aller, si possible, chez un éditeur de logiciel plutôt qu'une ESN. D'ailleurs le rêve à l'époque des salariés de cette société c'était d'être embauché par un client. Program transformationOu comment des programmes peuvent changer du code. Par exemple pour faire des réusinages automatiques et sans danger.De ma propre expérience, j'ai surtout utilisé des scripts Shell Git Bash pour faire cela. Avec:
Autre exemple où j'ai utilisé find et grep -v pour virer une annotation java devenue inutile. Grands principes de développementKISSKeep It Simple, Stupid
DRYDo not Repeat Yourself
Principe de DemeterNe pas appeler directement un ami d’un amiToute méthode M d'un objet O peut simplement invoquer les méthodes de
Principe SOLID
The End of this article"The End" des Doors |