体験を伝える―『ガジェット通信』の考え方

面白いものを探しにいこう 本物を体験し体感しよう 会いたい人に会いに行こう 見たことのないものを見に行こう そしてそれをやわらかくみんなに伝えよう [→ガジェ通についてもっと詳しく] [→ガジェット通信フロアについて]

エンジニアを目指す人が知っておきたい学習の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(ビヘイビア駆動開発)を重視しない企業や組織はまず存在しないでしょう。テストは開発において不可欠なものであり、後付け的に考えるべきではありません。そうでなければ、現在開発している機能、将来的にはアプリ全体に問題を起こす原因になります。

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

1 2次のページ
TechAcademyマガジンの記事一覧をみる
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。