Accueil 🔺 🎲

Idées sur le développement

Quelques 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 programmeur

Tout 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:
  • Maintenir, c'est se punir.
  • Commenter, c'est radoter.
  • Démontrer, c'est folâtrer.
  • Spécifier, c'est tyranniser.
  • Insister, c'est s'enfoncer.
  • Releaser, c'est se résigner.
  • Suivre les spécs, c'est s'humilier.
  • Trouver un bogue, c'est faire preuve de méchanceté.
  • Déboguer, c'est manquer de foi.

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/Talkers

Alors 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 Overflow

qui 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 code

c'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 types

Il 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és

Le 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. Martin

Dans 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.

RTFM

Read 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 class

En 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 conscience

Les 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érimentale

Je 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ègues

J'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.
  • Cool, merci d’avoir fixé les inputs des batch (vous noterez les 5 mots français de cette phrase :D )
  • Je peux être fin, mais là j'ai pas envie aujourd'hui.
  • Est-ce que je peux remplacer Mail par Courriel comme le demande l'Académie française ?
  • Ma foi interdit tout avatar.
  • Le modèle Git est un graphe orienté, acyclique et connexe de commits.
  • Le copié-collé c'est le meilleur ennemi du développeur
  • Le meilleur ennemi du développeur c'est le développeur lui-même.
  • Demande à ta brosse à dent.
  • On va rester sur un échec comme ça demain on sera bien stimulé.
  • Il faut envisager le cas où tout va bien et en profiter à ce moment-là.

Les étrangetés de java

Vous 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
false
Java 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:

  • si vous avez le malheur de faire un == entre deux Integer, ça pourrait marcher sur votre poste mais en production ça peut échouer si les entiers sont grands. Après les outils comme Sonar vont vous crier dessus si vous faites ce genre de choses.
  • ça ne doit pas aider la JVM à optimiser et virer Integer pour ne se servir que de l'int.
  • si vous avez à créer plein de grands entiers, eh bien vous aurez deux comparaisons gratuites à chaque génération d'Integer.

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 plaisantine

J'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.😀

ChatGPT

ChatGPT 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 étonnant

J'é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:

  • Sonar qui n'aime pas les guillemets sur les chaînes d'un caractère et m'a donné l'habitude d'écrire ' ' au lieu de " ";
  • un vilain tachon qui a du me jeter un sort par pure méchanceté gratuite.
Moi, je suis innocent comme l'agneau qui vient de naitre. Ce bogue pourrait être utilisé en test de recrutement en rajoutant du code pour compliquer le truc et le rendre moins évident.

Moulinette de génération de code

Un 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 informatique

La 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 informatique

Rien 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-shahar

Il y a un chapitre sur la vie professionnelle. Il regroupe tout dans un acronyme 'SPIRE'.
  • S pour spiritualité; non pas la religion mais plutôt votre travail a-t-il un sens autre que la paie au bout du mois? Si oui, vous serez plus heureux.
  • P pour physique: faites-vous de l'exercice? Restez-vous des heures assis devant votre écran sans vous lever du tout? Dormez-vous bien et suffisamment?
  • I pour Intellectuel; ça, ça va dans le développement, il y a toujours des challenges intellectuels. Êtes-vous curieux, apprenez-vous de nouvelles choses?
  • R pour Relationnel. Avez-vous des relations cordiales avec vos collègues? Avec le Covid et le télétravail c'est moins évident de nos jours de socialiser.
  • E pour Émotionnel. On a tendance à 'écraser' les émotions dans le travail sauf la colère pour un chef. Ce n'est pas si sain que ça.
Bon ce livre n'est qu'un avant-goût de tout ce qu'on pourrait dire sur le bonheur mais l'acronyme 'SPIRE' me semble une bonne chose et est facile à mémoriser.

Optimisations de base de données

Il 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 transformation

Ou 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:

  • iconv : conversion d'encodages;
  • sed : recherche/remplacement de texte;
  • find : trouver des fichiers source dans une arborescence;
  • mv (pour écraser le fichier source avec le fichier temporaire transformé).
Et bien sur bash, j'ai ainsi transformé des pages JSP en changeant leur encodage de ISO-8859-1 en UTF-8.

Autre exemple où j'ai utilisé find et grep -v pour virer une annotation java devenue inutile.

Grands principes de développement

KISS

Keep It Simple, Stupid
  • Faire les choses le plus simplement possible.
  • Un programme simple est plus facile à comprendre et à relire
  • Mais faire simple est compliqué
  • « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément » de Nicolas Boileau
  • Ne pas confondre ‘facile’ et ‘simple’: quelque chose peut être simple comme l’addition binaire mais si vous ne savez pas le faire, ce n’est pas facile. Il peut aussi être plus facile d’écrire du code compliqué que du code simple.
  • La simplicité renforce la maintenabilité dans un univers toujours changeant.
  • Supprimez tout code inutile, tout code mort pour simplifier
  • Principe YAGNI “You Aren’t Gonna Need It”: si le code ne sert pas MAINTENANT supprimez-le tout de suite
  • Ajoutez juste la complexité vraiment utile aujourd’hui

DRY

Do not Repeat Yourself
  • Éviter de répéter le même code à plusieurs endroits dans un programme.
  • Déplacer le code redondant dans une fonction.
  • Un des buts de ce principe est de faciliter la maintenance du programme.
  • On peut utiliser des générateurs de code pour avoir des redondances à un seul endroit
  • Exemple de redondance: HBM Hibernate sur les noms de propriétés dans l’XML et le code
  • Instabilité du développement
  • Chaque élément de connaissance doit avoir une représentation UNIQUE, NON AMBIGUË, OFFICIELLE dans un système
  • La question n'est pas de savoir si vous vous rappellerez d’une duplication, mais de savoir quand vous l’oublierez.
  • Devinette : qu'est-ce qui est pire que l'absence de commentaires ? C'est la présence de commentaires obsolètes.
  • Plutôt générer la documentation à partir du code.

Principe de Demeter

Ne pas appeler directement un ami d’un ami

Toute méthode M d'un objet O peut simplement invoquer les méthodes de

  • O lui-même
  • les paramètres de M
  • les objets que M crée/instancie
  • les objets membres de O
Le logiciel sera plus adaptable et maintenable. Mais il y aura plus de code à écrire avec de petits wrappers.

Principe SOLID

  • (Single responsibility principle): une classe, une fonction ou une méthode doit avoir une et une seule responsabilité
  • (Open/closed principle) une entité applicative (classe, fonction, module ...) doit être fermée à la modification directe mais ouverte à l'extension
  • (Liskov substitution principle) une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme
  • (Interface segregation principle) préférer plusieurs interfaces spécifiques pour chaque client plutôt qu'une seule interface générale
  • (Dependency inversion principle) il faut dépendre des abstractions, pas des implémentations

The End of this article

"The End" des Doors
🢁 🎲