Développer avec plus de plaisir grâce à 7 astuces
Cyrielle, Responsable marketing et communication 13 septembre 2019
Cyrielle, Responsable marketing et communication 13 septembre 2019
Aujourd'hui, c'est la Journée des Développeurs. Non ? Si. La journée des développeurs - ou des programmeurs -, ça existe vraiment. Elle a été instaurée en Russie en 2009 et est fêtée tous les ans le 256e jour de l'année.
Comme on est un vendredi 13, c'est également votre jour de chance (à défaut d'être en congé). Notre équipe technique a réuni toutes ses meilleures astuces (back-end et front-end) pour rendre vos journées de travail plus agréables et ça, c'est valable toute l'année ! On commence ?
Faire de la veille peut paraître fastidieux mais contrairement aux apparences, c'est loin d'être une perte de temps. Réaliser quotidiennement (ou fréquemment) une veille technique permet d'être au fait de toutes les nouveautés techniques et des nouveaux outils permettant de gagner en productivité. Cela permet de confronter ses méthodes à celles d'autres experts afin de s'approprier les meilleures façons de procéder. Voici quelques exemples de sites et de méthodes de veille efficaces.
Une bonne pratique de veille est d’utiliser ces sources pour repérer les blogs/magazines qui traitent de sujets qui nous intéressent le plus.
Lorsque l’on développe en équipe avec GIT, il est important de savoir dans quel état notre code se trouve.
Entre les changements de branche, les différences entre les dépôts distants et locaux, les éléments non suivis (untracked), indexés pour validation (staged), engagés (committed) ou poussés (pushed), il est fréquent de ne pas savoir à un instant T dans quel état sont les fichiers.
Plutôt que de devoir vérifier à chaque fois l’état du code, il est possible de configurer son shell pour avoir ces informations de façon très visuelle, au premier coup d’œil à l’invite de commande (prompt).
L’idéal est de construire une configuration adaptée à votre façon de travailler. Comme base de travail, vous pouvez néanmoins trouver des configurations toutes prêtes :
Si le shell par défaut fonctionne bien, il en existe d'autres, avec des options plus avancées. C'est notamment le cas de Fishshell. Celui-ci ne nécessite quasiment aucune configuration. De plus, il ajoute une simple fonctionnalité qui optimise réellement la productivité : l'autocomplétion basée sur l'historique.
Toute commande ayant déjà été tapée une fois dans un dossier particulier est retrouvable et autocompletée au fur et à mesure qu'on commence à l'écrire. Cette commande, que vous la tapiez 15 fois par jour ou 1 fois par mois, n'est maintenant plus qu'à quelques ctrl + flèche droite !
Il comporte néanmoins quelques subtilités, mais rien que le tutorial ne puisse indiquer.
Si vous utilisez Symfony, il y a de fortes chances pour que vous ayez déjà utilisé Doctrine. Vous avez probablement suivi la documentation et utilisé un alias particulier pour chaque type d'entité. De notre côté, nous préférons utiliser le même alias pour toutes les entités, (nous avons choisi le 'o', comme le fait Sylius).
Cela nous a permi de factoriser de nombreux comportements dans des traits sans avoir à se soucier de passer l'alias en paramètre. Cela permet également de ne pas avoir à réfléchir à quel est l'alias du Repository courant dans chaque méthode, puisque la réponse est invariablement 'o'.
En bonus, nous avons même pu automatiser l'harmonisation de cet alias, en créant un BaseRepository avec la méthode suivante :
abstract class BaseRepository extends ServiceEntityRepository
{
public function createQueryBuilder($alias = 'o', $indexBy = null)
{
return parent::createQueryBuilder($alias, $indexBy);
}
}
Prendre le temps de bien configurer son éditeur, c'est un véritable gain de productivité pour un plaisir garanti !
Notre IDE - ou éditeur de code - fait partie de nos outils de travail principaux. Il est donc très important de prendre le temps de le configurer. Certains de nos développeurs utilisent VSCode depuis quelques années maintenant et voici ce qu'il apporte :
Voici un top 5 des plugins que nous avons ajoutés (32 au total !) :
Sans oublier les modules pour la partie validation de code, typage statique, etc. : Flow, ESLint, GraphQL for VSCode, Babel, Prettier ou encore EditorConfig.
Les hooks sont devenus un standard dans le monde de React. La communauté y a adhéré très rapidement et a sortie des centaines de modules en quelques semaines seulement.
Cette communauté maintient à jour des dépôts type "Awesome". Ceux-ci listent les ressources les plus connues/utilisées sur la platforme concernée. On retrouve, par exemple, Awesome React-Native, Awesome React ou encore Awesome GraphQL. La même chose existe pour les hooks.
Il en existe d'autres, mais ce dépôt est le principal et regorge énormément de hooks. Voici une petite sélection bien croustillante :
Des centaines sont disponibles, n'hésitez pas faire une recherche sur Github et/ou npmjs.com !
Dernière astuce : voici comment upgrader votre application React Native, sans pleurer (ou presque) toutes les larmes de votre corps grâce au React Native Upgrade Guide.
React Native, c'est vraiment cool, on le sait tous. Par contre, quand il s'agit de mettre à niveau sa version de React Native (pour peu qu'il faille mettre à niveau plusieurs versions)... c'est déjà moins cool. Et pour cause, les changelogs sont souvent costaux lorsqu'il s'agit de maintenir les deux ogres que sont Android et iOS.
Pour palier ce problème, des développeurs ont créé le React Native Git Upgrade. Ce super outil nous a aidé à plusieurs reprises. Le dépôt est toujours activement maintenu pour le plaisir de toute la communauté.
Plus récemment, l'équipe de React Native a publié un outil en ligne qui permet de voir les différences entre deux versions : le React Native Upgrade Helper.
Avec cet outil, la mise à jour est manuelle. Il vous appartient donc de modifier chaque fichier, l'un après l'autre. Il y a évidemment du pour et du contre. De notre côté, nous avons une préférence pour RN Upgrade Helper, qui permet d'avoir la main sur la mise à jour et une meilleure visibilité.
Un grand merci aux co-rédacteurs de cet article : Stéphane, Jean-Pascal, Nicolas et Cédric.
