Pause café #43. 6 erreurs de programmation qui vous empêchent d'obtenir l'emploi de vos rêves. Comment contribuer aux logiciels Open Source pour la première fois

6 erreurs de programmation qui vous empêchent d'obtenir l'emploi de vos rêves

Source : Medium Pour trouver un emploi de programmeur, vous devez disposer d'un référentiel Git. C’est l’une des premières choses que les recruteurs examineront. Pour que votre référentiel fasse une impression positive, il doit contenir des projets avec des modifications récentes. Montrez uniquement les projets dont vous êtes fier, pas toutes les lignes de code que vous avez écrites. Ce sont les bases du travail avec un référentiel. N'oubliez pas que tôt ou tard, quelqu'un examinera votre code pour voir si vous correspondez bien à l'entreprise. Ce sera un moment décisif pour vous. Après quelques minutes, le recruteur décidera s’il vous invite à un entretien. Et ici, il y a à la fois de bonnes et de mauvaises nouvelles. La mauvaise nouvelle est qu’une simple erreur peut nuire à vos chances d’obtenir un emploi. La bonne nouvelle est que les gens ne veulent généralement pas approfondir le code. Ils ont besoin d’une compréhension générale de votre code et de votre architecture. Il n’est donc pas nécessaire d’être un génie, il vous suffit d’être un bon programmeur. Voici quelques erreurs courantes commises par les débutants. Évitez-les et vos chances d’entretien augmenteront considérablement.

Commentaires obsolètes

Les programmeurs ont des opinions différentes sur les commentaires. Certains les aiment, d’autres les détestent. Nous ne pouvons pas parvenir à une conclusion commune quant à savoir s'il vaut la peine de commenter le code et dans quels cas le faire. Mais tout le monde est unanime sur une chose : si vous avez des commentaires, ils doivent correspondre à votre code. Des commentaires existent pour expliquer le code. Lorsque votre code est complexe ou peu clair, vous avez besoin d’aide pour que les lecteurs le comprennent. Vous devez également modifier votre commentaire lorsque vous modifiez le code. Si vous ne le faites pas, votre commentaire ne sera plus utile. Un mauvais commentaire est bien pire que l’absence de commentaire. Pour aggraver les choses, les commentaires sont mis en évidence dans le code. Les IDE modernes mettent en évidence les commentaires dans une couleur différente pour les rendre plus faciles à lire. En ajoutant un commentaire, vous placez un signe « lisez-moi » dans le code. De cette façon, toute divergence entre le commentaire et le code sera facilement détectée. Choisissez judicieusement vos commentaires et n'oubliez pas de les mettre à jour avec votre code. De cette façon, ils vous serviront bien.

Combinaison de bibliothèques et de langages avec les mêmes cas d'utilisation

Avant le premier entretien, j'ai dû résoudre un problème de recrutement. C'était une simple application Web, j'ai donc écrit du code, recherché sur Google quelques questions complexes et l'application était prête. Au cours de l'entretien, le recruteur m'a demandé pourquoi j'avais mélangé du code jQuery avec du JavaScript simple dans tout le code. Ma réponse? "Euh..." Pour être honnête, j'ai collé quelques extraits de code de Stack Overflow. Je n'y ai pas beaucoup réfléchi. Le code a fonctionné, alors j'ai continué. Cette erreur est très courante chez les nouveaux développeurs. Nous sommes tellement concentrés sur la résolution des problèmes au travail que nous ne prêtons pas attention à la manière dont nous le faisons. Ne faites pas partie des débutants qui tombent dans ce piège. Examinez chaque ligne de code et assurez-vous de savoir pourquoi vous l'avez mise ici.

Répétition de codes

Ne vous répétez pas (DRY) est un dogme de programmation. Créer des abstractions pour du code répétitif est l'essence même de la programmation. Oui, cela peut être difficile au début. Lorsque vous souhaitez résoudre un problème, vous le faites de toutes les manières possibles. Ensuite, vous passez à d’autres tâches et le code répétitif reste avec vous. Vous pouvez vous débarrasser de cette habitude en vous créant un ensemble de règles. Chaque fois que vous affinez une fonctionnalité, relisez le code et voyez si vous pouvez faire quelque chose pour le modifier. N'oubliez pas que la première version du code est généralement erronée et que vous pouvez l'améliorer. Lorsque vous remarquez du code en double, prenez le temps de l’étudier. De cette façon, vous pouvez trouver la meilleure façon de le réécrire (par exemple, en utilisant une boucle ou en créant une nouvelle fonction). Si vous faites ce nettoyage à chaque fois, vous obtiendrez un code plus fiable et plus élégant.

Erreurs non gérées

Il est presque impossible de créer une application significative qui fonctionnera toujours parfaitement. Que vous remplissiez une base de données ou que vous effectuiez des appels d'API, des erreurs se produisent. Les erreurs non gérées peuvent non seulement empêcher l’exécution de fonctions individuelles, mais peuvent même provoquer le crash de l’ensemble de l’application. Anticiper les erreurs possibles est le signe d’un programmeur compétent. Chaque fois que vous accédez ou mettez à jour des données externes, vous devez vous préparer au pire des cas. Signalez les problèmes potentiels de manière à ne pas rendre l'application lourde. Cela permettra aux lecteurs de votre code (et peut-être à vous) de trouver rapidement les erreurs. Cela montrera également au recruteur que vous pouvez écrire du code cohérent.

Manque de cohérence

La cohérence est la marque d’un logiciel de qualité. Cela rend le code plus facile à lire et à maintenir. Le code créé dans un style uniforme est plus prévisible et il est plus facile d'évaluer les performances du programme. À un niveau d’abstraction plus élevé, la cohérence est difficile à atteindre. Il faudra des années pour la maîtriser, vous devez donc commencer à apprendre cette technique le plus tôt possible. N'oubliez pas de créer des titres en utilisant une seule langue. Cela devrait probablement être l'anglais, mais dans les projets personnels, vous pouvez nommer des variables et des fonctions dans n'importe quelle langue à condition que ce soit toujours la même langue. Si vous êtes cohérent, peu importe que vous utilisiez des tabulations ou des espaces. Créez ou choisissez un guide de style et respectez-le toujours. Vous devriez également utiliser un outil comme Prettier . Cela aide vraiment à garder le code formaté de manière cohérente. Quels que soient les outils et les styles que vous utilisez, utilisez-les de manière cohérente. Même si vous écrivez du mauvais code dans un style cohérent, c'est généralement mieux qu'un bon code incohérent car il est beaucoup plus facile à corriger.

Incompréhension des outils

Dans un projet typique, vous devrez probablement utiliser une bibliothèque externe. De nombreux programmeurs installent les bibliothèques presque automatiquement car elles sont utilisées dans chaque projet. Les bibliothèques externes sont formidables car elles constituent un moyen éprouvé de résoudre des problèmes récurrents. Cependant, les nouveaux développeurs ne comprennent souvent pas quelles bibliothèques ils utilisent et finissent par ajouter une bibliothèque par-dessus une autre ou par réimplémenter certaines fonctionnalités existantes. Chaque fois que vous installez une bibliothèque dans votre projet, lisez ou au moins consultez la documentation. Vérifiez les méthodes et les propriétés que vous pouvez utiliser et assurez-vous de comprendre quels problèmes la bibliothèque doit résoudre et lesquels nécessitent l'utilisation d'un outil différent. De cette façon, vous pouvez choisir les bons outils pour le travail et expliquer vos choix.

Comment contribuer aux logiciels Open Source pour la première fois

Source : Jamestucker.dev L'autre jour, j'ai vu un tweet d'Evan Yu (créateur de Vue.js ) à propos d'un nouveau référentiel sur lequel il travaillait et cela m'a intéressé. J'ai décidé que je voulais y contribuer ! Le problème, c'est que je n'ai jamais contribué à des projets open source auparavant et que je ne savais pas par où commencer. Mais ça ne doit pas être si difficile, n'est-ce pas ? Une fois entré dans le référentiel, je me suis immédiatement figé. « Que dois-je faire ? » me suis-je dit. Si je fais un PR (pull request, merge request), les spécialistes vont probablement déchirer mon code en morceaux. Je serai toujours connu dans le monde du développement comme celui qui ne sait pas comment travailler correctement avec l'open source. Et ma carrière prendra fin. Heureusement, j'ai lu un article (je ne me souviens plus où) dont l'auteur conseillait que votre première contribution au référentiel de quelqu'un d'autre soit aussi discrète que possible. Cela peut être quelque chose d'aussi simple que de corriger une faute de frappe. Et c’est ce que j’ai fait. J'ai lu la documentation du référentiel, trouvé quelques fautes de frappe, ouvert un PR et voilà, Evan a approuvé mes modifications. Je suis officiellement un contributeur Vue ! Peut-être devrais-je mettre cela dans ma bio Twitter ?

"C'est super, mais par où commencer ?"

Bon, commençons : je vais vous montrer les étapes que vous pouvez suivre pour faire la différence.

1. Trouver un projet

Pour vous inspirer, pensez à votre technologie ou outil préféré. Disons que vous travaillez avec JavaScript et que vous utilisez beaucoup Gatsby ? Consultez leur référentiel ! Vous pouvez également contribuer à l'un de mes référentiels. Voici une liste de mes projets frontend. Si vous avez quelque chose que vous aimez ou que vous trouvez utile, j'aimerais que vous l'ajoutiez ! Enfin, Awesome First PR Opportunities est un référentiel géant de projets open source pour les débutants. Il y a des projets dans 22 langues différentes !

2. Décidez comment vous pouvez contribuer

Découvrez le projet. Lisez le fichier Lisez-moi. Scannez différents dossiers et fichiers. Acquérir une compréhension de la structure de la base de code. En faisant cela, vous pouvez facilement trouver et corriger la faute de frappe ! Une fois que vous avez fait cela, jetez un œil à la section Problèmes du projet. Vous y trouverez une liste de bugs précédemment trouvés ou de fonctionnalités suggérées. Heureusement, de nombreux projets impliquent des problèmes destinés aux débutants. Je pense que votre première contribution doit être la plus subtile possible, mais si vous souhaitez être rapidement reconnu, c'est à vous de décider. Une fois que vous avez trouvé quelque chose que vous pouvez ajouter au projet, vous devrez le créer.

3. Créer un fork du projet

Un fork (fork d'un projet) en crée une copie exacte dans votre propre référentiel Github.

4. Clonez le projet localement

Clonez ensuite le projet dans un dossier local à l'aide de l'URL du projet.

git clone <project-url>

Vous trouverez ici l'URL. Maintenant que le projet est sur votre ordinateur, ouvrez-le dans un éditeur. Si vous pensez que les modifications prendront du temps, assurez-vous de synchroniser une copie du projet avec l'original afin d'être toujours au courant des modifications. Vous pouvez trouver les commandes Git exactes pour cela ici .

5. Créez une nouvelle branche pour vos modifications

Il est temps d'effectuer vos modifications/corrections ! Créez une nouvelle branche où vos modifications prendront effet.

git branch <branch-name>

Vous pouvez l'appeler comme vous le souhaitez, mais d'après mon expérience, vous pourrez voir un modèle pour nommer les branches dans le projet d'origine. Dans ce cas, je recommande de suivre le modèle existant. Un bon nom de branche pour corriger la faute de frappe serait patch/typo-fix . Vous pouvez basculer vers cette branche en utilisant git checkout <branch-name> . Maintenant, effectuez vos modifications !

6. Ouvrez un PR (demande de fusion)

Vous avez donc corrigé une faute de frappe flagrante ou mis à jour un lien rompu. Vous êtes fier de votre travail. Vous voulez que le monde entier sache que vous faites partie de ces développeurs mythiques qui peuvent coder, effacer et regarder Netflix en même temps. Envoyez vos modifications vers un référentiel Github ramifié à l'aide de git push -u origin <branch-name> . Accédez à votre référentiel Github forké et ouvrez un PR (pull request). Remarque : Si vous n'avez jamais effectué de pull request auparavant, regardez cette vidéo de Kent Dodds pour savoir comment procéder. Assurez-vous que votre branche pointe vers la branche principale du référentiel source. Vous êtes maintenant prêt à ajouter des détails à votre PR. Assurez-vous que votre titre transmet clairement le contenu du PR. Ajouter une description : si vous résolvez un problème existant, assurez-vous d'inclure un lien vers celui-ci. Une fois que vous avez terminé votre description, soumettez votre PR pour examen. Quiconque a le pouvoir d'approuver la RP examinera probablement votre demande dans quelques jours et effectuera l'une des opérations suivantes :

1. Fusionnera les modifications immédiatement.
2. Il vous demandera d'apporter des modifications.
3. Fermera votre PR.

Soyez patient car le créateur du référentiel peut être occupé par un travail à temps plein ou d'autres projets.

Tu l'as fait!

Vous êtes désormais contributeur au projet open source ! Comment ça se sent ? Prêt à créer votre propre concurrent Node.js ? J'espère qu'en apportant une simple contribution, les perspectives des futurs travaux open source deviendront moins intimidantes. Pour plus d'informations sur les contributions open source, consultez les guides open source .