Pour mon nouveau boulot, je suis amené à faire du Flex. Je ne le prends pas trop mal, dans la mesure où ça me permet (en théorie) d'implémenter un point essentiel des méthodes pour rester un développeur "on the edge".
Là où c'est moins bien, c'est que tant qu'à faire, j'aurais préféré travailler sur un langage qui ne fasse pas semblant.
Prenez l'IDE, par exemple. La toute dernière version de Flash Builder est en fait un packaging d'Eclipse dédié aux développeurs Flash (comme peut l'être, je ne sais pas moi, Eclipse for C, Pulsar, ...). En un sens, c'est très bien, parce qu'en tant que développeur Java, je ne suis pas vraiment surpris. Sauf quand ils décident de me livrer sans mon consentement une version française. Ou que le seul refactoring disponible soit le renommage de fichiers (alors que faire des refactorings dans un langage dynamique, même si c'est plus difficile, c
'est possible). Ou que les erreurs de compilation me font revenir quinze ans en arrière, avec des codes aabscons suivis de messages encore moins clairs (pour l'anecdote, il m'a fallu hier à peu près l'après-midi pour trouver qu'un test ne fonctionnait pas à cause d'un simple problème de déclaration de constructeur). Ou qu'une application mxml contenant les tests doive se trouver dans le dossier src (ce qui est super pratique pour séparer les tests et le code source de ma bibliothèque, tiens, imaginez comme maven est content).
Et si l'IDE infâme ne vous suffit pas, prenez les bibliothèques de test unitaire. En Java, je connais bien
jUnit, et un peu
TestNG. Elles sont plutôt documentées et facilement intégrées dans l'IDE. Bon, en Flex, il y a quoi ?
flexunit ?
funit ?
asUnit ? bon, eh bien je vous mets au défi de trouver une doc claire et complète pour ces différentes bibliothèques; Attention, je ne parle pas d'un tutorial écrit pour faire comme tout le monde et présentant un exemple bidon même pas intégré à l'IDE, mais bien de l'exemple complet qui me permet à la fin de lancer mes tests dans l'IDE. Cherchez pas, vous ne trouverez rien. Parce que ces trucs sont codés à la va-vite et que leurs auteurs ne semblent pas se soucier de l'industrialsiation de ces tests unitaires.
Et pour finir avec l'industrialisation, parlons un peu des flexmojos. C'est une super-idée de vouloir intégrer la compilation Flex à maven pour montrer comme l'outil est extensible. Mais c'est aussi une terriblement moins bonne idée que de fournir une dépendance flexmojos-unittest-support qui contienne les trois bibliothèques sus-mentionnées (dont les classes de bases de test unitaire s'appellent toutes ... TestCase ... merci pour les problèmes d'import) sans jamais expliquer comment éviter cette dépendance (mis à part, quand on connait maven, en allanrt faire un tour dans le pom de cette dépendance pour trouver les dépendances initiales et leurs versions respectives).
Bref, Flex, c'est quand même vachement moins bien que Java. Et c'est là que je comprend les éternels regrets des vrais développeurs Java, qui voient Sun lancer des idées du bout du petit doigt et ne pas les soutenir (au hasard, JavaFX) alors qu'avec un bon soutien, cette techno a les moyens de botter cent fois les fesses à ce Flex, qui n'est rien d'autre qu'un javascript vaguement rabhillé.
Comments [0]