Le point de vue de Yao Dong

La capacité d'apprentissage, en particulier la capacité d'auto-apprentissage, quand avez-vous déjà vu ces célèbres experts en programmation poser des questions sur les forums : « Quel livre dois-je lire pour apprendre XX,comment apprendre XXX rapidement,quel code recommandez-vous pour apprendre XXX » ? Quoi qu'ils veuillent apprendre, ils peuvent trouver rapidement par eux-mêmes de la documentation pertinente. Cette industrie évolue trop vite, et la technologie devient obsolète très rapidement. Si vous n'apprenez rien de nouveau pendant 3 ans, vous risquez de prendre du retard.

La capacité pratique, tout le monde lit des livres et des documents, mais alors que d'autres se torturent encore l'esprit à se demander quel livre lire et ce que signifient les mots du livre, certaines personnes ont déjà fait tourner des centaines ou des milliers de lignes de code.

La patience et la persévérance, l'intérêt est certainement important pour un programmeur — écrire du code que l'on aime est une chose très agréable — mais dans le développement logiciel, il y aura toujours une grande quantité de travail ennuyeux et sans intérêt, et vous devez persévérer et serrer les dents pour le terminer.

La capacité d'expression, être capable de présenter ses idées de manière logique, fluide et claire en public afin que les gens comprennent.

Et les compétences techniques ? Les compétences techniques ne sont pas importantes. Avec les capacités ci-dessus, quelle que soit la technologie dont le marché a besoin, vous pouvez la maîtriser rapidement.

Enfin, parlons du salaire. Retenez deux phrases :

• Le salaire n'est pas la récompense du patron pour vos contributions passées, mais son attente à l'égard de vos contributions futures.
• Votre patron actuel ne vous donnera jamais un salaire satisfaisant ; seul votre prochain patron le fera.

Le point de vue de Cao Zheng

Yao Dong a très bien répondu. Laissez-moi ajouter quelques mots en complément.

Nous savons tous que la capacité d'apprentissage est très importante, mais d'où vient-elle ? En dehors de la lecture de livres et des cours, comment apprend-on et grandit-on dans le travail pratique ?

J'ai exposé auparavant un concept général sur Weibo : qu'est-ce que la capacité ? Votre attitude face aux problèmes, ainsi que votre approche et vos méthodes pour les gérer.

Premièrement, l'attitude

Votre serveur renvoie occasionnellement des erreurs 501, peut-être pas à un rythme élevé (Zhihu a aussi connu cela de nombreuses fois). De nombreux programmeurs — oui, de nombreux — font semblant de ne pas le voir, s'en moquent ou mettent cela sur le compte de la malchance. C'est un problème d'attitude.

Plus tard, lorsque la charge devient élevée ou pour une autre raison, les erreurs 501 se produisent soudainement fréquemment. Au lieu d'enquêter sur la cause profonde, ils cherchent toutes sortes d'excuses : le fournisseur IDC est mauvais, la marque du serveur est mauvaise, le système d'exploitation est mauvais, la base de données est mauvaise, le CDN est mauvais, les conditions réseau sont mauvaises, le serveur web est mauvais, ou même disent directement au Boss : « Nous subissons une attaque DDoS ! » (J'ai rencontré ce cas — j'ai aidé son patron à trouver plusieurs experts en sécurité pour une consultation conjointe, et finalement nous avons découvert que ce n'était pas du tout du DDoS ; le programmeur était tout simplement trop mauvais.)

C'est une question d'attitude, et c'est choquant. Si vous pouvez être sensible aux problèmes et faire preuve de suffisamment de perspicacité face au moindre petit problème, vous avez une base pour une croissance rapide. La perspicacité face aux problèmes est très importante. De nombreux bugs non fatals de performance ou de logique de programme ne peuvent pas être détectés lorsque vous n'êtes pas assez perspicace, mais dès qu'un scénario particulier se produit, ils éclatent soudainement. Un peu plus de perspicacité de votre part réduit le risque de telles crises.

La deuxième attitude est l’attitude face à la résolution de problèmes. Certaines personnes sont pleines de confiance dans leurs solutions et les croient infaillibles, tandis que d’autres se ménagent une porte de sortie supplémentaire. Par exemple, lorsque vous vous demandez : dois-je renforcer la sécurité de mon serveur ? Vous le devez absolument, non ? Vous devez être aussi rigoureux et minutieux que possible. Mais devez-vous quand même chiffrer les mots de passe lorsque vous les enregistrez dans la base de données ? Et utiliser un sel aléatoire ? N’est-ce pas précisément pour prévenir le pire des cas, où il subsiste encore une vulnérabilité et où quelqu’un s’empare de la base de données ? Il en va de même pour les programmes. Certains processus démons côté serveur que j’ai écrits par le passé avaient des bugs et se terminaient inexplicablement. Bien sûr, ce bug doit être localisé et corrigé, mais en même temps, écrivez un cron pour vérifier l’état du démon et le restaurer automatiquement dès qu’il se termine. C’est un plan de secours. Même si vous ne voulez vraiment pas qu’il s’exécute, vous devez tout de même faire cette préparation. Avoir deux, voire trois plans pour un problème est aussi une qualité essentielle des excellents programmeurs et architectes.

La troisième attitude repose sur la communication et la compréhension. Lorsque l’équipe produit ou d’exploitation soulève une exigence déraisonnable, la rejeter en une phrase est certes satisfaisant et impressionnant. Mais avez-vous soigneusement communiqué et analysé sur quel besoin réel repose cette exigence, et si ce besoin réel peut être satisfait d’une manière plus raisonnable ? Un simple « ce n’est pas faisable, le coût de mise en œuvre est trop élevé » n’est pas la bonne attitude de communication. De plus, les meilleurs produits sont souvent ceux qui ont réalisé les besoins que les gens pensaient à l’origine impossibles à réaliser.

Avec une telle attitude, vous disposez d’une base pour progresser continuellement. Parlons maintenant des approches et des méthodes.

Si vous ne regardez que la vitesse à laquelle on tape du code, je pense que vous ne pouvez pas distinguer un excellent programmeur d'un programmeur médiocre. Peut-être que tout le monde peut écrire de nombreuses lignes de code en une journée, mais lorsqu'un problème survient, la différence d'efficacité de résolution de problème entre un programmeur médiocre et un excellent programmeur est comme le ciel et la terre. Ce qu'on appelle l'efficacité de résolution n'est rien d'autre que l'analyse, la localisation et la réflexion sur les bugs.

Le point le plus élémentaire : consultez les journaux d'exécution, consultez toutes sortes de journaux — journaux de serveur web, journaux de base de données, journaux de requêtes lentes, journaux binlog, journaux d'erreurs PHP, etc. Lorsque des problèmes surviennent en production, beaucoup de gens devinent au hasard sans même regarder les journaux. Il y en a aussi beaucoup qui ne lisent pas les journaux attentivement ou complètement. Si vous pouvez étudier sérieusement les journaux, vous avez déjà surpassé beaucoup de personnes.

Deuxièmement : les tests de modules et l'analyse par points d'arrêt. Une mauvaise habitude des programmeurs est de commencer par écrire un énorme morceau de code, puis de l'exécuter, sans savoir écrire et tester module par module, et sans savoir définir des points d'arrêt, réduire le périmètre et analyser étape par étape lorsqu'un problème survient après l'exécution. L'analyse par points d'arrêt est très simple : insérez plusieurs sorties intermédiaires dans le code pour observer quel maillon pose problème, ou observez la surcharge système de chaque maillon. C'est très important à la fois pour le débogage et l'optimisation des performances. Les experts pensent probablement que c'est un truc de niveau ABC, mais en ce qui concerne cette chose, la plupart des programmeurs que j'ai vus n'ont pas cette habitude.

Troisièmement : comprendre et rechercher les messages d'erreur. Les moteurs de recherche regorgent de toutes sortes de ressources techniques et de questions-réponses techniques. Les messages d'erreur et les invites que vous rencontrez peuvent généralement être trouvés en ligne. Bien sûr, après les avoir trouvés, vous devez réfléchir attentivement dans le contexte de votre scénario et les comprendre en profondeur, plutôt que de les traiter par simple recopie mécanique. Sinon, vous pourriez avoir de la chance cette fois-ci et tomber juste, mais la prochaine fois, quand la chance ne sera pas de votre côté, vous ne saurez pas ce qui se passe.

Quatrièmement : résumer et généraliser constamment. Pour un problème, une classe de problèmes et différents types de problèmes, sachez organiser et synthétiser, et réfléchissez constamment à vos propres problèmes. Même pour du code qui ne produit pas de bugs, lorsque vous y repensez après un certain temps, il y a de nombreux endroits où votre raisonnement était incorrect ou déraisonnable, et de nombreux points d'optimisation. Si vous pensez que votre code a toujours été génial et sans faille, alors vous faites certainement du surplace et ne progressez pas.

En ce qui concerne la synthèse, permettez-moi de partager un cas.

Auparavant, nous avions un système avec un volume de requêtes très important et une charge très élevée. Un assez bon responsable technique est venu s'en occuper. Il a listé plusieurs plans de mise à niveau, tous fiables, les a exécutés, et les résultats ont été très bons. Puis, lorsque nous avons assuré le suivi du rapport, il a parlé des mises à niveau qu'il avait effectuées et des résultats globaux. Ensuite, je l'ai critiqué.

Qu'ai-je critiqué ? Il a réalisé les améliorations ensemble, puis a observé les effets ensemble. Donc parmi ces plans, il n'avait aucune donnée sur l'effet réel de chaque plan spécifique ni sur la mesure dans laquelle il contribuait à l'amélioration. Il n'avait donc aucune notion de la valeur et de l'importance de chaque plan d'amélioration spécifique. Vous avez résolu le problème correctement, mais si vous n'avez pas soigneusement résumé et organisé, vos gains sont limités. Faire les améliorations ensemble ne peut pas être considéré comme faux, mais l'évaluation des effets doit être faite séparément, et ces données sont très précieuses. L'accumulation de connaissances ne provient pas nécessairement de ce que vous avez traité ; elle provient de ce que vous avez organisé.

C'est à peu près tout.

Enfin, laissez-moi le reformuler une fois de plus.

Qu'est-ce que la compétence ?

• Votre attitude face aux problèmes
• Votre approche et vos méthodes pour traiter les problèmes

C'est ça, la compétence

Source originale :Zhihu