1.毎年ソフトウェアエンジニアリングに関する2冊の本を読んでください。
他の人がすすめるソフトウェアエンジニアリングの本をゆっくりと注意深く読むたびに、上達します。注意深く読むこととは、メモを取ること、他の人と話すこと、書くことと描くこと、実践的な試み、そして戻ってもう一度読むことを意味します。
開発者になった最初の数年間でソフトウェア関連の本を読んでほしいです。しかし、私がこれを始めたのは、私のキャリアの5年目の頃だけです。「C＃In-Depth」、「Clean Code」、「Javascript：The Good Parts」などの本はすべて私のスキルを向上させるのに役立ちました。私は特定の本のタイトルをお勧めしません—それらのいくつかはとにかく時代遅れです。私の提案は、現在の知識よりも詳細な本を探すことです。これは、特定のテクノロジーやソフトウェアエンジニアリングの実践に関する本である可能性があります。
これらの本の読み方がわかりません。実は、ゆっくり見ていました。私はいつも座って、一度に1つまたは2つの章だけを読みます。読むときは、メモをとったり、要点を引き出したり、読んだ後は復習したり、よく話し合ったりします。個人ブログにも書評を書き始めました。
主に私が学んだことを振り返る。ここ数年、私はこれらの習慣を身につけました。これらの習慣は、テクニカルマネージャーとして急速に成長するのに役立ちました。これらの習慣は、エンジニアにとっても非常に有益です。おすすめの本のリストをお探しですか？これは私が読んだ、現在読んでいる本のリストです。
本がブログの投稿、ビデオ、スピーチよりも優れているのはなぜですか？実際、本は他の本を組み合わせるよりも優れていると思います。主題の内容が何であれ、本と比較して、他のフォーマットは表面的なものになります。本の知識はより深く、よく整理されています。このような投稿を書くのに数時間しかかからないのですが、私が書いたソフトウェアエンジニアの成長にこの本に1年近く費やしてきました。読書は知識をよりゆっくりと深く消化できると思います。
欲張りすぎないでください。6か月ごとに本を読むのは素晴らしいことです。良い本を選んで、それを読むのにもっと時間をかけてください。本を1〜2冊読んだ後は、「本の読み方：スマートリーディングのクラシックガイド」もお勧めします。
2.仕事の主なプログラミング言語をマスターし、最下層を学ぶ
私が最初に始めたとき、私は主にPHPを使用し、いくつかの基本的なJavaScriptも書きました。私は大学でCとC ++を学びましたが、それらは好きではありませんでした。私の最初のフルタイムの仕事はC＃でした。私は多くの言語を知っていますが、どれも非常に優れていません。
2年後、私はいくつかの問題を抱え始め、C＃コードのデバッグ時に上級開発者に助けを求めなければなりませんでした。そのうちの1人は、常にプログラムのデバッグを手伝ってくれるシニアエンジニアです。彼は言語を非常によく知っているようで、「C＃ディープラーニング」という本を勧めてくれました。それから私は見ました。スレッド化、ガベージコレクション、一般的な作業方法をすべて学びましたが、これらは低レベルの知識です。私は無数の時間を費やして、共分散（共分散）、逆分散（反分散）、およびその他の難しいトピックを理解しました。
私が行った最良の決定の1つは、自分の作品の主要言語を研究することです。私の最初の仕事では、この種の研究は意図せずに行われたため、上級エンジニアの指導に頼らざるを得ませんでしたが、この知識は、仕事や他の仕事の面接の際に有利になりました。私のキャリアの後半では、新しい言語とフレームワークを意図的に掘り下げました。私はC＃プログラマーとしてSkypeに参加しましたが、JavaScriptとWinJSに切り替える必要があります。したがって、私はJSを深く学び、WinJSをマスターして、Pluralsightのコースを開始できるようにしました。
知っている言語が多ければ多いほど、言語の長所と短所を理解することができます。iOSに移行したとき、私はすでにいくつかの言語に堪能でした。Swiftが登場したとき、私は単に言語のディスカッションに参加して参加し、Swiftの将来の計画にリフレクションの読み書き機能を追加することを提案しました。言語の特性を理解した後、私のチームがObjective-CからSwiftに移行するための最良の戦略を理解するのは簡単になります。そして、あなたが知っている言語が多ければ多いほど、新しい言語を習得することがより簡単になり、必要なときにもっと簡単に学ぶことができます。
3.他の人とペアプログラミング
最近ペアプログラミングは時代遅れになっていると思います。私たちが始めたとき、長期的なペアのエクストリームプログラミング、テスト駆動開発、および暴徒プログラミングはすべて人気がありました。誰かとペアを組んだ後、私のキャリアの中で最も大きなジャンプのいくつかを得ました。これらのジャンプは読書よりも重要です。
私はかつて、開発者との忘れられないペアプログラミングの経験がありました。彼は私を含むすべての人に対して厳格なコードレビューを行いました。ある日、コードレビューツールのコメントにうんざりしていて、返信せずに、これらのコメンターの隣に座って、コメントを私に説明するように依頼しました。私は最終的に多くを学びました、そしてまた彼らのコメントは不公平だと思ったと彼らに話しました。彼らはこれに気づき、これが起こったときはいつでもプログラミングをペアリングすることを提案しました。それから私はそれをやった。この開発者はパフォーマンスについてある程度知っており、プログラミングと組み合わせることで潜在的なパフォーマンスのボトルネックの内外について学び、それと引き換えに保守性について教えました。
別のエンジニアとのテスト駆動開発経験は、私のペアプログラミングのもう1つの好意的な記憶です。コードを書き、コードをテストします。それを2日間行ったところ、システムのトリッキーな部分に気づきました。その経験は本当に私の目を開きました。すべての境界値を検証する過程で、実装方法を逆に完全に変更しました。また、開発者との強い絆を確立し、数か月間続きました。
4.ユニットテストケースを作成し、継続的インテグレーションで実行する
上級エンジニアは、ユニットテストの重要性についてよく話します。しかし、単体テストは直観に反しすぎるように見えます。なぜ単純なように見えるテストを作成するためにより多くの時間を費やすのですか これは、ある時点での単体テストに関する私の意見です。
ユニットテストの価値を評価するには、「Aha！」の瞬間が必要です。作成したユニットテストで1日節約できるのは、「Aha！」の瞬間です。このステップに到達する前に、実地に行き、これらのテストを適切に記述し、継続的な統合で実行する必要があります。さらに、「あはは」の瞬間を得る前に、数か月間それを行う必要があるかもしれません。
私にはそのような瞬間が2つあります。最初の問題は、小さなオンラインカジノ用の（補助プロジェクトとして）バックエンドエンジンを構築しているときに発生しました。APIは実際のお金を管理しており、間違いを恐れていたため、すべてのコードを単体テストでカバーしました。このプロジェクトは予想よりも遅れて配信されました。これには、テストに時間がかかったためです。しかし、これは正しいです。契約の最後にプロジェクトをクライアントに譲渡しました。2年後、これらのテストによりチームが何度も救われたと言われました-テストの失敗がなければ、コードの脆弱性が本番環境に広がっていました。
私のもう1つの「あは」の瞬間は、Web上でSkypeを構築することです。web.skype.comでGoogleハングアウトの新しいライバルを作成しました。私たちのチームは、完全なユニットカバレッジと厳密な統合テストを備えた強力なチームです。プロジェクトに参加してから3か月後、エンジニアはプロジェクト全体の構造を再構築することを決定しました。これは非常に危険なリファクタリングであり、私たち全員がそれに反対票を投じました。
エンジニアは、既存のテストカバレッジに基づいて、このリファクタリングは簡単なものである必要があることを指摘しました。テストに合格する限り、リファクタリングは問題ありません。疑わしい。しかし、これがまさにテストケースの目的です。再建の1週間後、彼は大きな変化を推進しました...すべてが中断されたわけではなく、そのときも、その後も中断されませんでした。すべてのテストに合格しました。その瞬間、強力な一連のテストケースによって提供される安全性の保証と、リファクタリングを恐れないようにすることができることに気づきました。
5.リファクタリングの習慣とマスターリファクタリングツールを開発する
長年、私がチームで働いていたとき、コードベースにできる限り小さな変更を加える傾向がありました。私自身の個人的なプロジェクトでは、多くのリファクタリングを行ってきましたが、私が完全に制御できないコードベースでこのようなことをすることはありません。
次に、Skypeのエンジニアと出会い、小規模または大規模なリファクタリングを続けます。それらはすべて意味があり、コードは常に改善されます。そして、彼らは物事を台無しにすることはありません。彼らはそれをどのように行いましたか？
彼らとプログラミングを組み合わせたとき、彼らは彼らのIDEをよく知っていて、リファクタリング用のプラグインを追加していることに気付きました。抽出方法、数量の名前の変更、定数への抽出...必要なのは1秒だけです。
私はリファクタリングが怖いことに気づき、リファクタリングに役立つ実践とツールの両方を見逃しました。それで、週に1回リファクタリングの習慣を身に付け始めたとき、私は両方の面で改善しました。この習慣は私に多くのことを助けました-私が何年も前にこれを始めていたらよかったのに。
6.良いソフトウェアエンジニアリングの経験を学ぶ
私が最初にソフトウェアエンジニアとして始めたとき、私は上級エンジニアにだまされました。彼らは私が見なかった間違いを見ました、彼らは私が知らない答えを知っていました。彼らは私より頭が良いと思って、これをすべて受け入れました。
現在、私は多くの有名なソフトウェアエンジニアと緊密に連携し、他の何人かに対するメンターを務めていましたが、それはあからさまではありません。最高のソフトウェアエンジニアは、彼らが学んだ知識と実践的な経験知識を組み合わせて、学ぶことができます;経験、あなたは練習する必要があります。
さまざまなテクノロジースタック、さまざまな分野、挑戦的なプロジェクトで働く機会を探してください。「上級」レベルだと思うまでに7年から8年かかりました。Uberのような高成長企業に参加する人がいるのを見て、3〜4年かかりました。これの違いは何ですか？これらの人々は、やりがいのあるプロジェクトに取り組み、周りの他の人々に遅れずについていくよう努め、しばしばチームを途中で変更してやり直します。彼らは自主的に新しいプロジェクトに参加し、チームで新しいテクノロジーを試す最初の人です。私は最終的にそのような人になりましたが、それは後のことであり、最初の数年ではありませんでした。
7.学んだことを他の人に教える
特定のことを学ぶ最善の方法は、それらを他の人に教えることです。私はこれを偶然見つけました。2010年に、.NETおよびWindows Phoneユーザーグループでプレゼンテーションを開始しました。私のスピーチは効果的ではありませんでしたが、準備段階で多くのことを学びました。
さて、良いことを学びたいときは、公開討論に参加します。Uberに入社して1年後、2017年にUberがバックエンドの変更を大規模にどのように展開したかについてスピーチをすることを申し出ました。当時、私たちはそれがどのように行われているかを完全には理解していませんでした。以前は、主にモバイル開発とモバイルチームの管理に従事していました。講義を通して、詳細を学ぶしかない。私はこれを行うよう圧力をかけられています。約100人のローカル開発者が私の話を聞くためにサインアップしました。
他の多くの人も、このアプローチは効果的であると述べました。Shawn "Swyx" Wangは#LearnInPublicアプローチの傑出した代表者です。彼の成長ストーリーは私の経験よりもはるかに印象的です。彼のキャリアを変更した後、彼は4年間でNetlifyとAWSの上級エンジニアに就任し、彼の学習経験についての本を書きました。あなたは他人を教えることによってのみ利益を得ます。教えるだけでなく、他の人を助けたり刺激したりすることもできます。
そして、私が知っている経験豊富なモデル開発者はすべて、資格のある教師とメンターです。あなたが恩返しや指導を始めれば早いほど、自然にあなたはそのような開発者になるでしょう。