Un codeur qui parle de code
Tom ici écrivant, développeur passionné pour tout ce qui est web et natif. De nombreuses lunes se sont écoulées depuis que j'ai commencé à écrire quelques lignes de code. Un moment glorieux de « Hello World » a été, et depuis lors, j'ai écrit beaucoup plus de lignes de code beaucoup plus, allant des systèmes d'alerte en temps réel, des applications médicales soutenant les médecins dans leurs tâches quotidiennes aux réunions multi-plateformes-&- logiciel de gestion des horaires. J'ai également appris certaines choses en cours de route, et aujourd'hui, je souhaite partager un aspect du codage qui n'est peut-être pas toujours autant ciblé, en particulier pendant les périodes difficiles à mi-projet. Parlons de la responsabilité d'un codeur, ou, pour être précis, de l'héritage de code d'un codeur.
Les pyramides de Javascript
Le travail d'un architecte n'est pas seulement de définir la disposition fondamentale d'un nouveau bâtiment, les formes des murs, des fenêtres et des portes ou l'alignement de la maison proportionnel au soleil de midi. Parmi toutes ces choses, l'architecte sait que le bâtiment doit durer des années, qu'il doit résister à une nature brutale de vents forts, de fortes pluies, d'hivers froids et d'étés chauds. Le but ultime du travail de l'architecte est de s'assurer que les personnes vivant dans le bâtiment ont une maison sûre. Tout est question de longévité de son travail. Tout est dans son héritage.
Dans le développement de logiciels, les choses ont tendance à évoluer à un rythme très rapide, en particulier lorsque vous travaillez dans des startups. Il est important d'expédier rapidement de nouvelles fonctionnalités, de gagner du terrain sur le marché et de maintenir l'engagement des utilisateurs. L'accent pendant le développement a tendance à être limité au sprint actuel ou à la mise en œuvre de cette fonctionnalité hautement prioritaire dès que possible.
Pourtant quand je code, il ne faut pas se cantonner aux tests pour allumer tout en vert ou juste la date limite à atteindre. Une fois dans la nature, les applications sont utilisées par les humains qui peuvent compter sur elles pour leur routine de travail quotidienne. Le programme que je construis aujourd'hui est l'héritage que je laisserai demain.
Prenons l'exemple du Web : il n'a jamais été aussi facile de trouver des composants qui fournissent les fonctionnalités que je recherche actuellement via NPM. Ils sont rapidement installés et connectés au reste de la base de code. Mais en ce qui concerne la longévité de mon application, les dépendances tierces peuvent arrêter l'ensemble du processus de mise à jour, b/c mettre à jour cette dépendance en empêche une autre de fonctionner. C'est un exercice d'équilibre de décider entre ce qu'il faut implémenter par moi-même, fork ou installer directement à partir d'un gestionnaire de packages.
Cependant, le code de fournisseurs tiers peut tout à fait convenir. Il est important de vérifier certains facteurs avant d'utiliser la bibliothèque ou le framework : quelle était la qualité de la maintenance dans le passé, combien de contributions actives y a-t-il maintenant, une feuille de route est-elle disponible décrivant les modifications ou améliorations futures, le package est-il entièrement géré par la communauté ou soutenu par sponsors pour aider à son développement ?
En passant du code externe à ma propre base de code, une chose que je dois constamment me rappeler est de ne pas couper les coins ronds pendant le développement pour atteindre un objectif plus rapidement. Aussi tentant que cela puisse être à court terme, un code mal planifié se vengera et ripostera. Penser au code plus qu'à l'écrire permet d'atténuer de nombreux problèmes. L'expérience est certainement un facteur clé ici, mais les développeurs juniors doivent également comprendre l'importance d'un code maintenable dès le départ. Ce qui mène maintenant aux bogues peut ne jamais être corrigé en raison des délais du projet et n'être résolu que par des solutions de contournement, entraînant soit un code désordonné, une mauvaise expérience utilisateur ou les deux.
Mentalité du machiniste
Un autre aspect du codage réfléchi sur lequel je veux écrire est le public cible d'une application, l'utilisateur. Alors que je suis assis de 9 à 5 devant l'écran de mes règles à calcul électriques, parcourant des lignes de code et me concentrant sur le problème qui m'est assigné, il est certainement difficile de garder à l'esprit que tout mon travail, finalement, a être utilisé par quelqu'un qui l'utilise partiellement ou complètement dans le cadre de son travail quotidien. Et peu importe si je crée une application pour des personnes non techniques ou des API pour d'autres développeurs - le contenu que je crée doit être ergonomique dans son utilisation.
Je sais par expérience personnelle que les utilisateurs peuvent interagir avec votre application de manière étrange et pour la plupart inexplicable. En tant que créateur, j'ai tendance à rejeter le comportement « non intentionnel » de mon service, d'autant plus si j'y ai déjà investi beaucoup de temps et d'énergie. Pourtant, garder l'esprit serein lors de la réception des commentaires et, si nécessaire, m'obliger à les écouter, joue un rôle clé dans la compréhension du comportement d'utilisation réel et réel du public.
En tant que développeurs, nous vivons dans un monde d'ordre et d'uniformité lors du codage, où un type particulier de physique et de gravitation s'applique et où nous connaissons toutes les règles. C'est un monde à embrasser et à s'immerger pleinement, car nous en sommes les créateurs et les habitants. Mais faire face aux commentaires, c'est-à-dire aux critiques de l'extérieur de ce monde, conduit généralement à son rejet par les développeurs. La gestion des rapports et des options des utilisateurs doit être apprise et valorisée en tant qu'entrée pertinente pour le développement. C'est une leçon que j'ai apprise, et cela aide énormément à chaque étape du projet d'être ouvert aux changements et aux commentaires.
processus.exit();
Pour résumer, pensez non seulement au code que vous écrivez aujourd'hui, mais à celui que les gens utiliseront dans les années à venir. Prenez des décisions réfléchies concernant l'utilisation de packages de code externes ainsi que la structure et les implémentations du projet, de sorte que le produit final puisse être utilisé de manière ergonomique et efficace, reflétant la demande réelle du public cible. Comprendre les commentaires est essentiel et aide grandement à fournir un produit de qualité dont on peut être fier.
- Tom
