The faster you unlearn OOP, the better for you and your software dpc.pw/the-faster-you-un…
Mardi 27 novembre 2018 à 09:00
Cette discussion est en relation avec le billet suivant :
The faster you unlearn OOP, the better for you and your software dpc.pw/the-faster-you-un…
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.
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.
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 logicielSurtout quand tu bosses dans des boites où tu travailles selon des sprints.
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
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!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.
Au moindre correctif la documentation est obsolète.
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
GuybrushCa dépend de la rigueur avec laquelle tu maintiens ta documentationPerte de temps inutile.
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 mocksAbsolument !
GuybrushD'où l'importance de bien réfléchir à cette dernière avant de se lancer tête baissée dans le crachat de codeOui et non, bien réfléchir oui, mais pas au point de faire plusieurs sprints d'architectures avant de commencer.
PetitCalgonPerte de temps inutile.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é :
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 !
PetitCalgonUn 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).GuybrushJe suis de plus en plus adepte du TDD (test driven development)Excellent !
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.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.
Chaque sprint doit produire de la valeur ajoutée pour le client.
1996-2024 — Lexpage v4 — GPLv3 (sources)
page générée le 14 novembre 2024 à 18:22:27