Que ce soit dans le développement, les tests ou l'exploitation, chaque professionnel technique nourrit plus ou moins le rêve de devenir un maître technique. Après tout, « Il faut avoir un rêve, au cas où il se réaliserait » ! C'est précisément la poursuite de ce rêve technique qui nous pousse à travailler dur et à nous améliorer continuellement.


Cependant, « les rêves sont beaux, mais la réalité est cruelle ». Beaucoup d'étudiants découvriront après avoir réellement travaillé que le rêve est de devenir un maître, mais que ce qu'ils font semble totalement étranger à la condition de maître. Par exemple, les programmeurs disent : « Écrire du code métier tous les jours et faire des heures supplémentaires, comment puis-je devenir un maître technique ? » Les testeurs disent : « Il y a d'interminables cas de test à exécuter chaque jour. » Le personnel d'exploitation dit : « Transporter des machines, connecter des câbles réseau et taper des commandes shell — ce n'est pas la vie d'exploitation que je voulais. » ...... Sur Zhihu, une question similaire, « Les programmeurs qui écrivent du code métier tous les jours, comment peuvent-ils devenir des maîtres techniques et commencer à écrire du code technique ? » a 6K+ abonnés et 120+ réponses. À l'époque, j'y ai aussi répondu et j'ai reçu le plus de votes positifs. Plus tard, en menant des évaluations et des communications de promotion de niveau de carrière, j'ai acquis de nouvelles découvertes et idées, alors j'ai eu l'idée d'organiser systématiquement un article, en espérant aider plus d'étudiants à éviter les détours sur la voie pour devenir un maître technique.


Comme je suis programmeur, certains des exemples ci-dessous sont fondés sur le développement logiciel, mais les principes généraux sont universels, et les testeurs ainsi que le personnel d'exploitation peuvent aussi en tirer des enseignements.


Plusieurs idées fausses typiques


1. Prendre un maître technique comme professeur


Certaines personnes sur Zhihu pensent que la façon la plus simple, la plus directe, la plus rapide et la plus efficace de devenir un maître technique est de « prendre le maître technique d'une équipe comme professeur » et de lui demander de vous donner un encadrement supplémentaire et de vous confier quelques tâches difficiles.


Personnellement, je suis contre cette approche pour plusieurs raisons principales :


  • Les maîtres sont très occupés et il est peu probable qu'ils vous donnent un encadrement individuel, encore moins une heure d'encadrement chaque jour. De plus, au sein d'une équipe, si un maître vous donne souvent un encadrement particulier, cela suscitera inévitablement la suspicion parmi les autres membres de l'équipe. Personnellement, je pense que si un maître se soucie vraiment, le mieux est de dispenser davantage de formations à l'équipe. Cependant, quiconque a déjà donné une formation sait que préparer une session de formation prend beaucoup de temps. Les supports de cours et les documents prennent au moins 2 heures (et ne peuvent pas être réalisés en temps fragmenté), et l'explication prend 1 heure. Qu'un maître donne une formation une fois par mois est déjà très fréquent.
  • En raison de la première raison, lorsque vous souhaitez généralement consulter un maître, vous devriez venir avec des questions précises pour demander conseil ou discuter. Comme répondre à des questions ou en discuter ne prend pas trop de temps et repose davantage sur l’expérience et les connaissances accumulées, les maîtres sont généralement heureux de le faire—après tout, l’influence est un indicateur important d’un maître. Cependant, une attention particulière est nécessaire : si vous posez souvent des questions sur des connaissances faciles à trouver dans les livres ou sur Google, les maîtres finiront aussi par s’impatienter, car le temps est précieux. Souvent, des internautes me posent des questions comme « Comment configurer le paramètre JVM -Xmn ? » et je réponds directement : « Veuillez simplement rechercher sur Google », car il y a trop de questions de ce type. Si vous n’apprenez pas systématiquement par vous-même, poser chaque question individuellement fait perdre du temps à vous comme aux autres.
  • Les maîtres sont rares ; il est peu probable que chaque équipe ait un maître technique. Au mieux, il y a dans l’équipe des personnes plus compétentes que vous. Même s’il vous encadre tous les jours, vous ne pourrez au mieux vous améliorer que jusqu’à son niveau. Si le maître technique vient d’une autre équipe, en raison de l’organisation et de la répartition du travail, les occasions de consultation directe et de mentorat sont relativement rares. Assister seul à quelques formations du maître ne suffira probablement pas à faire de vous un maître technique.

Pour les raisons ci-dessus, je pense que pour la plupart des gens, pour devenir un maître technique, il faut d’abord comprendre le principe « compter principalement sur soi-même » et ne pas s’attendre à ce qu’un maître, comme un professeur d’arts martiaux, vous enseigne pas à pas, main dans la main. Aux moments appropriés, vous pouvez vous améliorer en consultant ou en discutant avec des maîtres, mais la plupart du temps, vous devriez encore vous améliorer de manière systématique et ciblée par vous-même.


2. Le code métier peut aussi être génial


Certaines réponses sur Zhihu soutiennent que l’écriture de code métier peut aussi être géniale, car le code métier peut aussi impliquer diverses techniques. Par exemple, vous pouvez utiliser l’encapsulation et l’abstraction pour rendre le code métier plus extensible, vous pouvez davantage communiquer avec l’équipe produit pour mieux comprendre et implémenter le métier, et avec une bonne journalisation, l’efficacité de localisation des problèmes peut être multipliée par 10... et ainsi de suite.


Il est certain que le code métier a aussi un contenu technique ; la technique dans le code métier est la base de chaque programmeur. Mais le simple fait de maîtriser ces techniques ne fait pas de vous un maître technique. C’est comme monter de niveau en combattant des monstres dans un jeu. Au début, combattre de petits monstres rapporte beaucoup de points d’expérience. Plus vous avancez, moins vous gagnez de points d’expérience. Combattre de petits monstres ne permet plus d’améliorer votre expérience, et à ce moment-là, vous devez combattre des monstres de niveau supérieur et terminer des donjons difficiles. Je n’ai jamais vu un jeu où l’on peut atteindre le niveau maximal en ne combattant que de petits monstres. Le chemin pour devenir un maître technique est similaire. Vous devez continuellement améliorer votre niveau, puis affronter de plus grands défis. En relevant ces défis, vous élevez votre niveau au niveau suivant, puis vous répétez le cycle, jusqu’à atteindre le domaine de maître technique, voire de maître de l’industrie. Écrire du code métier n’est qu’un défi sur cette route de progression, et je pense que c’est un défi relativement élémentaire.


Donc je crois : un programmeur qui ne sait pas bien écrire du code métier ne peut certainement pas devenir un maître technique, mais un programmeur qui ne fait que bien écrire du code métier n’est pas encore non plus un maître technique.


3. Le travail est trop prenant et il n’y a pas de temps pour étudier par soi-même


Beaucoup de gens pensent que la raison pour laquelle ils ne sont pas devenus un maître technique n’est pas qu’ils sont peu intelligents ou pas travailleurs, mais que dans l’environnement chinois, le personnel technique fait trop d’heures supplémentaires, ce qui ne leur laisse pas de temps supplémentaire pour étudier.


Cette raison est quelque peu objective. Après tout, comparés à l'Europe et aux États-Unis, nous faisons effectivement plus d'heures supplémentaires, mais ce facteur n'est qu'un problème à surmonter, pas un fossé insurmontable. Après tout, il y a encore beaucoup de maîtres autour de nous qui ont grandi dans cet environnement chinois.


Je pense qu'il y a plusieurs idées fausses qui conduisent à ce point de vue :


1) Le travail au bureau est entièrement répétitif ; pour progresser, il faut étudier en plus en dehors du travail.


La principale raison de cette idée fausse reste la croyance selon laquelle « écrire du code métier n'a pas de contenu technique », et comme j'écris du code métier au travail, je ne peux pas progresser au travail.


2) L'apprentissage exige de longues périodes de temps continues


Beaucoup de gens pensent que pour étudier, il faut avoir une journée entière de cours comme à l'école. Comme nous faisons beaucoup d'heures supplémentaires, le week-end, nous sommes tellement fatigués que nous voulons seulement faire la grasse matinée, ou simplement regarder des films et jouer à des jeux pour nous détendre, donc il n'y a pas de temps pour étudier.


L'approche réelle est tout le contraire : d'abord, nous devrions apprendre et progresser au travail, car apprendre en appliquant ou en ayant de vrais exemples donne les meilleurs résultats ; ensuite, après le travail, l'apprentissage n'exige pas de grandes plages de temps, mais plutôt de trouver du temps et d'utiliser des fragments de temps pour étudier.


La bonne approche


1、Faire plus


Faire plus—faire plus que les tâches que votre supérieur vous assigne.


Lorsque j'étais chez HW, j'étais chargé de développer une version. La charge de travail pour cette version était d'environ 2 000 lignes, mais en plus d'achever la fonctionnalité, j'ai aussi compris en profondeur toutes les fonctionnalités associées et lu tout le code (environ 10 000 lignes). Après avoir terminé cette version, je connaissais bien l'ensemble du métier lié à cette version. Après une ou deux réunions, tout le monde a constaté que c'était moi qui connaissais le mieux ce domaine. Ensuite, les choses sont devenues intéressantes : les discussions produit me sollicitaient, les testeurs venaient me voir pour les problèmes, et mon patron venait me voir pour le support externe. Plus tard, même pour des fonctionnalités qui ne relevaient pas de ma responsabilité, on venait me voir. Même si je ne savais pas sur le moment, je lisais le code ou cherchais des documents pour les aider à répondre... Au final, je suis devenu l'« expert » de ce système. Bien qu'à cette époque je fisse encore du métier et que j'écrivisse du code métier, j'étais devenu familier avec l'ensemble du métier.


Ce qui précède n'est qu'un simple exemple. En fait, cela montre que pour avoir des opportunités, vous devez d'abord sortir du lot. Pour sortir du lot, vous devez être différent. Pour être différent, vous devez en faire plus !


Comment en faire plus ? Vous pouvez commencer par les aspects suivants :


1) Familiarisez-vous avec davantage de domaines métier, que ce soit le vôtre ou non ; familiarisez-vous avec davantage de code, que vous l'ayez écrit ou non.


Cela présente de nombreux avantages. Voici quelques exemples simples :


  • L'analyse des exigences devient plus précise, et les risques, les impacts et les difficultés peuvent être identifiés dès l'étape des exigences.
  • Le traitement des problèmes devient plus rapide, car vous connaissez le métier et le code associés, et pouvez rapidement déterminer les causes possibles, puis diagnostiquer et traiter les problèmes.
  • La conception de solutions devient plus complète ; avec une compréhension de l'ensemble du métier, vous pouvez concevoir de meilleures solutions.

2) Familiarisez-vous avec le processus de bout en bout


Par exemple, si vous êtes responsable du développement backend web, en réalité, lorsqu'un utilisateur lance une requête HTTP, celle-ci passe par de nombreuses étapes intermédiaires avant d'atteindre votre serveur (par exemple, le cache du navigateur, DNS, nginx, etc.). Le serveur passe généralement par de nombreuses étapes de traitement avant d'atteindre la partie du code que vous avez écrite (routage, autorisations, etc.). Pour de nombreux systèmes ou étapes dans l'ensemble de ce processus, la grande majorité des personnes ne peuvent pas participer à l'écriture du code, mais la maîtrise de ces connaissances a un grand effet sur votre niveau global. Par exemple, les travaux techniques à plus forte valeur ajoutée tels que la conception de solutions et la gestion des pannes en ligne exigent tous un niveau technique complet.


Des mots comme « systématique », « global » et « complet » peuvent sembler vagues, mais ce sont en réalité des qualités essentielles d'un maître technique. Pour atteindre un tel niveau, vous devez vous familiariser avec davantage de systèmes, de domaines métier et de code.


3) Auto-apprentissage


Normalement, dans une équipe relativement mature, comme les frameworks ou les composants ont été fortement encapsulés, la technologie utilisée pour écrire du code métier est en effet limitée. Mais nous devons comprendre que « la seule constante, c'est le changement ». Le framework peut avoir besoin d'être amélioré, les composants peuvent avoir besoin d'être remplacés, ou vous pouvez rejoindre une entreprise où il n'existe ni composants ni frameworks et où vous devez repartir de zéro. Ce sont à la fois des opportunités et des défis, et les opportunités et les défis ne sont donnés qu'à ceux qui sont préparés. Par conséquent, dans ce cas, nous devons encore plus nous auto-former, car au moment où vous en aurez réellement besoin, il sera trop tard pour apprendre.


Prenons Java comme exemple. La plupart du code métier n’est qu’un if-else plus une opération de base de données, mais nous pouvons tout à fait apprendre par nous-mêmes davantage de connaissances Java, comme le ramasse-miettes, l’optimisation, la programmation réseau, etc. Elles peuvent sembler inutiles pour l’instant, mais quand vous en aurez vraiment besoin, il ne suffira pas de faire une simple recherche sur Google. À ce moment-là, celui qui aura déjà maîtrisé les connaissances et compétences pertinentes obtiendra l’opportunité.


Prenons le ramasse-miettes comme exemple : j’ai personnellement pris le temps d’apprendre ces connaissances pendant mon temps libre et je ne les ai pas utilisées pendant un an. Mais plus tard, je les ai utilisées plusieurs fois, et chaque fois elles ont résolu des problèmes majeurs de gel du système. Pendant ce temps, certains étudiants qui écrivent du code Java depuis plusieurs années ne savent même pas ce qu’est le concept de stop-the-world, encore moins comment l’optimiser.


2、Faire mieux


Sachez que rien dans ce monde n’est parfait. Les systèmes et le métier dont vous êtes responsable auront toujours des aspects déraisonnables et des points à améliorer. Ces endroits « déraisonnables » et « améliorables » sont tous des monstres de niveau supérieur : les vaincre vous rapporte plus de points d’expérience. Identifiez ces zones, trouvez des solutions et proposez-les à votre supérieur. Si cela ne fonctionne pas la première fois, proposez à nouveau. Tant qu’une proposition est mise en œuvre, c’est votre opportunité.


Par exemple :


  • Il y a trop de code dupliqué — pouvons-nous introduire des patrons de conception ?
  • Les performances du système sont moyennes — peuvent-elles être optimisées ?
  • Il s’agit actuellement d’une configuration à une seule machine — serait-il préférable d’en faire une configuration à deux machines ?
  • La qualité du développement des versions n’est pas élevée — pouvons-nous introduire des solutions efficaces de tests unitaires et de tests d’intégration ?
  • Le système actuel est trop volumineux — pouvons-nous le refactoriser et le découpler en trois systèmes ?
  • Certains systèmes d’intergiciel d’Alibaba semblent être des choses que nous pourrions aussi utiliser — pouvons-nous les introduire ?
  • 。。。。。。。。。。。。。。。。。。。

Tant que vous y réfléchissez, vous pouvez toujours trouver des axes d'amélioration. Si vous avez l'impression qu'il n'y a aucun endroit dans votre système qui puisse être amélioré, cela signifie que votre niveau de compétence n'est pas encore suffisant. Renseignez-vous davantage sur les technologies associées et voyez comment les autres entreprises du secteur procèdent—comment les entreprises BAT procèdent.


En 2013, j'ai été transféré à Jiuyou. Au début, j'ai repris un simple système backend. Chaque jour, je ne faisais que des opérations CRUD de données pour le frontend. Cela semblait totalement inintéressant, non ? Si vous ne faites que ces choses, c'est vraiment ennuyeux. Mais après avoir repris ce système, nous avons fait beaucoup de choses :


  • Découplage : diviser un backend en deux backends pour améliorer l'évolutivité et la stabilité ;
  • Double machine : faire passer une configuration mono-machine à un système à deux machines pour améliorer la fiabilité ;
  • Optimisation : optimisation d'une interface qui prenait à l'origine 5 heures à s'exécuter, ramenée à 5 minutes ;

Il y a eu beaucoup d'autres optimisations également. Plus tard, notre groupe a repris davantage de systèmes. Finalement, cette petite équipe de 5 personnes était responsable de 6 systèmes.


3、Faire de l'exercice


Lors des échanges sur les niveaux de carrière, j'ai constaté que beaucoup de personnes essayaient effectivement de faire plus et de faire mieux, mais dans le processus d'exécution, presque tout le monde rencontrait le même problème : le simple fait de lire sans mettre en pratique donne de mauvais résultats—que devons-nous faire ?


Par exemple :


  • J'ai appris la collecte des déchets de la JVM, mais en production, il y a rarement des problèmes de latence causés par FGC. Même si cela se produit, rétablir l'activité est la priorité absolue. Il est peu probable qu'un problème de production survienne et permette à tout le monde de s'exercer dessus. Alors comment puis-je pratiquer cette connaissance et cette compétence de la JVM ?
  • J'ai aussi lu sur Netty et je comprends les principes de Reactor, mais je ne peux pas participer au développement de Netty. Comment puis-je vraiment maîtriser le modèle asynchrone Reactor ?
  • J'ai lu « High Performance MySQL », mais les bases de données de production sont gérées par des DBA, et les bases de données de l'environnement de test donnent l'impression d'être configurées au hasard. Comment puis-je vérifier ces techniques ?
  • Le framework encapsule la couche DAL, donc nous n'avons pas besoin de nous soucier de l'accès à la base de données. Comment se renseigner sur les implémentations de sharding et de partitionnement de tables ?
  • 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

Il y a beaucoup de questions comme celles-ci. Laissez-moi partager mon expérience personnelle ici. Cela se résume en trois mots : apprendre, essayer, enseigner !


1）Apprentissage


C'est la première étape. Lire des livres, chercher sur Google, regarder des vidéos et lire les blogs d'autres personnes sont toutes des approches efficaces, mais il faut noter une chose : la « systématisation », en particulier pour les sujets fondamentaux tels que les principes de la JVM, la programmation Java, la programmation réseau et le protocole HTTP... et ainsi de suite. Ces technologies fondamentales ne peuvent pas être apprises uniquement via Google ou des blogs. Mon approche consiste généralement d'abord à lire un livre complet pour acquérir une compréhension globale, puis à utiliser Google, des vidéos et des blogs pour rechercher des points de doute précis ou quelques astuces.


2）Essai


Cette étape est la clé pour répondre aux doutes mentionnés plus haut par beaucoup de personnes. Pour parler par image, c'est « faites-le vous-même et vous en aurez à profusion » — c'est-à-dire : mettez en place vos propres environnements simulés et écrivez vos propres programmes de test. Par exemple :


  • Ramasse-miettes de la JVM : vous pouvez écrire un programme de test simple qui alloue de la mémoire sans la libérer, puis ajuster divers paramètres de démarrage de la JVM, et pendant l'exécution utiliser des commandes comme jstack et jstat pour inspecter la répartition de la mémoire du tas de la JVM et l'état du ramasse-miettes. Un tel programme est très simple à écrire — un programme simple ne fait que quelques lignes, et un plus complexe seulement quelques dizaines de lignes.
  • Principes de Reactor : essayez réellement d'écrire vous-même une démo du modèle Reactor. Ne pensez pas que c'est trop difficile — l'implémentation la plus simple du modèle Reactor, commentaires inclus, ne dépasse pas 200 lignes. Vous pouvez vous référer au PPT de Doug Lea. Après l'avoir écrit vous-même, allez voir comment Netty l'implémente. En comparant les deux, votre compréhension deviendra bien plus profonde.
  • MySQL : puisqu'il existe une configuration de production à laquelle se référer, vous pouvez directement demander au DBA de nous envoyer la configuration de production (n'oubliez pas de supprimer les informations sensibles) et vous en inspirer directement. Ensuite, installez votre propre environnement MySQL et démarrez-le avec la configuration de production. Vous devez savoir que beaucoup de gens utilisent MySQL depuis des années mais ne savent même pas mettre en place un simple environnement MySQL.
  • Le framework encapsule la couche DAL : vous pouvez essayer d'écrire une implémentation simple de partitionnement (sharding) de base de données/table à l'aide de JDBC, puis la comparer avec l'implémentation du framework pour voir où se situent les différences.
  • Utilisez les outils du navigateur pour inspecter les implémentations du cache HTTP et voir comment différents types de sites web et différents types de ressources contrôlent la mise en cache. Vous pouvez également écrire un simple serveur HTTP en Python qui renvoie divers en-têtes HTTP pour observer le comportement du navigateur.
  • 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

Il existe bien d'autres méthodes, et je ne les énumérerai pas une par une ici. En bref, vous devez véritablement essayer ce que vous avez appris afin de le comprendre plus profondément. Il y a un proverbe amérindien : « J'entends et j'oublie. Je vois et je me souviens. Je fais et je comprends. » De plus, « essayer » peut en réalité être assez simple — dans de nombreux cas, nous pouvons le faire nous-mêmes.


Bien sûr, si vous pouvez l'utiliser dans le travail réel, l'effet est encore meilleur. Après tout, l'environnement de production réel et la complexité métier ne sont pas quelque chose qu'un programme de simulation peut reproduire. Mais ces occasions sont rares, et dans la plupart des cas, nous ne pouvons vraiment compter que sur des simulations construites par nous-mêmes. Ensuite, lorsque l'activité réelle en a besoin, nous pouvons l'utiliser sans effort.


3）Enseignement


D'une manière générale, après avoir appris et essayé, vous pouvez maîtriser environ 70%. Mais pour vraiment maîtriser quelque chose, je crois que vous devez être capable de l'expliquer clairement aux autres. Lorsque vous expliquez, vous devez non seulement systématiser un point de connaissance, mais aussi prendre en compte divers détails, ce qui nous pousse à réfléchir et à apprendre davantage. En même temps, après l'explication, les personnes qui écoutent peuvent avoir des interprétations différentes ou de nouveaux compléments, ce qui permet effectivement d'améliorer continuellement l'ensemble du système de connaissances et de compétences.


Il existe de nombreux exemples de ce genre, notamment lorsque j'écris mon blog : je le rencontre souvent. Je pense d'abord avoir maîtrisé quelque chose de manière exhaustive, mais dès que je commence à écrire, je découvre de nombreux points que je n'avais pas pris en compte. Je le vois aussi souvent lors des formations internes d'équipe : certaines personnes rédigent un PPT, mais lors de la présentation, dès que tout le monde pose des questions ou discute, elles constatent que de nombreux points n'ont pas été clairement expliqués, ou que certains points sont mal compris. Parcourir tout le processus de rédaction d'un PPT, de sa présentation et de sa discussion permet globalement d'acquérir une compréhension assez complète d'un point de connaissance.


Postface


Le rêve de devenir un expert technique est beau, mais il exige beaucoup d'efforts. Qu'il s'agisse de Do more, de Do better ou de Do exercise, tout demande du temps et de l'énergie. Ce processus peut être douloureux ou ennuyeux. Ici, je tiens à souligner : ce que j'ai partagé ci-dessus relève de méthodologies, mais ce qui joue véritablement le rôle décisif, c'est en réalité notre passion et notre intérêt pour la technologie !