4 astuces pour coder tout en surmontant nos propres défauts psychologiques

Étant donné le choix entre un morceau de gâteau maintenant ou un gâteau entier dans un mois, nous choisirions probablement le premier. Ce biais psychologique est connu sous le nom de « Préférence de temps » ou « Réduction de retard ».

Nous avons tous vu ce bel exemple d'enfants essayant de s'accrocher en ne mangeant pas de guimauve, dans l'espoir d'une plus grande récompense :

Lors de l'écriture de code, nous sommes souvent confrontés au même problème, devoir choisir entre les avantages à court terme d'une mauvaise pratique et les coûts à long terme qu'elle génère.

Voir aussi : IoT et codage :quels sont les langages de programmation les plus populaires ?

Pour éviter de se gaver de guimauves inefficaces, voici 4 exemples de quand et comment nous pouvons vaincre nos préjugés pour gagner à long terme.

1. Écrire un test unitaire, pour votre propre avantage

Nous en avons tous lu, appris et entendu parler. Les tests sont un bon exemple de quelque chose que je sais que je devrais faire pour le bénéfice à long terme, mais c'est sur mon chemin lorsque j'essaie de faire le travail maintenant.

Voici quelques réflexions qui peuvent aider à équilibrer cette équation :

• Les tests s'assurent que rien ne se casse lorsque vous modifiez des éléments . Cela signifie que vous pouvez apporter des modifications à votre code et savoir sur place si tout fonctionne. Cela vous permet de travailler plus librement, même maintenant.
• Les tests aident à déterminer quand quelque chose est « assez bien ». Les tests définissent ce que cela signifie pour un morceau de code de « fonctionner ». Cela peut en fait vous permettre de dépenser moins temps en optimisant des choses que vous n'avez pas vraiment besoin d'optimiser.
• Les tests aident à écrire du code réutilisable . Vous pouvez composer des choses plus grandes à partir de pièces modulaires plus petites. Lentement, vous construisez un arsenal impressionnant de blocs de construction réutilisables prêts à être utilisés à votre guise.

Soyez également fier des tests que vous écrivez. Voir tous les indicateurs verts suspendus au-dessus de votre code. Sachez que votre pratique et votre éthique sont excellentes. Il n'y a aucune honte à cela.

2. Rendre le code réutilisable pendant que vous travaillez

L'écriture de code réutilisable présente de nombreux avantages à long terme ainsi que des avantages immédiats. Dans la mesure du possible, concevez votre code pour qu'il soit réutilisé. Ensuite, publiez-le/exportez-le vers l'open source.

Vous n'avez pas besoin de passer des heures à publier des packages. Au lieu de cela, vous pouvez exporter ces petits composants vers Bit. Voici un article de blog de Ran Mizrahi expliquant pourquoi et comment vous pouvez exporter de petits composants en quelques secondes.

Très rapidement, vous pouvez créer un arsenal de composants React ou Angular réutilisables ou une belle étendue de fonctions utilitaires.

L'effort est faible et la vue Web du hub communautaire de Bit offre une vue rapide de la documentation, des tests, des téléchargements et plus de votre composant, donnant une satisfaction immédiate avec votre travail désormais disponible dans le monde. Vous pouvez également le partager avec votre équipe ou la communauté.

3. Ne pas copier-coller. Ne le faites pas.

Un exemple classique. Le copier-coller permet de faire le travail beaucoup plus rapidement dès maintenant, mais les duplications rendent notre base de code plus difficile à maintenir demain, créant une dette technologique toujours croissante.

Chaque petite modification devra être effectuée à plusieurs endroits et les problèmes ne seront souvent détectés que lors du passage à la production.

Que pouvons-nous faire ? eh bien, ne faites pas de copier-coller de code ! Ne le faites pas. Au lieu de cela, recherchez/créez/partagez des composants réutilisables. Sindre Sorhus a sorti plus de 1 000 petits paquets. Les packages sont difficiles, et 1 000, c'est beaucoup.

Nous pouvons utiliser Bit pour rendre ce processus facile (exporter des composants en quelques secondes) et définir un objectif réalisable tel que rendre 100 composants réutilisables. Vous découvrirez qu'une centaine environ pourrait suffire pour réduire considérablement le nombre de duplications, et très bientôt, vous verrez que la réutilisation est beaucoup plus rapide que la duplication.

4. Documentez votre code, racontez une histoire

Une bonne documentation signifie que si je me faisais manger par des coyotes sauvages demain, quelqu'un d'autre pourra me remplacer. Important sans aucun doute, mais pas ma principale préoccupation en ce moment. Je préfère faire le travail que de m'inquiéter de « mon futur » ou de ceux qui me suivront. Je m'occuperai d'eux plus tard si j'y arrive à temps. Ce genre de priorisation (très humaine) conduit à des lacunes et à un manque de rigueur dans la documentation.

Cependant, il y a un autre point de vue que je peux adopter pour m'assurer de ne pas négliger ma documentation.

Le code lui-même et sa documentation sont des représentations de l'histoire logique que je raconte. En écrivant ce que fait chaque partie de mon code, en ajoutant les arguments qu'il reçoit, ses retours, en ajoutant quelques exemples, etc., j'ai également une bonne vue du scénario du code que j'écris. Je comprends comment cela fonctionne dans le cadre d'une image plus large.

Les bons documents montrent que vous comprenez parfaitement ce que vous faites et comment vous le faites. Si l'histoire n'a pas de sens, il vaut mieux le découvrir à travers les documents qu'à travers le code lui-même.

En fin de compte, notre volonté est une ressource limitée. Nous forcer à combattre notre propre psychologie à chaque heure de chaque jour est une bataille difficile à gagner. Cependant, adopter de bonnes pratiques est une routine et se donner des récompenses immédiates pour les faire peut nous aider à gagner beaucoup plus à la fin de la journée.

Après tout, une guimauve à la fois ne suffit vraiment pas.