エンジニアを目指す人が知っておきたい学習の10のルール
エンジニアとして働くことを目指す人が知っておきたい学習のルールを紹介しています。アメリカのスタートアップでWebエンジニアとして働いた人から実際に働く中で感じた大事な要素をまとめています。ぜひ覚えておきたい内容でしょう。
テックアカデミーマガジンは受講者数No.1のプログラミングスクール「テックアカデミー」が運営。初心者向けにプロが解説した記事を公開中。現役エンジニアの方はこちらをご覧ください。 ※ アンケートモニター提供元：GMOリサーチ株式会社 調査期間：2021年8月12日～8月16日 調査対象：2020年8月以降にプログラミングスクールを受講した18～80歳の男女1,000名 調査手法：インターネット調査
本稿は、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要素を中央配置したらいいか、などの質問でメンバーを困らせてはいけません。
コスパとタイパ、両方結果的に良くなる良くなる学び方とは？
「スクールは高いし時間も縛られて効率が悪い」と考える方は多いと思います。
もちろん、時間も費用もかかることは間違いありません。
ただ
結果的に無駄な学びにお金も時間もかける方がリスクが高いという考えもあります。
コスパ・タイパ最適化の参考として、
テックアカデミー卒業生がスクールを選んだ理由
をご紹介します。
- ・困ったときに、質問や相談できる相手がいるため挫折しなかった
- ・プロとして必要なスキルのみを深く学べたので無駄がなかった
- ・副業案件の提供と納品までのサポートがあったので目的を達成できた
安価・短期間で広く浅く学んでも意味がありません。
本当に自分の目的が達成できるか、それが重要です。
自分にどのスキルや学び方が合っているか、どんな学習方法かなど、お気軽に
無料相談
に参加してみませんか？
カウンセラー・現役のプロへ、何でも気軽に無料相談可能。
30分か60分お好きな時間が選べて、かつ3回まで
すべて無料で
ご利用できます。
無理な勧誘は一切ない
ので、お気軽にご参加ください。
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では初心者でもエンジニアになれるオンラインブートキャンプを開催しています。自分のアイデアを形にしたい、エンジニアを目指したい方はぜひご覧ください。
現役エンジニアがパーソナルメンターとして受講生に1人ずつつき、マンツーマンのメンタリングで学習をサポートし、最短4週間でオリジナルWebサービスを開発することが可能です。
プログラミングを独学で学習していて、このように感じた経験はないでしょうか？
- ・調べてもほしい情報が見つからない
- ・独学のスキルが実際の業務で通用するのか不安
- ・目標への学習プランがわからず、迷子になりそう
テックアカデミーでは、このような
学習に不安を抱えている方へ、マンツーマンで相談できる機会を無料で提供
しています。
30分間、オンラインでどんなことでも質問し放題です。
「受けてよかった」と感じていただけるよう
カウンセラーやエンジニア・デザイナー
があなたの相談に真摯に向き合います。
「自分に合っているか診断してほしい」
「漠然としているが話を聞いてみたい」
こんなささいな悩みでも大丈夫です。
無理な勧誘は一切ありません
ので、まずはお気軽にご参加ください。
※体験用のカリキュラムも無料で配布いたします。（1週間限定）
