@Ewi et @Histrion vous dites que vous récupérez des gros projets spaghetti et en même temps vous êtes tout les deux pour les micro framework, c’est un peu contradictoire
Pourtant les micro framework, et leur faible
structuration, c’est la porte ouverte à des projets anarchiques qui partent en vrille, non, et qui ne peuvent pas grandir ou de façon désordonné ?
La seule chose qui ne me paraît pas contradictoire dans votre point de vue sur les micro framework et vos constats lors de récupération de projet foireux, c’est lorsque un micro projet part en vrille, il n’impacte pas le reste des autres projets : il se casse la gueule tout seul et on peut se concentrer sur le bordel local sans remettre en cause le reste ni reculer devant l’énormité de la tâche.
C’est surtout parce que faire du light avec beaucoup de liberté, c’est ce qui m’amuse et que la mode en ce moment c’est de vendre de « l’agilité »(ce qui me nourrit).
Ton projet part en live quand tu perds trop d’ancien, quand tu ne prends pas le temps de le maintenir, quand tu en fais un mouton à 5 pattes, etc. Et ça c’est vraiment indépendant du langage ou des outils.
La réalité c’est que les clients embauches des dévs pas chers, qui du coup n’ont que des compétences très médiocres sur les gros frameworks, et font encore plus de la merde que si on leur donnait des outils moins « dangereux ». Le nombre de trucs immondes que j’ai vu codés en J2E, ça m’a vacciné. La réalité c’est que les bons dévs n’ont pas besoin d’un framework pour savoir ce qu’il faut faire. Le framework n’est qu’un gain de temps, ou de lignes de codes. Et de toute façon dans l’écrasante majorité des projets ce temps gagné est perdu vingt fois ailleurs.
Je suis la conversation de loin et je ne dis pas grand chose, mais tous ces posts sur les micro-services ça me fait bouillir.
Déjà rien que le principe que d’écrire son UI avec un framework full JS et de devoir développer toute une couche de services REST ou GraphQL en dessous par défaut, sans même avoir envisagé de faire plus simple ça me fait pousser des boutons … alors les micro-services c’est la crise d’urticaire
J’en profite pour vous pousser un petit article que j’ai écrit il y a quelques mois sur le sujet :
Oui mais pourtant Django me paraît du même niveau de complexité, voire moins, que cakePHP, et beaucoup moins complexe que Symfony. Déjà ça te paraît trop structurant ?
Comprends-tu mon besoin d’un peu de structure vu que, à part un petit projet en cakePHP, je n’ai jamais utilisé de framework. Je vais oublier des trucs ou réinventer la roue pour rien.
Ou alors il faut que je tombe sur un projet Flask, sur Github, qui me serve de ligne directrice.
Tu en connais ? Avec donc un framework IHM et template (Vue (ou React)), et un gestionnaire de CRUD avec gestion des forms. Non pas que ça me fasse peur de réinventer la roue, je l’ai fait en R Shiny, mais je voudrais que ça soit davantage maintenable, que ça ne soit pas du développement uniquement à façon par moi, et que je puisse entrer dans d’autres projets comme dit @damaki
Ah, un réveil !! Il y avait Kaa (@Histrion) , le serpent du livre de la jungle, qui me disait « Aie confiance @@ ».
Vi. Si encore il y avait des recommandations, des lignes directrices dans ce domaine, et pas que ça soit chacun pour soi avec sa cuisine. Je ne suis pas pour des recommandations étouffantes mais il en faut un minimum sur ce qui n’est pas géré par le micro framework ou alors avoir un framework pas micro.
Dans ton article tu parles de Docker. J’ai dé-Docker-isé une application complexe tierce, trouvée sur Github, pour qu’elle soit plus facilement interfaçable avec mon application R Shiny, et qu’eventuellement je puisse faire du support au téléphone, sans que mon utilisateur se noie dans les principes de Docker.
« * If you want your micro-services to talk together, you’ll have to tie them up with APIs (whereas a simple function call would have been much simpler and faster).»
Ca c’est juste les gens qui comprennent pas que le micro service est là pour être un délinéateur de ownership. C’est pour grandir avec une organization. Trois péquins et douze micro services c’est une abomination. 5 équipes de 8 et 12 micro services c’est potentiellement propre. Si il y a pas de séparation aujourd’hui ou court terme de a qui appartient quoi vous vous trompez d’outil.
Correct. Que tu le veuilles ou pas tu ship ton org. Donc autant faire ça propre. Et les énormes équipes sont pas productives. Une équipe de plus de 8 à 10 personnes c’est généralement une mauvaise idée. Donc au final… mais faire du micro service à outrance dans une boîte de 10 personnes c’est teubé
Ça fait longtemps que je n’ai pas bossé sur de gros projets à plus de 10, mais je me dis qu’on doit bien pouvoir délimiter proprement des périmètres avec des application boundaries propres sans pour autant faire du microservice.
Faire des sous-projets, des libs ce que tu veux sans forcément transposer ça en unités de déploiement.
Je dis pas que les micro services c’est à jeter tout le temps (idem pour Docker ou encore Kubernetes qui sont des bijoux). Je trouve juste lourd que le moindre projet sorte l’artillerie lourde sans faire preuve de bon sens (quand je vois ce que Doctolib arrive à faire avec un gros monolithe Ruby on Rails, ça peut en faire réfléchir beaucoup)
Houla oui ! Attention de mon côté quand je parlais de micro-service, je parlais d’un micro-service, qui serivrait de périmètre pour s’auto-former à telle ou telle techno. Il y a une grosse différence de maturité entre en faire un, pour comprendre, voir en tirer quelques bonnes idées, et commencer à en gérer en masse.
Grosse alerte sur la hype Docker : à éviter par défaut comme outil pour faire de la production. Ça augmente la complexité d’au moins un ordre de grandeur par rapport aux anciennes architectures. Docker, c’est très bien pour développer, prototyper, intégrer. Mais il faut avoir de véritables besoins de scalabilité/découpage, et les reins très solides pour en faire une techno d’infrastructure de prod.
Nope. Je dis « fais ce que tu veux faire ». Tu as toutes les infos dans ce thread pour te faire une idée de ce que sont tes options de formation. Mais il n’y a que toi qui peut prendre une semaine ou deux de ton temps pour tester, et tâtonner, et décider si oui ou non telle ou telle techno tu as envie de la pousser plus loin. Ou bien tout jeter et repartir sur une autre techno.
Tu n’arrêtes pas de parler d’Elixir. En fait quand j’ai débuté en Python, il y a 10 ans, c’était pour être précis du Jython, c’est-à-dire l’implémentation de Python 2.7.x sur des libs java, celles embarqués par Oracle Data Intégrator où on pouvait brancher des scripts Python. (Mais je n’ai pas 10 ans d’expérience en Python, c’était une petite mission).
Et je n’arrêtais pas de parler de Jython que personne ne connaissait . (Il suffisait de leur rappeler que c’était du Python dans un 2ème temps, mais il y a 10 ans en BI ce dernier n’était pas non plus très connu).
Et c’est ce genre de langage qui m’a redonné envie de développer.
En apprenant R, j’ai entendu parler du langage Julia, et tu m’as appris l’existence d’Elixir qui est similaire dans sa philosophie. Et je crois que Ruby fait partie de la même famille: en même temps très puissants, propres, et non verbeux. (Après ils ont chacun leurs points forts et points faibles, ils ne sont pas interchangeables aussi facilement)
Puisque tu insistes, laisse moi te parler d’Elixir
C’est un langage à la croisée des chemins : il partage une syntaxe très moderne et expressive comme peut l’avoir Ruby avec une plateforme d’exécution (pense à la JVM dans le monde Java) extrêmement éprouvée qu’est Erlang.
Erlang ca peut sembler pas très connu, mais c’est un truc qui a plus de 20 ans et qui a été développé par le monde des télécoms (Er comme Ericsson) pour gérer du code avec beaucoup de concurrence de manière très fiable (c’est à dire pas avec de la synchro de thread dans tous les sens comme on pouvait faire en C++ ou d’autres langages plus modernes). Aujourd’hui l’utilisation la plus connue de Erlang est Whatsapp dont le serveur est développé entièrement en Erlang, mais il y a aussi Discord, Heroku ou encore des morçeaux de World of Warcraft.
Et Elixir est encore plus costaud avec Phoenix (qui est un peu le Django de Elixir) qui permet de faire des apps webs de manière très productive. Des stacks webs il y en a bcp dans pas mal de langages (Python Django, Ruby on Rails, PHP Laravel, NodeJS Express …) mais là ou Elixir dénote c’est que c’est un langage 100% fonctionnel : c’est pas facile à expliquer en qq lignes sur un forum, mais c’est un principe de programmation qui rend le code beaucoup plus fiable, moins sujet aux bugs et surtout très facilement parallélisable (et avec le nombre de core dispo sur nos CPU ce n’est pas du luxe !)
Voilà j’espère que j’aurais donné envie à quelques un de creuser un peu Elixir En tout cas ça fait maintenant 4 ans que je m’en sers fulltime au boulot, et je ne regrette pas un seul instant.
J’ai appris à programmer avec OCaml et Lisp niveau fonctionnel, jai les bases. Autant d’un point de vue pédagogique (et pour la beauté du code), je comprends, autant dans un environnement de production, j’ai du mal à voir les avantages (et j’en ai jamais rencontré hors de mes études). Qu’est ce qui te pousse à utiliser ça?
Et pour la beauté du code, je ne peux que vous encourager à regarder Pharo
C’est marrant j’avais le même parcours et apriori que toi : j’avais adoré mes projets caml à l’école (10 ans avant ma découverte d’Elixir) tout en me disant que la prog fonctionelle était un délire d’universitaire inapplicable dans la vraie vie.
Puis j’ai eu un déclic en découvrant … React. Je ne sais pas si tu connais cette techno, mais pour moi ça a révolutionné le développement de UI dans la sens ou la génération d’un écran web devient une fonction pure : f(state) -> UI.
Tu veux modifier ton écran ? Tu modifies le state et la fonction est réappliquée (ensuite React fait automatiquement le diff entre la nouvelle version et l’ancienne version de l’écran pour uniquement faire les qq updates qui vont bien sur ton écran). Avant de faire du React, lorsque je voulais faire une mise à jour sur un écran en JS, je faisais comme tout le monde à parcourir les ID de mon DOM avec JQuery, insérer des noeuds, mettre à jour des noeud …
Le code React apporte beaucoup de sérénité dans le sens ou tu n’as pas besoin d’envisager tous les cas possibles : il suffit de coder une seule fonction qui transforme un état en écran. J’ai trouvé que mon code JS était beaucoup moins sujet aux bugs qu’avec jQuery.
Et pour la suite, j’ai finalement découvert qu’une application Web (serveur) c’était finalement qu’une grosse fonction : f(http request) -> http response. Et ensuite tout le code consiste à découper cette grosse fonction en plein de sous-fonctions.
Je vois plusieurs avantage de la programmation fonctionnelle stricte (je dis stricte parce qu’en Elixir c’est fonctionnel obligatoire, en comparaison à d’autre langages comme JS ou Ruby où tu peux faire cohabiter du code fonctionnel et non fonctionnel, et du coup tu ne peux pas en tirer tous les bénéfices):
lorsque tu appelles une fonction il n’y a pas d’effets de bords : donc tu es certain que la fonction ne va pas modifier la propriété d’un autre objet dans ton dos ou pire, modifier une variable globale.! Tu veux ajouter un élément à un tableau ? Tu fais une fonction qui te retourne un nouveau tableau avec la nouvelle entrée, mais le tableau passé en paramètre reste inchangé (d’un point de vue mémoire c’est quasi indolore, car le tableau n’est pas dupliqué tout ca est juste un jeu de pointeurs). Comme en React, c’est un peu perturbant au début mais ça augmente considérablement la fiabilité de ton code.
qui dit fonction, dit tests automatisés facilités. Tu appelles ta fonction avec des paramètres et tu testes la valeur de retour, pas plus compliqué que cela. Et la testabilité est un enjeu majeur du développement (souvent ignoré par les devs juniors)
pour terminer le gros avantage, particulièrement bien exploité par Elixir, est le no shared mutable state (cf. pas possible pour une fonction de modifier une variable globale ou partagée par d’autres instances de ton code comme tout à l’heure). Ceci rend n’importe quel code exécutable immédiatement sur autant de threads que tu veux sans avoir à réfléchir une seule seconde aux potentiels conflits (2 threads qui lisent / modifient la même variable en même temps) car tes threads (Process en Elixir) ne partagent absolument rien. Je me sers régulièrement de cet aspect pour optimiser des gros traitements de données afin d’exploiter la totalité des 16 cores de mon serveur.
Je vous invite à essayer le style de programmation fonctionnel, c’est pour moi une vraie avancée ! (pas forcément en Elixir, vous pouvez faire vos armes en JS ou en Java avec qq bonnes librairies)
C’est un truc qui m’attire pas mal (au moins par curiosité), et j’en fait déjà un peu de temps en temps en JS ou Kotlin (sans aller jusqu’à utiliser Arrow pour le moment), mais en environnement pro il faut bien admettre que ça ne court pas les rues.
Si tu passes une équipe sur un langage purement fonctionnel, après il faut réussir à recruter les gens qui vont vouloir et être capable de bosser avec ce genre de techno. Vu comment c’est déjà compliqué de trouver des gens de qualité dans les technos mainstream…
Mais je rêve de pouvoir faire un vrai projet en Clojure un de ces jours…
et que la mode en ce moment c’est de vendre de « l’agilité »(ce qui me nourrit).
.
. (Il suffisait de leur rappeler que c’était du Python dans un 2ème temps, mais il y a 10 ans en BI ce dernier n’était pas non plus très connu).
niveau fonctionnel, jai les bases. Autant d’un point de vue pédagogique (et pour la beauté du code), je comprends, autant dans un environnement de production, j’ai du mal à voir les avantages (et j’en ai jamais rencontré hors de mes études). Qu’est ce qui te pousse à utiliser ça?