リブセンスの IESHIL で内定者インターンをして一ヶ月が経ちました。
そのなかで「学」んだことを書いていきます。
対象読者
- これから新卒やインターンでエンジニアになる（なりたての）方
- 複数人での開発経験が浅い方
- 新規の開発現場に行く予定の方
少しでもみなさんのお力になれれば 
学んだこと
ここから学んだことをつらつらと書いていきますが、至極当たり前なことを書いています。
ただ、その当たり前の品質を保ち続けるためには、日々意識的に行動していかないと自分の血肉にはならないと思ったので、自戒の念を込めて言語化しました。
変数やメソッドなどの命名には最大限の配慮を心がけましょう
僕が初プルリクエストで指摘された箇所はほとんど命名に関してでした。
下記のように愛のあるコメントをいただきました。普段は心優しいボスです 
現開発メンバーや、のちに開発メンバーとして入ってくる人たち、そして数ヶ月後の自分自身のためにも命名はしっかりと考えるべきです。
自分以外のメンバーのために、わかりやすい命名をするのは当たり前かもしれません。
ただ、自分自身も「あれ？なんでこんなコード書いたっけ？」ってよくなりますよね 
数ヶ月後の自分も他人と認識しておきましょう。
この辺の知識を補ってくれるオススメの書籍はリーダブルコードです。
是非読んでみてください 
1行1行のコードに思いを込めて書きましょう
ちょっと表現がポエムっぽいですが...
要するに、1行1行のコードに対してなぜそう書いたのか、根拠を持って説明できる状態にしておくことが大事です。
レビューをしていただくときに、「こういう書き方の方がいいんじゃない？」というような議論がよく起きます。そういったときに、自分自身が根拠なくコードを書いていたらそういった議論が発展しなくなります。
良いコードを書くためにも、1行1行のコードには思いを込めましょう。
コードを書く前に、まず事業やオペレーション周りを把握しましょう
メリットは大きくわけて２点あると思っています。
⓵ コードがより読みやすくなる
自分が事業部に配属されたころ、事業のことやオペレーションのことをほとんど把握していませんでした。
その状態で、コードを見たら、正直わからないことだらけでした。
「やべぇ、なんにもわからねぇ。。。」
初めは自分に技術力がないだけだと思い込んでいました。
ただ、よくよく考えたらそもそも事業のことを何にも理解していないことに気がつきました。
それから、ミーティングなどで事業に関するわからない単語などがでてきたら、1つ1つ質問して潰していくことを意識しました。
事業のことがわかってくると、コードも読みやすくなってきます。
コードが読めないのか、そもそも事業のことを理解していないのかは、分けて考えた方がいいです。
もし、事業のことを理解していないのであれば、すぐに周りに聞きましょう。
優しく先輩たちが教えてくれるはずです 
コードが読めないのであれば、しっかり勉強しましょう （自分も含め）
⓶ 最適解を提案（考案）できるようになる
事業やオペレーションを把握するとことで、課題に対する最適解を提案（考案）できるようにもなります。
もし把握していない場合、与えられた開発タスクを日々こなすだけになってしまいます。
事業やオペレーションを把握することで、開発タスクに対しても「これが本当の最適解なのか？もっといい方法はないのか？」と改めて考えることもできますし、課題点を見つけて自分でタスクを作ることもできます。
早くチーム内で自走していけるためにも、事業やオペレーションは早めに把握しましょう。
技術書は読みましょう
当たり前ですが、網羅性の高い書籍を読んでおくことは必須だなと思いました。
技術書を読んでいると、利用シーンがわからない部分とかと頻繁にでてきますが、頭の片隅に入れておくだけでも武器になると思います。
技術書を読んでいるときにわからなかった利用シーンが、
実際の開発で「もしかしたら、あれが使えるかもしれない
」ってことが何度かありました。
利用シーンに実際に出会うと、かなり理解も増します。
なので、網羅性の高い技術書を読んでおくことはオススメします。
さいごに
たった１ヶ月で多くのことを学びましたが、今回は厳選して４つのことだけを書きました。
まだまだ学ぶことはたくさんあると思うので、随時発信して行く予定です。
来年はもっと技術よりな記事を書こうと思うので、お楽しみに！
それでは、良いお年を 
（まだ早いか...）