« L'excellence n'est jamais accidentelle. Elle est toujours provoquée par des intentions fortes, un dévouement sincère et des actions intelligentes. ce n'est pas le hasard qui déterminera votre destin. "- Aristote Nous voulons tous être les meilleurs dans notre domaine. Les meilleurs, mais peu consacrent le temps et les efforts pour réaliser ce qu'ils veulent. Il est difficile d’être une bonne personne, comme c’est le cas dans n’importe quelle profession.
Il est très difficile d'évaluer l'excellence d'un développeur JavaScript.
Qu'est-ce qui fait un bon développeur JavaScript ?
Nous pouvons porter des jugements en fonction de nombreux critères.Je pense que les points ci-dessus ne fournissent pas de mesures précises. Retarder un projet entier de deux mois afin d'écrire du beau code simplement parce que vous voulez refactoriser quelque chose qui n'aide pas. Nous savons tous que clôturer un ticket ne veut rien dire. Il y a de nombreux facteurs changeants à prendre en compte. Si je demandais à 10 programmeurs différents ce qui, selon eux, fait un bon développeur, je suis sûr que j'obtiendrais 10 réponses différentes. Je crois que vous réfléchissez aussi à sa définition maintenant. J'ai eu du mal avec cette définition pendant un moment, alors j'ai décidé d'essayer de la comprendre. Concentrez-vous sur le travail Je veux trouver certaines choses que tous les développeurs font, puis je peux classer les performances des développeurs en fonction de la façon dont ils le font. C’est trop simpliste de baser une excellente évaluation d’une industrie sur une seule chose, mais je vais quand même essayer.La qualité du code, la livraison dans les délais et la résolution rapide des tickets (remarque : les tickets sont similaires aux problèmes de github, reportez-vous à ici) sont plusieurs normes auxquelles il est possible de se référer. Bien entendu, cela implique également d’aider les autres membres de l’équipe à résoudre les tickets.
Vous pouvez désormais le prendre avec des pincettes.
Je vais essayer de prouver que j'ai fait le bon choix. C'est quelque chose que tous les développeurs font, et cela distingue les bons des médiocres.
Tous les développeurs écrivent du code merdique de temps en temps.
Soyons réalistes, vous et moi écrivons de temps en temps du code tellement trash et honteux que nous ne voulons jamais que quiconque le voie.Avant de montrer quelques atrocités de codage, voyons pourquoi nous écrivons du code merdique. Nous pouvons alors éviter de rester bloqués et de lutter contre les odeurs de code. Raisons courantes pour écrire du code indésirable 1. Presser le temps Le «manque de temps» est actuellement la raison la plus courante pour écrire du code indésirable. Les engagements envers les clients, les calendriers serrés et les nouvelles versions en attente peuvent tous en être la cause. 2. Souffrir profondément La base de code existante est tellement dégueulasse que vous ne voulez même pas travailler dur pour écrire du bon code. Vous savez que peu importe ce que vous faites, vous ne pouvez en aucun cas sauvegarder cette base de code inutile qui s’effondrera à un moment donné. 3. «Je viens de terminer la tâche et je pars» En tant que développeurs, nous travaillons parfois dans différents groupes de projets. Si vous devez passer à un nouveau projet après avoir écrit les dernières lignes de code, ce n'est pas grave et cela affecte les autres. Sachez que votre temps sur ce projet touche à sa fin et que plus personne ne révisera votre code. Il vous suffit donc de valider, de pousser, puis de vous fier aux tests unitaires pour vous assurer qu'il n'y a pas de problèmes. Regardez la vérité Nous écrivons tous du code merdique de temps en temps. Cela signifie-t-il que nous sommes tous de mauvais développeurs ? Bien sûr que non. Ce n’est pas parce que tout le monde écrit du mauvais code de temps en temps. Cependant, au fil des années, j'ai progressivement découvert une vérité surprenante sur les développeurs.Nous avons tous des raisons d'écrire du code merdique de temps en temps. Je ne vais pas entrer dans la discussion sur les raisons valables, car chacun de nous a ses propres raisons valables.
La façon dont nous nous comportons après avoir écrit du code indésirable est un test fondamental de nos qualifications de développeur.
C’est un peu incroyable, mais c’est vrai. La conscience que vous écrivez du code inutile et les actions que vous entreprenez pour éviter que cela ne se reproduise à l'avenir reflètent la façon dont vous écrivez du code et la façon dont vous abordez l'écriture de code en général.Cela a beaucoup à voir avec ça. Prenons Ron comme exemple. Ron a écrit du mauvais code aujourd'hui et n'en était pas content. En raison d'une méchante chaîne d'héritage du modèle Backbone à cinq niveaux de profondeur, Ron ne pouvait pas modifier une seule ligne de code sans tout casser.Dans quelle mesure le code indésirable a-t-il à voir avec l'évaluation de l'excellence des développeurs ?
Ron a écrit un morceau de code super nul pour contourner ce problème. Tout le monde était content car Ron a livré le code à temps. Sauf Ron lui-même.
Il a raconté au chef d'équipe ce qui s'était passé. Ensemble, ils réfléchissaient à la manière de résoudre le problème. Ils ont clairement indiqué que briser la chaîne d'héritage et la diviser en modules composables horizontaux était la meilleure solution.
Ron a alors demandé à son patron de lui laisser du temps pour mettre en œuvre le plan de reconstruction dont lui et son patron venaient de discuter.
Roger a également écrit un code épouvantable aujourd'hui. Il a déclaré à ses collègues développeurs qu'il avait utilisé un hack incroyable pour contourner une étrange chaîne d'héritage de modèle Backbone profonde à cinq niveaux. Il était prêt à parcourir toute la structure et à livrer à temps.
Roger lui-même était très satisfait et estimait qu'il n'y avait pas besoin d'amélioration supplémentaire.
Vous pouvez diviser les programmeurs en quatre catégories, de médiocre à excellent, en fonction de leur attitude à l'égard de l'écriture de code inutile.
Dites-moi que vous n'avez pas rencontré les quatre types de développeurs en même temps.
Barney s'en fiche d'écrire du code merdique. Tout ce qui l'intéresse, c'est de faire le travail à temps ; rien d'autre n'a d'importance. Si le code s'exécute normalement, il n'y aura aucun problème.
Le code poubelle écrit par Barney entrave parfois la progression de l'ensemble du projet. Lorsque vous travaillez sur du code, cela entraînera toujours de nombreux problèmes, ce qui retardera la progression de l'ensemble du projet. Barney sentait qu'il n'avait pas besoin d'apprendre quelque chose de nouveau.
Il sait déjà tout ce qu'il doit savoir sur JavaScript pour faire le travail.
Bill ne se rend pas compte qu'il écrit du code poubelle. Il a suivi l'accord de l'équipe et les règles de charpie et a pensé qu'il n'y avait rien de mal dans ce qu'il avait fait. Mais il n’a pas pris le temps de comprendre toute la structure du projet et la façon dont les différentes composantes interagissaient les unes avec les autres.
Le résultat final est malheureusement le chaos.
Bill n’a consulté personne avant de faire des choix de conception majeurs. Il fait ce qu'il pense. Il a lu trois articles de blog d'il y a un an qui ont guidé sa décision.
Je dis souvent qu'entrer dans le code de Bill ressemble à une guerre de mines, un faux mouvement et tout vous explose au visage.
Nous avons déjà mentionné le type de Roger. Soyez pleinement conscient que vous écrivez du code inutile. Il sait à quoi ressemblerait le code s’il voulait bien l’écrire. Il s'est tapoté dans le dos et a continué à écrire ces conneries.
Le principal problème de Roger est qu’il n’a pas essayé de faire quelques changements. Il a fait ce qu’on lui demandait et il l’a bien fait. Mais il préfère laisser les choses telles qu’elles sont plutôt que de prendre le temps et les efforts nécessaires pour les faire changer.
Ron est un excellent programmeur, mais il doit parfois encore écrire du code inutile.
Ce qui différencie Ron des autres, c'est que lorsqu'il écrit ce code poubelle, il réfléchira sérieusement à la manière d'éviter que cette situation ne se reproduise, ni pour lui ni pour quelqu'un d'autre. Ron déterminera quel type de refactoring est nécessaire et quelles solutions techniques peuvent être modifiées ou améliorées.
Ensuite, sur la base de ces constats, Ron prendra des mesures pour promouvoir ces changements.
Je dois me repentir. Je suis Roger ici. Mais je suis Ron aussi. Je crois aussi que j'ai été Bill par accident à plusieurs reprises sans même le savoir. Je ne pense pas avoir vécu comme Barney, mais qui sait ? Nous faisons tous des allers-retours sur le chemin de l’excellence durable. Parfois nous sommes ordinaires, parfois nous sommes bons ou excellents. J'essaie toujours de ne pas être mauvais.
Le rôle que nous finirons par durer le plus longtemps déterminera quel type de développeur nous sommes.
Pour être honnête, d'un développeur ordinaire à un bon développeur, ce qu'il faut, c'est l'accumulation de plus de connaissances et d'expériences que d'autres choses. Mais pour passer du bon au grand, il vous suffit de changer une chose : votre attitude.
Ce qui précède est la différence entre les développeurs JavaScript avec différents niveaux d'excellence. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (m.sbmmt.com)« N'oubliez pas qu'avant de pouvoir être génial, vous devez être bon. Avant de pouvoir être bon, vous devez être mauvais. Mais avant de pouvoir être mauvais, vous devez essayer. - Art Williams
.