Tu as raison il faut préciser le contexte sinon on ne sait pas de quoi on parle.
Mon créneau c'est beaucoup de petites et moyennes (1 à 15K lignes de code très concis) applications web très spécifiques, dont certaines vont durer très longtemps et évoluer dans des sens non définis au départ et que je gère quasiment seul. Genre des gestion de chantiers qui commencent gérées au siege, puis par des agences, puis par des chefs d'équipe sur leur smartphone etc... Après ça sera une gestion de résidents d'une maison de retraite qui pointent leur repas, leur ménage etc. Ou bien un site de vente de livres, où les éditeurs se regroupent puis se séparent puis se regroupent à nouveau, un jeu en ligne, un service de calcul d'itinéraire... Je suis également admin sys de tout ça, cad quelque dizaines d'apps en cours. Et c'est chouette de rentabiliser sa passion :-)
Donc mon casse tête c'est de pouvoir réutiliser le maximum de composants pour ne pas réinventer et réapprendre la roue. A court terme un bon framework c'est royal pour moi, j'essaye souvent.
Mais sachant que les composants et frameworks vont avoir une durée de vie plus courte que certaines applis et qu'ils seront utilisés dans des contextes parfois très différents, il faut impérativement que j'évite les effets de bords, dans l'instant et sur la durée, qu'en faisant évoluer un composant ça n'impacte pas les autres mais qu'une ancienne appli puisse quand même en bénéficier facilement un jour.
Si j'avais utilisé des gros frameworks, j'aurai du en utiliser plusieurs en même temps dont certains qui n'existeraient plus. Imagine si j'avais à maintenir des applis Zope et Django en même temps avec une demande d'évolution vers les websockets ou une contrainte de perf...
En revanche, avec un micro framework comme Pyramid je trouve un outil qui me permet de remplacer progressivement des composants de mon framework perso sans avoir à changer une ligne de code de mon appli. Donc j'achète, au pire je revend plus tard, le coût de la manoeuvre reste faible. Je prend Pyramid comme exemple car la doc explique de manière très détaillée cette philosophie, qui plus est par un ancien de Zope qui connaît bien le domaine, ça vaut le coup d'être lu même si on ne l'utilise pas.
Je faisais l'analogie avec la philosophie Go dans le sens où les auteurs ont décidés d'accepter une fonctionnalité du langage que s'ils étaient tous d'accord. J'applique la même règle avec mes composants perso, pour en faire une lib que je vais partager il faut que toutes mes applis soient d'accord, même la plus ancienne. En attendant : "une petite copie vaut mieux qu'une grosse dépendance" (Rob Pike).
C'est sûrement pas universel mais c'est assez marrant de partager certains points de vue entre Google et un indep ! J'ai vraiment été surpris. De la même manière quand je me suis aperçu que je pouvais utiliser Python pour le boulot, un langage qui semblait fait pour les enfants !
[^] # Re: Go
Posté par wilk (site web personnel, Mastodon) . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 3.
Tu as raison il faut préciser le contexte sinon on ne sait pas de quoi on parle.
Mon créneau c'est beaucoup de petites et moyennes (1 à 15K lignes de code très concis) applications web très spécifiques, dont certaines vont durer très longtemps et évoluer dans des sens non définis au départ et que je gère quasiment seul. Genre des gestion de chantiers qui commencent gérées au siege, puis par des agences, puis par des chefs d'équipe sur leur smartphone etc... Après ça sera une gestion de résidents d'une maison de retraite qui pointent leur repas, leur ménage etc. Ou bien un site de vente de livres, où les éditeurs se regroupent puis se séparent puis se regroupent à nouveau, un jeu en ligne, un service de calcul d'itinéraire... Je suis également admin sys de tout ça, cad quelque dizaines d'apps en cours. Et c'est chouette de rentabiliser sa passion :-)
Donc mon casse tête c'est de pouvoir réutiliser le maximum de composants pour ne pas réinventer et réapprendre la roue. A court terme un bon framework c'est royal pour moi, j'essaye souvent.
Mais sachant que les composants et frameworks vont avoir une durée de vie plus courte que certaines applis et qu'ils seront utilisés dans des contextes parfois très différents, il faut impérativement que j'évite les effets de bords, dans l'instant et sur la durée, qu'en faisant évoluer un composant ça n'impacte pas les autres mais qu'une ancienne appli puisse quand même en bénéficier facilement un jour.
Si j'avais utilisé des gros frameworks, j'aurai du en utiliser plusieurs en même temps dont certains qui n'existeraient plus. Imagine si j'avais à maintenir des applis Zope et Django en même temps avec une demande d'évolution vers les websockets ou une contrainte de perf...
En revanche, avec un micro framework comme Pyramid je trouve un outil qui me permet de remplacer progressivement des composants de mon framework perso sans avoir à changer une ligne de code de mon appli. Donc j'achète, au pire je revend plus tard, le coût de la manoeuvre reste faible. Je prend Pyramid comme exemple car la doc explique de manière très détaillée cette philosophie, qui plus est par un ancien de Zope qui connaît bien le domaine, ça vaut le coup d'être lu même si on ne l'utilise pas.
Je faisais l'analogie avec la philosophie Go dans le sens où les auteurs ont décidés d'accepter une fonctionnalité du langage que s'ils étaient tous d'accord. J'applique la même règle avec mes composants perso, pour en faire une lib que je vais partager il faut que toutes mes applis soient d'accord, même la plus ancienne. En attendant : "une petite copie vaut mieux qu'une grosse dépendance" (Rob Pike).
C'est sûrement pas universel mais c'est assez marrant de partager certains points de vue entre Google et un indep ! J'ai vraiment été surpris. De la même manière quand je me suis aperçu que je pouvais utiliser Python pour le boulot, un langage qui semblait fait pour les enfants !