More than 5 years have passed since last update.

開発インターンで気をつける5つのポイント

Last updated at 2017-05-19Posted at 2016-03-07

概要

仕事をしたことがある人なら心得ているけど、初めてインターンに参加したり、メンターもいてがっつりコードを書くインターンをしたことがない場合は、分からないことも多いはず。
インターンに行く前に事前に行っておくといいことや、開発する時に気をつけることをまとめました。
半分以上は仕事の進め方を書いています。設計を大きく間違えたり、メンターの人が話をしていることを勘違いすると、どんなにコードを書いても成果がでません。最初の1週間は、コミュニケーションの方法や、確認の方法などに慣れてください。

参加する前

インターンに行く会社のブログを見る(Wantedlyなら)
- 例)
- Wantedlyの開発フロー http://qiita.com/awakia/items/c571e93e96a1ec28044f
- (github) 初めてコードレビューされる人のためのpull requestとcommitの作り方 http://qiita.com/reikubonaga/items/e3b3b19c14d4ef4efb95
- (ruby) rails開発に加わる前に学んで欲しいこと http://qiita.com/reikubonaga/items/60b4f6ee0a86ed06e83b
- (ruby) Rubyはじめての人がRails開発に参加するときに最初に知っておくべきこと http://qiita.com/awakia/items/42525adb473c7cc6b811
- (ruby) Ruby/Railsチェックポイント http://qiita.com/awakia/items/ea81e2da242e8e28dec6
- (ruby) 新人エンジニアに読んで欲しい英語ドキュメントまとめ (Ruby/Rails編) http://engineer.wantedly.com/2013/12/26/getting-started.html
- (iOS) iOS開発に加わって最初に学んで欲しいこと http://qiita.com/reikubonaga/items/3ebe6fe29ce8d7c84291
- (setting) Wantedlyで開発するときにとりあえず設定してもらう事一覧 http://qiita.com/awakia/items/4c599ebe29a8b2b6ca27
初日は遅刻しないように、早めに家を出る
- インターン受入れの準備など行ってくれている

開発する前に聞くといいこと

成果を求められているか、自分の技術の確認をしているか
- 成果を求められている場合はメンターにも聞きつつ仕上げる必要がある
どのくらいの頻度でメンターに相談すればいいか、相談しやすい方法は？
- 直接話しかけるか
- チャットで聞くか
- githubのissueにコメントを書くか

なにを作るのかをしっかり理解し、記録する

求めているのは、最短で、必要なものを、読みやすく(mergeできる)実装されたコード

シンプルに実装する
- 基本的には、今後使える汎用的なクラスを作るのでなく、要件をシンプルに作るほうがいいです
- 最初の開発に時間がかかるということは、技術のコミュニケーションがうまくとれていないことにもつながるからです
開発する上で必要なことをgithubのissueにする
- なにを作るかを間違えていると開発では最も悪い。仕様やゴールの確認は行うためにも最初に話をしたことをissueにしてください
- 参考: Wantedlyの開発フロー http://qiita.com/awakia/items/c571e93e96a1ec28044f#1-issue%E3%82%92%E4%BD%9C%E3%82%8B
社員の人に質問したり、確認したことは、githubのcommentに追記する
- 聞いたことを勘違いしている可能性もあるので、文字に落とす

メンターには、小まめに相談する

モデルの変更がある時は、事前に設計や命名をメンターの人に確認する
- 実装し始めてから、モデルの設計が異なると時間を大きく消費してしまう
- 命名は間違えるとあとで変更に時間がかかるので、決めたらコードを書く前に確認する
既存のコードの読み方
- 基本的にはプロジェクトに関係のあるクラスを理解することがゴール。
- あまり細かく見ていると、時間が経つけど、やりたいことができないことに陥りやすい
- 最初は既存に書いているコードと似たロジックや書き方でかけるといいです
新しい役割のあるクラスを作りたい時は、事前に設計と命名をメンターの人に確認する
- 新規で入った人は、既存のコードを完全に追いかけるのは不可能
- 似たようなコードがないということは、今まで必要ないと判断しているかもしれない
- 最初は、メンターと設計に関して議論できるチャンスがあれば、議論するくらいのほうが、スムーズに開発が進むはず
5分くらい考えて分からないときは、直接社員の人に聞くくらいがいい
- 1時間をなにを作るかに考えない
- 1時間なにも進んでないときは要注意
- 1-2時間かかっているとしたら効率が悪いし、5分コード読めば分かることは自分で読めるほうがいい
コードが増えたなと思った時
- 増えすぎる前に一度メンターに相談しましょう

コードをgithubにアップするとき

タイミングは小まめに

まだ完成していなくてもpushは数時間置きにはしておくほうがいいです。
もしメンターが見れば早めにフィードバックできるし、pushするだけならメンターの仕事も阻害しないからです
書いている途中のときは、[WIP]とタイトルにつけてください。詳しくはこちら http://qiita.com/awakia/items/c571e93e96a1ec28044f

pushしたあとで自分のコードを見る

必要ないファイルがpushされたり、indentやspaceなど基本的なことをみてください
一度書いたコードを見るとミスが発見できることも多いです。他の人のコードをレビューするつもりでいちゃもんをつける
小さいミスがあると小さいミスの指摘で終わってしまい、多くの場合レビューを直した後に再度レビューの指摘をされます。一度のレビューでマージするためにも、小さいミスをなくすことを心がけて、pull requestをレビュアーに渡してください。
pushした後に、「間違いをひとつ見つけよう」って思ってコードを見るといいと思います。

その他

* メンターが複数いる場合。直接見てくれている人以外の人にアドバイスをもらい方針が変わる場合。基本的には、アドバイスもらったひとにもメンションして方針が変わったことを伝えるほうがいいです。