こんにちは！スマートキャンプで20卒の内定者インターンをしている、ジョニーこと高砂です。
本記事は「スマートキャンプ Advent Calendar 2019 - Qiita」の11日目の記事です。
私は主にBiscuetという営業効率化ツールの開発に携わっています。
プログラミング初心者としてインターンを始め、週2のペースで10ヶ月程続けてきました。
その中でメンターから学んだことを思い返して、本記事ではその中でも特に印象に残った10個を会話形式で紹介していきます！
開発の進め方について
一行ずつ全て理解しながらコードを読もう
Biscuet全体のコードの繋がり方を上手く追えず、メンターに相談した時の話です。
私「このコードがデータをどう処理しているのか分かりません…」
メンター「なるほど、この一文はどこを参照してる？」
私「えっと、多分DBのこのテーブルです」
メンター「本当に？何でそう考えたの？」
私「え、関数名的にそこかな、と…」
私「あ、でもいま下のコードをよく読んだら別のテーブルでした！」
メンター「うん、高砂はコードの流れをなんとなくで追ってしまっているね」
私「確かに…一文ずつ丁寧に読むべきですね！」
調べる時は3つのソースから
新しい関数を作ろうとしたものの上手く動かず、メンターに相談した時の話です。
私「ソート機能を実装したくて、調べて出てきた記事を基に書いたんですが…」
メンター「この書き方で合ってるの？」
私「うーん、記事の通りに書けてると思います」
メンター「公式ドキュメントも読んでみようか」
私「はい！…あれ、記法が微妙に異なりますね」
メンター「おそらく環境によって変わるんだろうね」
私「本当だ、こっちなら動きました！」
メンター「記事の内容が必ずしも正しいとは限らないよ」
メンター「基本は公式ドキュメント、本、記事の最低3ソースで確認するくらいが良いね」
説明する時は専門用語を使って
実装内容をメンターに説明する時の話です。
私「この部分は画面の上部に表示させたくて、このような実装にしました」
メンター「うーん、画面の上部ってどこを指してる？」
私「あ、パンくずリストの事です」
メンター「だったらそういう風に専門用語で言ったほうがすぐ伝わるよ」
私「そうか、分かりやすくしようと必要以上に平易な言葉で話していました…」
メンター「専門外の人に対してはその意識は大事」
メンター「でも僕らの会話では的確に専門用語を使おう！」
開発期間の見積もりが甘い
メンターにタスクの進捗報告をしている時の話です。
私「今日までに完了する予定でしたが、あと3日かかりそうです…」
メンター「うーん、何で見積もりより遅れたの？」
私「API作成が想定より大変だったのと、風邪で数日休んだからですね…」
メンター「それは全体的に見積もりが甘いかな…」
メンター「前者についてはタスクを細かく分解して工数を予測するのが大事」
メンター「後者はイレギュラーケースも考慮して長めに期間を決めると良いね」
私「なるほど…間に合わないよりは早く完了した方が良いですもんね！」
プログラミングについて
範囲を区切ってコーディングしよう
新しいプログラムを作ろうとしたものの、フロント〜バック〜データベースの流れを追いきれなくなってメンターに相談した時の話です。
私「現時点でどこの機能まで出来たか分からなくなってしまいました…」
メンター「それは一度に作ろうとしている範囲が大きすぎるからだね」
メンター「いきなりシーケンシャルにコーディングするのは難しい」
メンター「まずはフロントだけ、のように区切って開発すると良いよ」
私「確かにそれなら混乱せずに作りきれそうですね！」
関数名・変数名は内容と一致するように
個人開発した社内向けツールをメンターにリファクタリングして貰った時の話です。
メンター「ここのchangeUser(user)って関数は名前はユーザーを変更してそうだけど、中身はユーザーの投稿内容の変更だよね」
私「はい、ユーザーに関する変更だからそれで良いかと思ってました！」
メンター「関数名や変数名は、原則それだけで役割が分かるようにしたい」
メンター「今回だとchangeContentOnPost(user)のように具体的な方が良いよ」
私「確かにそのほうがわかりやすいですね！」
関数一つの役割は一つに
上記と同様のリファクタリングの時の話です。
メンター「このdisplayFilteredPostsはユーザーの投稿のうちフィルターに合致するものを表示する関数かな？」
私「そうです！」
メンター「一つの関数に対して役割が多いな…」
メンター「例えばこれはdisplayPostsとfilterPostsに分けた方が良いね」
メンター「一つの関数は一つの役割に限定した方が、読みやすいし再利用性も高まるよ」
私「なるほど！そしたら別の場面でも使えそうです」
学習方法について
まずは実務をやって課題を見つけたら本を読む
何の本で勉強した方が良いかについてメンターに相談した時の話です。
私「どの本を読もうか迷ってるんですが、何かオススメはありますか？」
メンター「そうだなぁ、高砂は何で勉強しようと思ってるの？」
私「えっ、それはもちろん開発のスピードを上げたいからです」
メンター「だったらそれを阻害する部分の勉強をすれば良いんじゃない？」
メンター「慣れたら課題になりそうな分野を先読みして学習する事も出来る」
メンター「でも今は素直にいつも分からなくなる分野の本を読めばいいよ」
私「なるほど！ではRubyの文法の本から読んでみます」
「分かった」は気軽に言わない
新しいライブラリを導入するタスクをメンターに任された時の話です。
私「事前に勉強したのでこのライブラリの事は大体分かりました！」
メンター「お、じゃあとりあえず一つ画面を作ってみて」
私「はい！」
私「…あれ、上手く動かない」
メンター「うーん、サンプルも作れないと『分かった』とは言えないよね」
メンター「あと完全に理解するのは不可能だから、どこまでなにが理解できたかを伝えた方が良いよ」
私「了解です…もっと丁寧に勉強してきます！」
話せるまで理解しよう
上記を踏まえて、ライブラリの調査の最中にメンターに疑問点を話しました。
私「ライブラリの調査はどの位までやればいいんですか？」
メンター「そうだなぁ…例えばこの部分はどうやって表示してるの？」
私「ここはさっき調べました！」
私「えっと…あれ、どこのコードが影響してるのか分かってなかったです」
メンター「だとするともう少し調査が必要だね！」
メンター「何度か顧みて他の人に説明できるかどうかを目安にすると良いよ」
まとめ
- 一行ずつ全て理解しながらコードを読もう
- 調べる時は3つのソースから
- 説明する時は専門用語を使って
- 開発期間の見積もりが甘い
- 範囲を区切ってコーディングしよう
- 関数名・変数名は内容と一致するように
- 関数一つの役割は一つに
- まずは実務をやって課題を見つけたら本を読む
- 「分かった」は気軽に言えない
- 話せるまで理解しよう
以上10個が、本記事で紹介した愛のムチです。
私は情報学部出身ではなく、しばらく独学で開発を行っていました。
その為「どう書くと他の人に分かりやすいか」や「どうすれば効率的に開発できるか」を考えた経験が無く、チーム開発に参加した当初はそのような考え方を知るところから始めなければなりませんでした…。
そんな中、インターンを通じて指摘されたたくさんの内容（全てノートにメモっています）を出来る限り意識し開発を行うことで、今はだいぶ一人前のエンジニアに近付けたかなと自信を持てています！
明日は弊社デザイナー高松の記事です！お楽しみに！
qiita.com
