The main point is: just because my software operates in a domain with concepts of eg. Customers and Orders, doesn't mean there is any Customer class, with methods associated with it. Quite the opposite: the Customer concept is just a bunch of data in a tabular form in one or more DataStores, and “business logic” code manipulates the data directly.

Effectivement, je vois pas bien en quoi c'est contradictoire avec la POO.
L'auteur n'a visiblement pas pratiqué depuis qu'il a appris Java à l'université et ne s'est pas intéressé aux pratiques de l'industrie. Des basiques comme SOLID, DDD (et les Bounded Contexts), 12factor... Les exemples qu'il cite ont l'air d'être tiré d'un "Applet Java pour les nuls" 😁

On peut bien sûr implémenter de la business logic en mode FP et en utilisant que des fonctions pures, si on a un langage qui s'y prête, mais ce n'est pas antinomique en soit avec une modélisation en objets.

Je pense qu'il fait surtout référence aux "abus" de la POO (par ex, la prolifération de classes pour coller aux concepts ou abstraire inutilement certaines choses), et qui mènent à du code de moindre qualité, mais "typiquement accepté" parce que pour beaucoup de (mauvais ?) développeurs POO, l'encapsulation est *la* métrique de qualité.

Lors de mon cours séjour dans le privé, j'ai eu (en tant qu'analyste) la charge de documenter une application réalisée par un consultant (et totalement non-documentée, youhou !). Le code était fonctionnel, et je suis sûr qu'un développeur lambda y retrouverait ses petits, mais c'était une véritable horreur, à base de centaines de classes "inutiles", et des design patterns dans tous les sens (le moindre truc était réalisé via une factory et de l'injection de dépendances, rendant le code impossible à "lire/comprendre" sans un IDE pour naviguer dedans). Quand j'avais fait remarquer la complexité inutile de l'application (et la difficulté à l'étendre !), on m'avait dit que c'était "comme ça qu'il fallait faire" parce que ça permettrait à n'importe quel dev de reprendre le projet facilement (ironiquement, les devs avec qui je bossais n'arrivaient pas à implémenter le moindre correctif/feature sans tout casser ).

Je pense que le gros problème de la POO (ou de Java, dirons-nous) dans le milieu "moyen" (grosses boîtes avec plein de devs et un turnover relativement important), c'est que les devs crachent du code bourré de design patterns "juste parce que ça facilite leur travail", un peu en mode brainless, sans penser à l'architecture ni à la maintenance future du logiciel. D'un autre coté, on va par leur reprocher : là où j'étais, clairement leur job était plutôt de faire de la dactylo de code que de réellement réfléchir à comment coder correctement.

GuybrushLors de mon cours séjour dans le privé, j'ai eu (en tant qu'analyste) la charge de documenter une application réalisée par un consultant (et totalement non-documentée, youhou !)

Un code bien écrit est censé s'auto-documenter.
La documentation - par définition - n'est jamais à jour. Jamais!
Au moindre correctif la documentation est obsolète.

Ici, on n'utilise pas la POO avec des méthodes sur les objets. Les objets n'ont que des propriétés.
Pour reprendre son exemple, on aurait un composant CalculateurTourCombat(Monstre m, Joueur j) qui vérifierait si l'un ou l'autre a touché, les points de vie, la mort, etc. Mais pas sur les objets.

C'est la base aussi pour pouvoir écrire des tests-unitaires.

Guybrushc'est que les devs crachent du code bourré de design patterns "juste parce que ça facilite leur travail", un peu en mode brainless, sans penser à l'architecture ni à la maintenance future du logiciel

Surtout quand tu bosses dans des boites où tu travailles selon des sprints.
Normalement, à la fin de l'itération (1 à 3 semaines), le code que tu as produits passe dans la catégorie "Legacy", tu n'es plus censé revenir dessus et le modifier (sauf bug).
Et le but d'un sprint est de produire de la valeur ajoutée pour le client. Faire du refactoring ou changer le framework / l'architecture ne produit pas de valeur ajoutée pour le client.

Oui, on retombe facilement dans le travers: c'est pas grave si il y a plus de lignes de codes, de toutes façons les CPU sont de plus en plus puissants, pas la peine d'optimiser.

GuybrushJe pense qu'il fait surtout référence aux "abus" de la POO (par ex, la prolifération de classes pour coller aux concepts ou abstraire inutilement certaines choses), et qui mènent à du code de moindre qualité, mais "typiquement accepté" parce que pour beaucoup de (mauvais ?) développeurs POO, l'encapsulation est *la* métrique de qualité.

Ben dans ce cas l'orientation de l'article est curieuse, puisqu'il utilise un exemple où sciemment il brise la separation of concerns pour en déduire "vous voyez bien qu'on peut pas séparer les concerns". Si c'est pour dire qu'en faisant de l'objet, on est pas OBLIGÉ de séparer les concerns, oui bon ben d'accord. Mais des paradigmes qui enforcent du code de qualité quelque soit le programmeur, j'en connais aucun

Enfin on a tous nos moments de faiblesses, on a bien le droit d'être de mauvaise foi de temps en temps

PetitCalgonUn code bien écrit est censé s'auto-documenter.

Le code Python est souvent assez explicite pour être "auto-documenté", et c'est normal vu le coté dynamique du langage qui nécessite d'être plus explicite au niveau du code, puisqu'on ne peut pas l'être via le typage (même si les annotations de type permettent, dans une certaine mesure, de combler ça). Mais je n'ai que rarement vu des codes Java suffisamment explicites que pour se permettre de ne pas le documenter

PetitCalgonLa documentation - par définition - n'est jamais à jour. Jamais!
Au moindre correctif la documentation est obsolète.

Oui et non. Ca dépend de la rigueur avec laquelle tu maintiens ta documentation, et ça dépend aussi des "outils" que tu utilises. En Python, par exemple, tu as des modules tels que doctest qui te permettent de tester directement le code repris en exemple dans la documentation du code. Tu peux aussi utiliser des trucs comme Sphinx (une sorte de générateur de documentation HTML) qui peuvent te tester à la volée les morceaux de code ou d'autres choses que tu précises dedans.

Même si c'est pas parfait, et certainement pas suffisamment "couvrant" que pour être confiant sur la doc, ça permet d'éviter certains problèmes assez tôt (et ça fait aussi office de tests fonctionnels pour le coup). Bon, j'avoue que je me suis déjà retrouvé avec des morceaux de docs pas à jour (alors que je fais gaffe à ça) malgré ces outils (et le pire, c'est que personne parmi les utilisateurs ne l'a remarqué, alors que ça concerne un point important du tutoriel, principal point d'entrée dans l'usage de la lib).

Par ex, un des projets que je maintiens propose de la gestion d'intervalles. C'est pas du tout un gros projet, donc j'ai pas "investi" dans Sphinx, mais la documentation tient dans un document Markdown dont les morceaux de code sont automatiquement extraits et testés (je me sers de doctest d'une façon un peu atypique pour ça, mais ça marche). Ca me permet de m'assurer que la doc reste compatible avec le code, dans une certaine mesure. Pour info, le projet est ici : github.com/AlexandreDeca…

PetitCalgonC'est la base aussi pour pouvoir écrire des tests-unitaires.

Dans le cas du projet dont on m'avait chargé lors de mon séjour dans le privé, il n'y avait pratiquement aucun unit tests, à part des tests bêtes automatiquement générés pour des getter/setter. Je suis de plus en plus adepte du TDD (test driven development). Si le code ne peut pas être testé "morceau par morceau", c'est qu'il est probablement mal écrit. Et dans le cas où c'est "trop complexe" de mettre toute la machinerie en route juste pour tester une feature, y a les mocks (et j'avoue que les mocks en Python, c'est super simple et plaisant à utiliser

PetitCalgonEt le but d'un sprint est de produire de la valeur ajoutée pour le client. Faire du refactoring ou changer le framework / l'architecture ne produit pas de valeur ajoutée pour le client.

Pour sûr. D'où l'importance de bien réfléchir à cette dernière avant de se lancer tête baissée dans le crachat de code

Pour la documentation tu as GhostDoc submain.com/products/gho… pour Visual Studio qui d'un simple Ctrl + Shift + D il te génère la documentation.
Si tu es pas content, tu renommes ta fonction, un nouveau Ctrl + Shift + D et le commentaire se met à jour.

GuybrushCa dépend de la rigueur avec laquelle tu maintiens ta documentation

Perte de temps inutile.
Il vaut mieux faire attention au nommage de tout ce que tu utilises dans ton code pour que ce soit auto-documenté plutôt que de faire de la documentation.
Une variable locale doit aussi bien être nommée qu'une fonction, pas de i, a, n, v je ne sais quoi !

GuybrushJe suis de plus en plus adepte du TDD (test driven development)

Excellent !

GuybrushSi le code ne peut pas être testé "morceau par morceau", c'est qu'il est probablement mal écrit.

Oui !

Guybrushy a les mocks

Absolument !

Mais l'idée est correcte, écrire des composants avec de la dépendance d'injection, et donc possibilité d'utiliser des mocks!

GuybrushD'où l'importance de bien réfléchir à cette dernière avant de se lancer tête baissée dans le crachat de code

Oui et non, bien réfléchir oui, mais pas au point de faire plusieurs sprints d'architectures avant de commencer.
Chaque sprint doit produire de la valeur ajoutée pour le client.
Chaque objectif doit être atteignable pendant le sprint et donc suffisamment petit.
Et l'objectif contient la réflexion + l'écriture de l'architecture + le code himself + les tests (qui sont du code productif)

Justement les tests servent aussi de documentation, car en consultant les tests, on peut comprendre comment un composant doit être utilisé / appelé.

PetitCalgonPerte de temps inutile.
Il vaut mieux faire attention au nommage de tout ce que tu utilises dans ton code pour que ce soit auto-documenté plutôt que de faire de la documentation.
Une variable locale doit aussi bien être nommée qu'une fonction, pas de i, a, n, v je ne sais quoi !

Ok, mais y a des situations dans lesquelles ton code a beau être explicite, si tu documentes pas, ça reste obscure (ou une perte de temps de lire tout le code pour comprendre ce que fait la fonction, même si elle est clairement codée . Quand je parle "documentation" (sous-entendu du code), je parle d'une ou deux lignes qui expliquent ce que ça fait, pas d'une demie page de Javadoc comme on en voit souvent En Python, je documente en fonction de la complexité :
- Soit je ne documente pas parce que le nom de la fonction ainsi que les paramètres sont assez explicites;
- Soit je documente d'une seule ligne pour décrire ce que fait la fonction (au cas où) et c'est compréhensible parce que les variables/contextes/co sont des "mots" repris dans la phrase descriptive;
- Soit je fais ça, et j'ajoute une ou plusieurs lignes pour les "cas particuliers" (par ex, j'ai une fonction qui "bind" des événements sur un composant, et ces événements sont prédéfinis. Bah la doc de la fonction qui bind contient la liste des événements).
- Et si les paramètres sont "vicieux" (= pas explicites, ou explicites mais peuvent conduire à une mauvaise interprétation), j'ajoute des annotations de type (soit dans le code depuis Python 3, soit sous forme de doc en suivant l'une des conventions supportées en "standard" par les outils de docs).

Si j'ai une doc qui fait plusieurs paragraphes, c'est souvent parce que la documentation "en ligne" (via Sphinx & ReadTheDocs par exemple) s'en sert directement (on peut importer la doc de certains objets python directement), et tant qu'à faire, je préfère que la doc soit avec le code qu'ailleurs

PetitCalgon

GuybrushJe suis de plus en plus adepte du TDD (test driven development)

Excellent !

Un de mes "gros" projets (le simulateur de statecharts + paradigme de tests) m'a vraiment ouvert les yeux sur TDD (et aussi sur l'importance des unit tests). Je ne compte pas le nombre de fois où j'avais l'impression que ça "allait", et que mes suites de tests m'ont fait comprendre le contraire, pour des cas auxquels je n'aurai probablement pas pensé si les tests n'étaient pas là pour couvrir anticipativement ces situations (parce que souvent, ce sont les "vieux tests" qui captent le mieux les erreurs ; les "nouveaux tests" étant surtout là pour le feature coverage et les "border cases" envisagés).

PetitCalgonMais l'idée est correcte, écrire des composants avec de la dépendance d'injection, et donc possibilité d'utiliser des mocks!

Je ne sais pas comment ça se passe dans les autres langages, mais le mock en Python est vraiment très simple (le coté "dynamique" du langage aide bien). Tu peux le créer de toutes pièces (et faire en sorte que chaque opération, même chaînée, retourne un mock également), faire un hybride (comportement cloné d'un objet existant, mais en "écrasant" certains comportements spécifiques lors d'appels spécifiques ou non), .... tu peux faire ça "à la main" (création de l'objet pour l'injecter manuellement), ou "à la volée" (pour écraser le comportement d'un module externe, ou d'un objet externe par exemple). Vraiment sympa. Le "hic", c'est que parfois ça devient quand même complexe de mettre en place un test fonctionnel en mockant de grosses parties du comportement (et on perd la couverture de ces parties, du coup).

PetitCalgonOui et non, bien réfléchir oui, mais pas au point de faire plusieurs sprints d'architectures avant de commencer.
Chaque sprint doit produire de la valeur ajoutée pour le client.

Je n'ai pas assez l'habitude de ces pratiques pour avoir un "vrai" avis dessus, malheureusement. Mais je ne pense pas qu'il soit prudent de sacrifier une bonne réflexion initiale (mais faut pas réinventer le monde à chaque fois non plus), à moins que le produit "à la fin des sprints" soit juste un prototype qui va être ré-écrit partiellement ou totalement pour éliminer cette fameuse technical debt.

Tiens, c'est typiquement comme ça que ça marche:
http://www.commitstrip.com/fr/2018/11/26/if-its-not-broken/

Tu ne touches que ce que tu dois toucher, pas plus.

Concernant le sprint, rien ne t'empêche effectivement de proposer plus de réflexion, plus d'architecture.
Mais l'idée maîtresse est le MVP: minimal viable product.
Tu ne codes que ce qui est décrit dans l'objectif, tu n'en fais pas plus.

Exemple: tu dois faire une liste d'utilisateur
Tu fais une liste d'utilisateur, point. Tu ne codes pas la suppression, pas l'ajout, pas la modification, pas le tri.
Ca sera des UserStory séparées que le PO aura priorisé à sa guise.
Et si tu n'avais pas de base de données, tu inclus dans la UserStory l'accès à la BDD, mais dans un premier temps, seulement la lecture des utilisateurs, pas plus. (et donc pas encore de notion de IsDirty ou je ne sais quel mécanisme dont tu n'as pas encore besoin)

Au sprint suivant, si il faut modifier et enregistrer les utilisateurs, il faudra ajouter à l'archi la possibilité de taguer un utilisateur à mettre à jour, voir une concurrence de donnée, etc.

Mais pareil, tu ne fais que le nécessaire, et tu construit tout doucement ton appli comme ça, jusqu'à avoir une grosse appli.
Évidement au départ, tu essaies de faire des choix qui ne vont pas trop chambouler plus tard ton archi, tu essaies de ne pas de mettre des battons dans les roues dans le départ pour plus tard.

Je veux monter en compétence sur le TDD depuis un moment, mais j'avoue que pour le moment je manque d'exemple concret. Vous auriez de la bonne lecture sur le sujet ?
J'essaye de mettre cela en place au boulot, profitant d'être seul pour le moment pour mettre en place les bonnes pratiques. Je n'ai déjà pas le temps, donc ça sera encore pire quand j'aurais monté mon équipe :D

De bons guides ? Des explications concrêtes ?

Je sais pas comment ça marche dans les autres langages de programmation que le C#, mais le principe est simple:
- tu écris la définition de la fonction et elle n'exécute encore rien
- tu écris le premier test qui décrit ton cas métier
- tu exécutes le test, les données en entrée et en attendu sont correct, mais la fonction étant vide, le test échoue
- tu modifies la fonction pour que le test passe vert
- tu écris un nouveau test qui décrit un 2ème cas métier
- tu exécutes le test, oh il échoue !
- tu modifies la fonction pour que les 2 tests passent vert
etc.