姚冬の見解
学習能力、特に独学能力。有名なプログラミングの達人がフォーラムで「XX を学ぶにはどんな本を読めばいいのか」と質問しているのを、あなたはいつ見たことがあるだろうか。如何快速学习 XXX「XXXを学ぶにはどんなコードがおすすめ？」といった質問。彼らは何かを学びたいと思ったら、すぐに自分で関連資料を見つけられる。この業界は発展が速すぎて、技術の淘汰される速度も非常に速く、3年新しいことを学ばなければ時代遅れになるかもしれない。
动手能力みな本や資料を読んでいるが、他人がまだどんな本を読むか悩み、本の中の言葉の意味に悩んでいるうちに、ある人たちは数百行から数千行のコードをすでに実行できている。
忍耐と根気プログラマーにとって興味は確かに重要であり、自分の好きなコードを書くのはとても楽しいことだ。しかし、プログラム開発にはどうしても退屈でつまらない作業が大量にある。それを忍耐強く、歯を食いしばってやり遂げる必要がある。
表达能力大勢の人の前で、自分の考えを論理的に明確かつ流暢に話し、人に理解してもらえること。
では技術はどうか？技術は重要ではない。上記のような能力を身につけていれば、市場で必要とされる技術はすぐに習得できる。
最後に給料のことについて話そう。二つの言葉を覚えておいてほしい。
- 給料は、上司があなたの過去の貢献に対する報酬ではなく、あなたの将来の貢献に対する期待である。
- 現在の上司があなたの満足する給料を出すことは決してない。出すのは次の上司だ。
曹政の見解
姚冬さんの回答は非常に良かったので、私からは蛇足ながら一言付け加えたい。
私たちは皆、学習能力が重要だと知っている。では、その学習能力はどこから来るのか。本を読んだり授業を受けたりする以外に、どのように実務の中で学び、成長していくのか。
以前、微博（ウェイボー）で大まかな概念を述べた。能力とは何か？ 問題に対する態度、および問題を処理する考え方と方法である。
先说态度
サーバーが時々 501 エラーを返す。割合は高くないかもしれない（知乎でも何度も発生している）。多くのプログラマーが、そう、実に多くのプログラマーが、見えないふりをするか、気にしないか、あるいは運の問題だと決めつける。これこそが態度の問題だ。
その後、負荷が高くなったか、他の何らかの原因で、突然 501 エラーが頻発するようになる。原因を深く追究せず、あらゆる言い訳を探す。「IDC プロバイダーが悪い、サーバーのブランドが悪い、OS が悪い、データベースが悪い、CDN が悪い、ネットワーク状況が悪い、Web サーバーが悪い」、挙げ句の果てには上司に直接「DDoS 攻撃を受けました！」と言うことさえある。（実際に遭遇したことがある。彼の上司のために複数のセキュリティ専門家を呼んで診断してもらったが、最後には DDoS ではなく、プログラマーが酷すぎるだけだと判明した。）
これが態度だ。実に驚くべきことだ。もし問題に対する敏感性を持ち、どんな小さく軽微な問題にも十分な鋭敏さをもって向き合えるなら、急速に成長する基盤ができる。問題に対する鋭敏さは非常に重要だ。多くの性能上またはプログラムロジック上の致命的でないバグは、鋭敏さが足りないときには発見できない。しかし、特殊なシナリオに入ると突如として爆発する。あなたがもう少しだけ鋭敏さを持てば、そのような危機のリスクを減らすことができる。
二つ目の態度は、問題を解決する態度だ。自分の解決策に自信満々で「万全だ」と思う人もいれば、別の逃げ道を一つ残しておく人もいる。例えば「サーバーにセキュリティ強化をするべきか」と言えば、もちろんすべきだ。できる限り厳密で周到にやるべきだ。しかし、データベースにパスワードを保存するときも暗号化すべきではないか？しかもソルトはランダムにするべきだ。それは、万一依然として脆弱性が残っていてデータベースを奪われたらどうするのか、という備えではないか。プログラムも同じだ。以前書いたサーバー側のデーモンプロセスにはバグがあり、原因不明で終了することがあった。このバグを特定して修正するのはもちろんのこと、同時に、cron でこのデーモンプロセスの状態をチェックし、終了したら自動復旧させる仕組みを書く。これが第二の備えだ。たとえ実行されることをどれほど望まなくても、この備えはやっておくべきだ。問題に対して二手、いや三手の備えをすることも、優秀なプログラマーやアーキテクトの重要な資質である。
三つ目の態度は、コミュニケーションと理解に基づく態度だ。プロダクト担当者や運営担当者が非現実的な要望を出してきたとき、一言で跳ね返すのは確かに痛快で、威勢がいいものだ。しかし、その要望がどのような実際のニーズに基づいているのか、そのニーズにはもっと合理的な実現方法がないのか、入念にコミュニケーションして分析したことがあるだろうか。「これは実現できない、コストが高すぎる」という一言は、正しいコミュニケーション態度ではない。しかも、最も優秀な製品は、往々にして人々が実現不可能だと思っていた要望を実現したものである。
このような態度があって初めて、持続的な進歩の基盤ができる。次に、考え方と方法を述べよう。
優秀なプログラマーと凡庸なプログラマーは、コードを書く速度だけを見れば、見分けがつかないと思う。誰でも一日にたくさんの行のコードを書けるかもしれない。しかし、問題に直面したとき、凡庸なプログラマーの解決効率は、優秀なプログラマーと比べると、天と地ほどの差がある。いわゆる解決効率とは、結局のところ、バグの分析、特定、そして思考にほかならない。
最も基本的なこと、それは実行ログを見ることだ。あらゆるログを見る。Web サーバーのログ、データベースのログ、スロークエリログ、binlog ログ、PHP のエラーログ、などなど。本番環境で問題が発生したときに、ログも見ずに当て推量する人が大勢いる。ログを注意深く、完全に見ない人も大勢いる。あなたが真剣にログを研究するだけで、すでに多くの人を超えている。
二つ目は、モジュールテストとブレークポイント分析だ。プログラマーの悪い習慣の一つに、いきなり大きなコードの塊を書いてから実行するというものがある。モジュールごとに書いてテストするということを知らず、実行中に問題が発生してもブレークポイントを設定して範囲を絞り込み、段階のに分析することを知らない。ブレークポイント分析は非常に簡単だ。コード全体にいくつか中間出力を挿入して、どの工程で問題が発生したかを観察するか、各工程のシステムオーバーヘッドを観察する。デバッグと性能最適化の両方にとって非常に重要だ。達人たちはこれを ABC のようなものだと思うかもしれないが、この程度のことであっても、私が見てきたプログラマーの大半はこの習慣を持っていない。
第三条、エラーメッセージの理解と検索。検索エンジンには様々な豊富な技術資料や技術Q&Aがあり、あなたが遭遇したエラーメッセージやエラーヒントは、通常ネットで検索できる。もちろん、検索した後は自分の状況に合わせて真剣に考え、徹底的に理解すべきであり、表面的に真似して処理してはいけない。そうしないと、今回は運よく当たるかもしれないが、次は運が悪いとまた原因がわからないことになる。
四つ目は、絶えず総括し整理することだ。一つの問題、一類の問題、そして異なるタイプの問題について、整理とまとめを上手に行い、絶えず自分の問題を反省する。バグが出ないコードであっても、しばらく時間が経ってから見返すと、考えが正しくなく不合理だった箇所や、多くの最適化ポイントが見つかる。もし自分のコードはいつもすごくて、欠陥などないと思っているなら、あなたは間違いなくその場で足踏みしていて、何の進展もない。
帰納と総括について、一つの事例を挙げる。
以前、私たちのシステムはリクエスト量が非常に大きく、負荷が非常に高かった。有能なテクニカルマネージャーが対応した。彼はいくつかのアップグレード計画を挙げた。どれも信頼できるもので、実行したところ効果は非常に良かった。そしてフォローアップ報告の際に彼が説明した。「いくつかアップグレードを実施した。全体的な効果はこのようになっている」と。すると私は彼を批判した。
私が何を批判したのか？ 彼は一緒にアップグレードを行い、一緒に効果を観測した。それらの案の中で、具体的に各案の実際の効果はどうか、向上への助けがどれほどか、彼は何のデータも持っていなかった。だから、各アップグレード案の価値と重要性について、彼は何の概念も持っていなかった。あなたは問題を正しく解決したが、真剣に整理・総括しなければ、得られるものは限られている。一緒にアップグレードすることは間違いとは言えないが、効果評価は別途行う必要があり、そのデータは非常に価値がある。知識の蓄積は、処理したからといって必ず蓄積されるわけではなく、整理したものだけが蓄積されるのである。
大体これだけ
最後にもう一度述べます
能力とは何か？
- 問題に直面した際の態度
- 問題を処理する考え方と方法。
これが能力だ
原文出处：知乎