Seulement voilà, ce type de développement Flex, lorsqu'il a besoin d'être repris par un développeur autre que le développeur d'origine, peut poser des problèmes différents selon celle des deux situations citées plus haut qui se présente - la troisième, qui a priori ne pose aucun problème, étant le développement de l'application par un codeur Flex expérimenté pas trop attaché aux usines a gaz ;)

Le développement par une SSII

La plupart des ingénieurs en développement sont formés sur des langages type Java ou .NET. Quand je me parle à moi-même (et oui, ca m'arrive), j'appelle ca des langages "non-visuels". Ces langages disposent d'un framework extrêmement développé, sans compter le nombre de frameworks annexes(type Spring, MINA, etc..), utilisés par tellement de monde que c'est comme s'ils étaient natifs au système et disposent d'un support énorme par la communauté.

Ces développeurs reproduisent naturellement les mêmes mécanismes quand ils se retrouvent dans un environnement Flex et utilisent le premier framework qui passe et qui ressemble à ce dont ils pensent avoir besoin. Je dis bien ils pensent, car l'utilisation de ces frameworks revient souvent à compliquer une architecture qui n'en a pas besoin. Cela permet la plupart du temps au développeur de retrouver un environnement de développement qui lui est familier concernant le MVC, ou l'utilisation de connecteurs plus "standards" (j'entends par là standard à leur langage de prédilection) pour la récupération de données (WebService la plupart du temps).
La formation ou le transfert de compétence étant le plus souvent effectuée par la première personne qui a initié le projet, cela ne semble poser de problème à personne. Sauf si l'on pense au fait qu'une fois le produit livré, ça laisse difficilement la possibilité au client final de confier la maintenance ou l'évolution du produit à un autre prestataire, a moins que le doc soit vraiment extrêmement complète - ce qui, avouons le, est très rare: une bonne doc (ASDoc + doc rédigé) prenant beaucoup de temps, ce que peuvent rarement se permettre les prestataires s'ils veulent respecter leur délais sans facturer la partie documentation.

Le problème là n'est pas lié à Flex, mais bien à la philosophie SSII (la plus répandue en tout cas): des ingénieurs parlent aux ingénieurs. Et étant donné que Flex commence à être vu, comme je le disais, comme un outil "serieux", les SSII sont de plus en plus sollicitées sur cette technologie, mais pour des clients "web", dont la politique n'est pas de se retrouver pieds et mains liées à cause de choix technologiques du prestataire.

Les prestataires peu expérimentés

Suite à un assez vieux post, j'ai été considérés par certain comme un élitiste casseur de débutants, alors que le message que je désire faire passer est qu'il faut seulement essayer de faire ce que l'on sait, et apprendre ce que l'on ne sait pas.
En tant que codeur AS2, mon passage à l'AS3 s'est fait via Flex2, avant que ne sorte Flash CS3. J'ai eu l'immense chance à ce moment là de faire partie d'une entreprise pour laquelle le projet que je devais réaliser avait un besoin impératif d'une conception propre, quitte à passer beaucoup de temps à étudier le framework Flex avant de commencer à coder l'application. J'ai donc passé beaucoup de temps en R&D avant de passer en production, ce qui m'a permis d'apprendre beaucoup de mes tests et erreurs.

Flex a ce côté séduisant du fait que pas mal de choses peuvent sembler se faire toutes seules: positionnement, binding, navigation, composants... Mais il faut malgré tout en connaître le fonctionnement précis pour, par exemple:

  • ne pas utiliser une gestion des states avec manipulation de la display list là où une ViewStack est plus indiquée...
  • ne pas utiliser un binding là ou un simple événement suffit...
  • ne pas utiliser un (Binding) là où un (Binding(event="..")) sera bien plus performant... (les crochets passent mal sur Dotclear)

C'est pourquoi le seul conseil que je peux donner ici est de ne pas se lancer dans un projet qui est au delà de ses compétences actuelles. L'auto formation est une excellente chose et je ne jure que par elle, mais pour un freelance, c'est selon moi un manque de respect au client que de vendre une prestation qui a 9 chances sur 10 d'être plus ou moins bancale (par exemple, je préviens systématiquement mes clients si je n'ai pas la compétence/expérience sur une techno précise, quitte a refuser le contrat).
Cela en plus complique la tache d'un éventuel autre prestataire qui aurait besoin d'assurer la maintenance ou l'évolution du produit: c'est donc aussi pas très cool pour les collègues...
Je parle bien ici précisément de Flex: rien a voir avec le fait d'accepter de coder un diaporama sans en avoir jamais fait: il s'agit bien là d'un framework complet et de toute la philosophie de développement qui lui est attaché, ainsi que de ses outils.

Les frameworks en général

Beaucoup de développeurs de haut-niveau se sont essayés, souvent avec succès, au développement d'un framework open-source... Rappelons d'ailleurs que Flex n'est "qu'un" framework AS3, auquel est associé un "traducteur" MXML->AS3. Ces frameworks permettent de faire plus de choses, ou d'encapsuler un certain nombre de comportements communs. Que ce soit une implémentation du MVC, une couche d'accès aux données ou tout autre fonctionnalité, ces frameworks disposent pour chacun d'une philosophie de développement propre à son concepteur ou à ceux qui ont adhéré au framework.

Ce qui veut dire également que ceux qui n'ont pas adhéré au framework se voient affronter un mode de développement complètement différent de la technologie qu'ils pratiquent, pour laquelle ils se sont déjà formés. Alors s'il s'agit d'un easyMVC (7 classes) ou d'un cairngorm(22 classes), ca peut encore aller. Mais s'il s'agit d'un servebox foundry (121 classes en comptant commons+foudry+toolbox), d'un VEGAS (171 classes) ou autre lowRIA (265 classes), ça commence a faire usine à gaz...
Et quels que soit les avantages et inconvénients de chacun de ces frameworks, il est à chaque fois obligatoire de se conformer à la philosophie de développement de chacun sous peine de perdre tout l'intérêt des les utiliser.

Bref, je dirais que l'utilisation d'un framework "propriétaire" dans le cadre d'un framework agence ou de projets perso peut être une excellente chose: il peut correspondre ainsi à un goût pour tel ou tel mode de travail, ou devenir une politique d'entreprise dans le cas des agences. Mais pour un prestataire qui sait que ce projet va lui échapper, je pense que ce n'est certainement pas une bonne idée: non pas pour son propre travail, mais pour ceux qui peuvent être amenés ensuite à intervenir sur le projet.

Et moi en tant que prestataire aujourd'hui, faudrait-il que je maîtrise l'ensemble des frameworks les plus courants pour pouvoir accepter les missions que l'on veut me confier? Ce serait l'idéal, mais travail+R&D+sommeil sont rarement tous les 3 compatibles! :P
Et faire de la R&D pour maîtriser un framework qui ne me permet pas de faire plus de choses que ce que j'aurais fait sans, je dois avouer que ça me rebute un peu...

Et puis quand je livre un client, je fais systématiquement en sorte qu'il ne soit pas "verrouillé". C'est avec j'avoue un peu de fierté que je dis en général à mes clients qu'ils peuvent faire appel a n'importe quel prestataire compétent dans la technologie (Flash ou Flex) pour prendre la suite, sans requis supplémentaires. C'est bien plus pratique pour tout le monde: le client ne se sent pas prisonnier d'un prestataire, et je ne culpabilise pas de ne pas pouvoir assurer la maintenance si mon emploi du temps ne me le permets pas car je sais qu'un autre prestataire pourra le faire facilement.

Pour finir, je rappelle que les Design Patterns sont une solution générique pour un problème précis, généralement pour des problèmes que l'on rencontre souvent dans du développement Objet. Cela veut aussi dire qu'il ne sert à rien de les utiliser si le problème ne se pose pas! Un MVC avec une seule vue et un seul contrôleur est par exemple totalement inutile, et pourtant j'en vois si souvent... Car évidemment, quelqu'un qui utilise un framework qu'il aime pratiquer en vient à l'utiliser systématiquement, même quand il n'est pas nécessaire...

--

Si j'ai le temps et la foi suffisante, j'essaierai de faire un ticket sur un ensemble de pratiques personnelles en Flex, qui se sont avérées être efficaces et productives sur le terrain, qui grâce aux commentaires pourraient être débattues et enrichies.