Amis du soir bonsoir,

Aujourd’hui je vais vous parler d’un sujet un peu différent des denières fois.
Comment j’ai fini par développé une librairie pour prouver à des collègues qu’ils s’y prennent mal et qu’ils sont dans l’erreur.
Et finalement je me suis rendu compte qu’il y a matière à vraiment en faire pas mal de choses de cette librairie ^^

Par lassitude

J’avais déjà failli faire un article l’hiver dernier, car j’avais fait une petite librairie principalement par lassitude: Unity Barcode Scanner

Après avoir entendu parler pendant des mois que sur un autre projet, la librairie qu’ils utilisaient pour scanner des QRCodes était bugger et pas a jour. J’avais décidé de prendre le taureau par les cornes et de m’en occuper en faisant une sur mon temps libre.

Mais c’était presque un Proof of concept fait en seulement quelques jours juste pour prouver la faisabilité et la simplicité de ce type d’outil.

Par énervement

Depuis 2~3 mois, je suis forcé de travailler sur des jeux en HTML5. Pas que je haïsse ça, mais l’absence d’outils efficaces et l’utilisation de JavaScript ne sont pas très encouragent quand à coté il y a des outils comme Unity, Unreal ou PlayCanvas. Une legere impression de devoir reinventer la roue.

Mais le problème cette fois-ci est venu de 2-3 collègues développeurs JavaScript (avec un background flash pour certain) qui pensent pouvoir donner des leçons sur la façon de développer. Si ce n’était que ça, je me serais contenté de les ignorer … mais à partir du jour où j’ai été contraint d’utiliser leurs librairies/logiciel, j’ai eu des envies de meurtres.

Dans le désordre:
* Un code très peu lisible avec un style totalement freestyle
* Une structure tres mouvante sans héritage claire
* Des fichiers massifs entre 1k et 8k lignes
* Des gros morceaux de code mort
* Du code bugger, jamais tester
* Du code préoptimisé qui ne fonctionne même pas
* Une documentation et des samples absents
* …

Et de ces personnes j’ai entendu:
* Le Typescript c’est lent et lourd
* Les tests unitaires ça n’est pas très utile, car ne reflète par un usage réel
* La documentation ne sert à rien, il suffit de lire le code
* Les interfaces et abstracts c’est over-engineer

L’heure de faire quelque chose

Et ces personnes ont entre autres développé une librairie de tween nommé Tina que je suis forcé d’utiliser à longueur de temps. Et je ne passe pas une semaine sans y découvrir de nouveaux bugs. J’ai arrêté de les signaler tellement ça devient ingérable. Même les fonctions de easings comportent des bugs …

Ca ne parait pas forcement grand-chose, mais dans un jeu vidéo une librairie de tweening est l’une des briques essentielles. La logique va dépendre des callback pour correctement gerer l’état du jeu, donc des tweens pas fiables peuvent très rapidement ruiner un jeu.

Fatina

Et donc il y a de ça 3 semaines j’ai commencé le développement de Fatina

Une librairie de tweening pour Typescript / Javascript
* Site officiel
* API
* Samples

L’objectif était donc de leur montrer:
* Que typescript n’est pas lent et même plus rapide dans pas mal de tests que leurs JS ES5 fait main
* Qu’écrire des tests et avoir un coverage > 95% ont un réel intérêt
* Qu’il est possible de rapidement iterer et ajouter des features quand le socle est solide
* Qu’il est possible de faire un code lisible sans impacter les performances
* Que l’open-source n’est pas que pour pouvoir utiliser npm gratuitement

Conclusion

Finalement je me suis pas mal amusé et le résultat est assez conforme à ce que je souhaitais faire.
Par contre plus je travaille sur cette librairie, plus je me rend compte des lacunes de ce type de librairie et tous les editeurs / plugins qu’il faudrait faire autour.

Je me suis egalement pas mal amuser à faire le site web sur github grace à Hugo et PixiJS

email

Facebook

Twitter

Linkedin