Terminer des projets perso, retours d’XP
Premier post depuis un long moment et, pour changer les “habitudes”, on ne va pas mettre le nez dans du code à proprement parler.
Je vais plutôt aborder quelques leçons apprises (à mes dépends parfois) pendant le développement de projets persos que je souhaitais vraiment voir aboutir !
Pour le contexte, j’ai donc travaillé sur deux projets persos distincts:
Flowfield, une librairie JS de pathfinding avec laquelle vous pouvez jouer ici
AngryMap Une application à mi-chemin entre Twitter et Zenly, en version ultra béta ici
Objectif
Dans les deux cas, mon objectif était clair: TERMINER CES PROJETS.
Comme tout bon développeur, j’étais donc chaud bouillant de motivation au début de ces deux projets. Je pensais déjà aux milliers de stars que ma librairie obtiendrait et les millards de $$$ que mon application me rapporterait.
Pourtant, aussi beau soit l’objectif, la motivation, ça ne reste pas, vraiment pas. Très vite, on se dit que c’est trop compliqué, que le projet n’est pas si bien que ça, ou que sais-je encore et on abandonne.
Je me suis donc fait violence pour maintenir, si ce n’est ma motivation, au moins ma rigueur pour continuer à faire avancer ces projets au fil du temps.
Pour autant, tout en sachant que la motivation est fragile et donc à cajoler, j’ai fait des erreurs (techniques, etc.) ayant pu mettre en péril mes nobles objectifs.
Voici donc un petit état des lieux non exhaustif pour vous aider vous aussi à “terminer” vos projets perso.
Enfin, par terminer, j’entends atteindre au moins le stade de la béta, parce que bon, un projet informatique, c’est jamais vraiment fini… :)
Utiliser des variables d’environnements
Dès le début d’un projet, il est essentiel d’utiliser un fichier .env contenant toutes les variables d’environnement de votre appli. Cela évite le hardcode d’URLs ou de n’importe quoi de dynamique à l’échelle de l’application.
Dans le même principe, si vous prévoyez de traduire votre application dans différentes langues par exemple, cela à un coût en terme de code et de refacto. Pour limiter ce coût au minimum, intégrez les librairies et les changements que ce besoin implique (variabilisation de tous les labels, etc.) au plus vite dans votre code.
Même si tout est en français pour le moment, vous saurez que le moment venu, rajouter du polonais ou du chinois sera un jeu d’enfant !
Déployer son code ASAP !
Dans la suite logique du fichier .env, il est essentiel qu’au plus tôt dans la vie de votre librairie/application, celle-ci elle soit déployée en ligne et donc prod-ready.
Il existe plein de services gratuit qui permettent ça.
Pour Angry Map, j’utilise Heroku pour héberger mon API Node, Surge pour servir mon application React et mLab pour ma base de données Mongo.
Ainsi, déployer son code au plus vite permet deux choses :
- Lever des problèmes dans son code pour les corriger le plus tôt possible. Terminé le it works on my machine syndrome.
Histoire vraie: Alors qu’en local, mon application fonctionnait sans problème, impossible de la déployer sur Heroku !
Pour faire court, avec la configuration que j’avais, le stockage des sessions utilisateurs se passait directement sur la mémoire du serveur. Cette configuration conduisait Heroku a refusé de déployer mon appli (l’empreinte mémoire devenait non maîtrisable). Cela m’a donc conduit a refactoré du code afin de déporter ce stockage sur MongoDB.
- Récupérer des feedbacks utilisateurs au plus vite sur son travail.
Limiter les librairies
Nous sommes des développeurs et comme tout développeur qui se respecte, ce que l’on souhaite plus que coder, c’est coder avec une nouvelle librairie/code/framework/whatever. On aime le neuf, la technique pour la technique et apprendre des trucs en permanence mais ATTENTION, ici, on veut livrer du code (et prendre soin de sa motivation).
Il faut donc manipuler le npm/yarn install avec parcimonie :D
Par exemple, pour ma librairie JS Flowfield, je me suis lancé à utiliser Flow et Immutable.JS. Comme je ne connaissais pas ces deux librairies qui ont un impact certains sur la façon de coder, ma vitesse de développement a diminué.
Nuance cependant, je ne dis pas qu’elle m’ont été inutiles loin de là, seulement, au lieu de faire de l’algo et avancer, j’avais le nez dans la documentation.
Fort de cette expérience, avec l’application Angry Map, j’ai tâché de limiter les libs que j’utilisais (que je les connaisse ou non d’ailleurs). Ainsi, la version béta a dit adieu à redux, GraphQL et react-apollo par exemple.
J’en aurais peut être besoin ultèrieurement mais à l’heure actuelle, ça n’aurait eu que peu ou pas de valeurs. Pire, les utiliser auraient pu me ralentir et me faire over-engineerer des parties de l’appli qui vont être complètement transformées dans deux jours. Une perte de temps colossale dont la première victime est votre motivation.
Besoin de GraphQL ? Une API Rest fera l’affaire pour le moment
Besoin de Redux ? Si j’en ai besoin, je m’en rendrais compte très
vite mais pour le moment, je fais très bien sans.
Besoin de … ?Il est important de se poser ces questions à chaque lib que l’on installe !
De même, attention au mode clé en main de certains frameworks.
Naïvement, j’avais développé mon API Rest en utilisant Loopback, un framework où vous n’avez qu’à déclarer vos modèles de données et toutes les routes se génèrent automatiquement.
Les 2 premier jours, j’étais donc aux anges ! Et puis, j’ai voulu ajouter de l’authentification avec Gmail et là, c’était terminé. Documentation pas claire, repository du module d’authentification plus maintenu, etc. j’ai perdu 2 semaines à vouloir faire rentrer cette fonctionnalité d’authentification (pas vraiment révolutionnaire vous en conviendrez), et j’ai échoué. Finalement, j’ai tout supprimé et recommencé mon API de zéro…
MOTIVATION EXCUUUUUSE MOI, PLIZ STP REVIEN §§§§§§§§
Trop de pattern tue le pattern
Lorsque l’on développe une librairie ou une application, on développe un produit une idée, un concept loin d’être finalisé. Aussi, de mon point de vue, cet état de fait doit clairement influencer notre façon de coder.
Il faut éviter les abstractions trop importantes dès le début, celles-là même qui vont se révéler désatreuses dans quelques semaines pour implémenter une nouvelle feature.
Amoureux des render props en React, et armé du cours de Ryan Florence à ce sujet, j’ai commencé à en utiliser pour pas mal de choses sur Angry Map.
Seulement, ce qui était pour moi la quintessence de l’élégance est devenu de plus en plus compliqué à maintenir alors que la quantité de code augmentait…
Rappelez-vous, on se bat contre notre baisse de motivation, il faut donc aller vite !
Aussi, en tant que développeur, malgré la douleur que cela représente, il faut savoir savoir sacrifier la beauté du code au profit de la fonctionnalité.
Concevoir son UI/UX en s’inspirant de ce qui existe
Si comme moi, vous êtes un développeur pour qui convevoir le design et l’ergonomie d’une appli vous posent quelques soucis, clairement, inspirez vous d’applications existantes.
Pour mon application, je suis parti tout de suite dans des grandes idées de design que j’ai eu du mal à implémenter et qui m’ont pris trop de temps par rapport à l’importance que ça avait dans l’application en général.
C’est dommage parce que sur mon téléphone, j’avais une petit application qui s’appelle euh… ah oui Airbnb et qui répondait en parti à mes problématiques…
Utiliser des listes
Enfin, dernier conseil pratique pour ne pas perdre sa motivation trop vite : découper ses objectifs en tâches courtes.
Au cours de mes projets, je me suis mis à utiliser assidument Trello.
Ainsi, j’avais un board sur lequel se trouvait 4 listes :
- Fonctionnalités critiques pour la béta
- Tâches pour déployer l’appl en “prod”
- Fonctionnalités sympas et idées sur le moyen-terme
- DONE (ma préférée)
En réalisant cette liste, on canalise son énergie vers des tâches qui nous rapprochent de l’objectif final : SHIPPER.
Que ce soit pour noter de nouvelles idées ou pour prioriser les tâches à faire, j’ai trouvé cet outils particulièrement intéressant et pertinent pour ne pas s’éparpiller (sur le court terme) et ne pas oublier les idées géniales (sur le moyen/long terme).
En plus, chaque fois que l’on place une carte dans la liste DONE, un petit shot, mélange d’endorphine et d’auto-satisfaction se déclenche et ça, ça fait vraiment du bien ! :D
Conclusion
Voilà, c’était ma liste non exhaustive pour arriver à (enfin) terminer les projets perso qui vous tiennent à coeur ! J’espère que vous y aurez trouvé des choses intéressantes à appliquer dans votre vie de développeur au quotidien.
En ce qui me concerne, cet article a une valeur de pense-bête (cadeau pour mon moi du futur :) ).
