Je suis tout à fait d’accord avec ta vision du monde réel. Je travaille dans
une PME et en effet, nous faisons ‘avec’ les développeurs que nous avons,
et les compétences qu’ils possèdent. C’est compliqué opérationnellement parlant
de gérer la transition vers une nouvelle techno.
Quand à virer ses équipes sous prétexte qu’elles ne seraient pas suffisamment
adaptables comme cela a été suggéré dans une réponse à ton post, c’est peut être
faisable dans les Sims édition développeur, dans la réalité c’est plus
compliqué
----- Message d’origine -----
De: pierrederome [email protected]
Env: lundi 4 février 2008 19:54
À: Railsfrance [email protected]
Objet: [RailsFr] Re: Appel à argument et info : contrer les sceptiques
Ruby on Rails.
bonjour,
j’ai choisi Ruby on Rails pour mon projet actuel de services Web grand
public. J’étais CTO de Club-Internet jusqu’à récemment.
Je crois qu’il ne faut pas trop argumenter sans bien en peser les
implications. Les forces de ROR, on les connait, pour les “preuves qui
restent à faire”, je crois qu’il faut effectivement donner le temps au
temps et ne pas promettre que tout va bien se passer… Certains
arguments ne doivent pas être contrés par des mots, mais plutôt par
des résultats concrets et visibles.
Dans une boîte de taille moyenne à grosse, il n’est pas raisonnable de
lancer de grands projets de développement sur des technos aussi
récentes et si peu éprouvées. On a des équipes habituées à des
environnements de développement précis, et on sait assez bien en
combien de temps,avec quel niveau de qualité, et de performance on
fera tel ou tel projet. Les projets sont aussi très souvent des
extensions ou des évolutions de systèmes existant, pour lesquels on ne
va pas changer la techno en cours de route. Je crois aussi qu’adapter
des bases de données existantes à Rails doit être assez pénible.
Ceci étant, dans ce type de boîte, on a aussi régulièrement de
nouveaux projets de taille petite à moyenne relativement indépendants
des SI existants, avec seulement des besoins d’interface. C’est sur ce
type de projet qu’il est pertinent d’introduire de nouvelles technos.
Les arguments du développement agile, et DRY ont de quoi séduire tout
CTO, mais dans un contexte où on gère les risques: i.e. projet de
taille petite/moyenne, avec pas trop de dégats si les perfs ne sont
pas immédiatement au rendez-vous (l’exemple donné dans un post
précédent de faire une maquette en ROR est pas mal; et les maquettes
bien faites ont tendance à évoluer en produit final plutôt que
disparaître). Après, ROR fera ses preuves tout seul…
Après, il ne faut pas sous-estimer non plus la difficulté à faire
changer de techno des développeurs experts en PHP ! Mon expérience est
qu’il y a une courbe d’apprentissage non négligeable que tout le monde
n’a pas nécessairement envie de suivre… même si pour ma part, je
trouve que ça en vaut la peine.
sinon sur la liste d’arguments contre:
- performances faibles ou inconnues
- c’est déjà assez difficile de trouver de bons développeurs Java,
alors Ruby on Rails !!! - on m’avait dit la même chose sur Python/Django (et là vous pouvez
aussi remplacer par tous les frameworks récents à la mode), et ça ne
s’est pas imposé…i.e. mode/tendance ? - qui utilisera Ruby on Rails dans 2, 3 ans ?
- API pas stabilisées, toujours besoin de migrer (péniblement) vers
les versions les plus récentes (e.g. migration vers Rails 2.0) - pas assez de plugins, notamment plugins insuffisants pour
authentification - prototype et scriptaculous sont des librairies javascript… et pas
du tout besoin de ror pour faire de l’AJAX !!! (et franchement
expliquer l’intéret de RJS, ce n’est pas facile à faire sans entrer
dans les détails) - faire fonctionner RoR dans le monde réel est aussi bien plus
difficile que PHP, i.e. avec Apache, plusieurs serveurs et du load
balancing… - ouais, ben ok pour MVC, mais on va essayer de la faire avec Cake
PHP…
Perso, je suis convaincu de l’intéret des modèles MVC, de la nécessité
des principes de développement DRY, des interfaces REST. Je crois que
les méthodes de développement “agile” sont prometteuses et peuvent
nous sortir de certains “marasmes” d’un mode de développement
trèslinéaire et formel avec specs super détaillées, en tout cas pour des
applis web (et je crois que les applis du futur seront surtout web).
Je trouve que RoR m’aide à faire tout cela, mais je ne suis pas
convaincu que ce soit le meilleur choix, et sûrement pas pour tout le
monde. Pour l’instant, pour moi, je fonce sur RoR