エンジニアを目指す人が知っておきたい学習の10のルール

本稿は、Mediumのブログ記事を了解を得て日本語翻訳し掲載した記事になります。

本記事は、WebエンジニアのTodd Rizley氏によって投稿されました。

現在、私はUpsider（アメリカのスタートアップ）との契約期限が迫っているため、求人媒体で次の仕事を探す予定です。

Upsiderはジュニアデベロッパーとして仕事を始めて腕を磨くには素晴らしい会社でした。Upsiderの創業者ほど温かく寛容で賢いメンターを私は出会ったことがありません。

彼は、私の能力を超えるようなプロジェクトも任せてくれて、定期的にペアリングをしてくれました。

私が取り組んだプロジェクトはフルスタックの領域をカバーするものでした（UpsiderはRuby on Railsを利用しています）。CSSやHTMLの修正、SPECファイルの作成といった基本的なことから始まり、RspecとCapybaraにテストカバレッジ (網羅率)を追加し、最終的に新しいメッセージング機能を開発しました。

私はデザイナー、プロダクト管理者、その他の会社のメンバーと共同作業をしながら、非常に多くを学びました。

この記事では、私が過去数か月の経験を通して学んだ10のルールをご紹介します。

1. 削除しないこと

何かにコードを実装するときは、古くて使われなくなったコードを削除しないように注意してください。たとえ、削除することが与える影響、アプリケーションに変更が加わるすべての箇所について100％確信できたとしても、慎重になるべきです。

私は誤って古いコードを削除してしまった経験が何度かありますが、スタイリングが崩れただけではなく、アプリケーションの機能性が損なわれました（例：ボタンが機能しなくなる）。

2. コードベースに精通すること

div要素の再配置などの作業が楽しみで仕方ないのは分かります。

しかし、先にコードベースに精通することを優先しましょう。将来的に時間の節約になるだけではなく、コードの重複の防止、関数名やクラス名の再利用の防止にも役立ちます。

3. 具体的に

なるべく具体的に命名してください、ただし冗長にならない範囲で。たとえば、あるボタン要素はbuttonというクラス名を与えるのが適切でしょうか？

いいえ、おそらく「sendCandidateEmailButton」というクラス名の方が適切です。具体的に命名すると、他のエンジニアにとって読みやすいコードになるだけではなく、あなた自身にとってもデバッグが迅速になるというメリットがあります。コードベースにおいてネーミングの慣習がある場合には、それに従いましょう。

おそらくそのコードベースは、前任のエンジニアが、明快に、簡潔に、扱いやすく構築したものだからです。一貫性が重要です。

4. 助けを求めないこと/助けを求めること

一見矛盾しているように思えるかもしれませんが、これはジュニアデベロッパーにとって重要な学びです。自分の能力を超えるプロジェクトに取り組むときは、パニックになるような場面も経験するでしょう。壁に当たっていると思うときには、前向きにその状況を楽しんでください。

こうした場面こそ、問題を解決しようとあなたの頭脳が回転し、本当に学びを得て向上できる機会です。次のステップを試してみてください。

• 一歩引いて、問題を再考する（私の場合、コーヒーを飲むか、外出して通りを数ブロックほど散歩して頭をクリアにしています。）
• 問題解決にGoogle検索、Stack Overflowを利用する（他の誰かがすでに同じような問題に直面したことがあるかもしれません！車輪の再発明をすべきではありません！）
• ドキュメントを参照する。

以上のステップを実行したら、あなたの問題についてチームのメンバーと自由に会話して構いませんが、どのようにdiv要素を中央配置したらいいか、などの質問でメンバーを困らせてはいけません。

5. テストコードを書くこと

これは明快なことです。ソフトウェア開発手法として、TTD（テスト駆動開発 ）やBDD（ビヘイビア駆動開発）を重視しない企業や組織はまず存在しないでしょう。テストは開発において不可欠なものであり、後付け的に考えるべきではありません。そうでなければ、現在開発している機能、将来的にはアプリ全体に問題を起こす原因になります。

あなたの会社で使用されているテストフレームワークについて学習し、アプリケーション内のテストコードの書き方を見て、新しい機能についてテストカバレッジを追加しましょう。（メソッドの中の条件構文をすべてテストするのも忘れずに！）

6. GitとGithubで可能なことをすべてを学ぶこと

もしくは、あなたの会社が使っているバージョン管理システムを学びましょう。作業するブランチ（branch）を間違えたり、誤ってプロダクションにプッシュ（push）するような事態は避けたいものです。

Gitについて深く理解しておくことは、エンジニアにとって非常に重要です。不安を感じる場合には学習リソースを活用しましょう。そうすれば、コミット（commit）やロールバック（roll back）などを簡単に扱えるようになるでしょう。

7. 現在取り組んでいる機能に集中すること

現在書いている小さなコードを見失うことは、特にそれがより大きな機能の一部を構成している場合、よく起こり得ることです。コードはDRY原則（Don’t Repeat Yourself）に従って読みやすく書くことを忘れずに。

もし圧倒されたように感じたら、今しようとしていることを理解するために、また現在書いているメソッドの有効範囲に何を含めるべきかを明らかにするために、疑似コードを書いてください。

私は新人のエンジニアになりたての頃、書いている小さなコードを見失い、その結果、最初に意図した動作を実現できないメソッドが完成することがよくありました。

たとえば、深いネスト構造のJSONによってメソッドをパース（解析して変換）する場合には、段階ごとに、コードを小さな部分に分けて考えるべきです。あまりにも多くの問題に一度に取り組もうとするべきではありません。（もし可能であれば、関心の分離も実践してください。）

すべての可能なシナリオを一度に考えようとすると、コードは混乱してしまいます。他のタイプの入力値は、後で処理することを考えましょう。

8. 動作させるためだけに悪いコードを書かないこと

私がコード学習をしていた頃、「早く、正しく、動作するように。」とよく聞かされました。これはUpsiderでの最初の数週間の間は、私の教義でした。

しかしこの教義を実践したことで、時には3階層以上のネスト構造のループ文を伴うような、最良ではないコードを書くようになっていました。

3段階以上のイテレーションを行わずに済むような良い方法は、他に多くありました。

私のメンターは、「この方法は、リファクタリングの段階においてより多くの問題を引き起こします。メソッドを完全に書き直さない限り、最適化はほぼ不可能です。」と指摘してくれました。

この方法にはメリットもありますが、「クリーンで効率的なコード」は現在の目標にするべきであり、最終的な目標とするべきではありません。そうすれば、リファクタリングと最適化を、よりシンプルに問題なく行うことができます。

9. Googleの使い方を学ぶこと

私は壁に当たったときに、「シニアデベロッパーに質問をする段階」が早すぎたことがよくありました。これはGoogle検索を上手く使いこなせていなかったことが原因です。

また、これは問題の定義が「異なる外部idを持つ3つのモデルを結合するために、Railsのテーブル結合を利用することは可能か？」のように具体的すぎたことも原因でした。

Stack Overflowで「Rails 複数の外部キー」と検索すれば解決できたはずです。一見当たり前のことに思えるかもしれませんが、問題をそのまま具体的に考える方がいいのか、それともより広い問題として考えることができるか、判断することが重要です。

10. 分かりやすいネーミング＞膨大なコメント

膨大な行数のコメントは必要ありません。私は多くのコード課題でこの誤りを犯しました。コメントは控えめに、そして説明が必要となる場合にのみ使いましょう。

冗長な説明をする代わりに、他のエンジニアにとっても意味が分かりやすい、具体的な名前を使いましょう。コードは可能な限り読みやすくするべきです。「言語や物語のように読めるコードが、最良なコードである。」と私はよく教えられました。これは、コードの「DRY原則」や「関心の分離」とも一致します。

将来あなたのコードを見るエンジニアのためだけではなく、あなたにとって物事を進めやすくするためにも、シンプル、簡潔、具体的なネーミングを行いましょう。

おわりに

これからエンジニアとして働きたい人は、実践で役立つ要素になるはずです。

ぜひ学習しながら実践してみてください。

また、TechAcademyでは初心者でも最短4週間でエンジニアになれるオンラインブートキャンプを開催しています。自分のアイデアを形にしたい、エンジニアを目指したい方はぜひご覧ください。

現役エンジニアがパーソナルメンターとして受講生に1人ずつつき、マンツーマンのメンタリングで学習をサポートし、最短4週間でオリジナルWebサービスを開発することが可能です。