インターンが6ヶ月でソースコードReviewの指摘が200回超えた話

# はじめに
今回、先輩インターンや社員の方にソースコードをレビューして頂き、不備を指摘して頂いた回数が200回の節目にたったので、どんなことが今までにあったのか備忘録として残しておきたいと思います。
技術について投稿すべき、Qiitaに投稿する内容としてはふさわしくないかもしれませんが、ここに書き残したいと思います。

**自分が今、何を考えているのかを未来の自分に伝えるため、またインターンをしている仲間に対してなぜ、こんなことをしてきたのかを共有する意味を込めて書きたいと思います。**

## インターンをする環境
私は現在、[ユアマイスター株式会社](http://corp.yourmystar.jp/)でインターンシップ生として働いています。
現在はインターンを初めて1年になりますが、まだまだ駆け出しの見習いエンジニアで日々勉強することや新しい知識にワクワクしています。

[ユアマイスター株式会社](http://corp.yourmystar.jp/)では[「あなたのマイスター」](https://yourmystar.jp/)というユーザーとハウスクリーニングプロや靴やカバン修理を行う職人さんを繋ぐサイト、大切なものを大切にしたい人のためのメディアサイト[「RELIVERS」](https://yourmystar.jp/relivers/)を運営しており、私はその2つのサイトに携わっています。
![あなたのマイスター.jpg](https://qiita-image-store.s3.amazonaws.com/0/221678/48d9bd8b-147c-db7c-c83c-66ac799a2961.jpeg)
あなたのマイスタートップページ

## 使用する言語等
どんなサイト構成になっているかは今回省略して、今回は開発に使用されている言語等を紹介させて頂きます。
フレームワーク
- CakePHP3

言語
- PHP
- HTML5
- Javascript
- CSS
- MySQL

以上の物を使用しています。(その他色々あるかもしれませんが、インターンである私が触れているのはこの部分です。)
先述した、あなたのマイスターはECサイトとなっているためただWEBアプリケーションを触れるだけでなく、お金のやり取りがあるため、普通のWEBアプリケーションを作るインターンでは味わえないような世界を垣間見ることができます。

## ソースコードレビューについて
実際に運用されているサービスであるため、**コードにデグレやバグを生むような不審な点がないか入念なチェック**をしています。経験不足からチェックが甘いのが現状です。そのため、先輩インターンや社員さんにコードをレビューしてもらい問題がなければリリースできるというフローになっています。
インターンを初めてから最初は、プログラムをほとんど書いたことがなく、特にPHPについてですが、関数とは何か、インスタンスとは、$thisが何かという初歩的なことも知らず日々よくわからないことに対処するという日々が過ぎて行きました。
(**超がつくほどの初心者を受け入れて頂き、今は感謝してもしきれないほどだと思っています。ありがとうございます。**)
現在は、インターンを初めてから約1年が経ちましたが、まだまだ学ぶべきことが多々あります。来年4月からは**社会人エンジニア**になり社会の荒波に揉まれる予定です。

## レビュー回数を数えようと思ったきっかけ
ある時、ふと**「自分のコードをレビューしてもらう時間分、他のインターンや社員さんの時間を奪ってしまうのではないか」**と考えるようになりました。
コードレビューは必須だが、つまらないミスや仕様の確認不足で本来不要だったソースコードレビューが発生しているのではと考えるようになりました。

## そこで行なったこと
ソースコードレビューを経て、不備を指摘してもらった回数を数え、自身に戒めをかけようと思いました。
そこで行なったこととしては
**「不備があった回数1回ごとに100円貯金する」**
ということを行いました。シンプルだけども、自分にとってはダメージが大きいことでした笑

社内では`review貯金`という名前のもと貯金しています。
計算していただくとわかると思いますが、現在では2万円以上溜まっていて、日々貯金額は増えています・・・。

## なぜここまで指摘回数が多かったのか
物事には必ず原因があり、ここまでレビュー回数が積み上がったのには大きく原因があります。

1. 要件確認不足
2. コードの冗長な記述
3. 命名
4. テスト不足

分析した結果、上記の4項目が主な原因ではないかと判明しました。

### 1. 要件確認不足
実装を行なって欲しいと任されたものに関して、予定していた機能に足りないものを実装してしまうということが多々ありました。ここで一番問題だったのは、**コミュニケーション不足**だったと思います。要件や仕様を理解する能力不足があったのも確かですが、**わからないことを聞く**という当たり前のことができていませんでした。**聞くは一時の恥、聞かぬは一生の恥**ということわざがあるように、質問をすることは良いことだと思います。

参考
[質問は恥ではないし役に立つ](https://qiita.com/seki_uk/items/4001423b3cd3db0dada7)
このQiitaの記事を社員さんから教えていただき、質問する際の話し方を意識的に変えてきました。

まだ、社会人から見ると「仕事のレベルに達していないよ」という声があるかもしれませんが、仕事においては**コミュニケーション**が大事だと実感しました。

### 2. コードの冗長な記述
```php
if ($showText) {
 echo 'Hello world!';
}

// 何かの処理

if ($showText) {
 echo 'Bonjour le monde!';
}

```

色々とやってしまった事例はありますが、ここでは簡単な例として上記のコードを記述します。`$showText`が`true`であれば2つif文を書く必要がなく、1つにまとめられるはずです。

```php
if ($showText) {
 echo 'Hello world!';
 echo 'Bonjour le monde!';
}

// 何かの処理

```

ここであげたのはとても初歩的なことですが、普段から記述が冗長ではないかをチェックすべきでした。

### 3. 命名
変数名やメソッド名の命名に関しては個人的に難しいと感じています。
例えば、`ある商品を注文したユーザーの詳細情報`を`$user`と名付ける場合、漠然とした情報になってしまうので、その変数にどんな情報が入っているのかわかりやすい変数にする必要があると思います。`$orderedUserDetail`としてあげれば関連するユーザーの情報というのがわかると思います。
命名が良くないという指摘は最近は減りましたが、ここまで多い指摘の一つでした。

### 4. テスト不足
実装後のテストで、考慮しきれていないということがありました。
「**実装を行った結果、要件を満たす挙動をしているのか？**」ということは確認を行いますが、その実装を行った結果、「**他の機能に影響がないか？**」ということに対してテスト不足となる場合がありました。**実装が終わった！できた！よかった！**ではなく、本当にそれで良いのか？と自分自身を疑ってかからないといけないと思います。
また、バグを発見できる能力は経験から来ると感じているので、最初にバグが起こりそうな部分はどこなのか先輩エンジニアに**アドバイスをもらう**というのも1つの解決策だと思います。

# まとめ
人はミスをする生き物だと思います。ミスを０にするのは難しいですが、**ミスを限りなく少なくする**ことはできると思います。
ミスをしたら、ミスをしてしまったなと思うだけではダメで、**ミスを蓄積**して同じミスをしないようにするということが重要だと思います。

現在では、自分のコードをレビューしてもらうだけではなく、後輩インターンのソースコードをレビューするという経験もさせていただいています。レビュワーの目線に立つとコードを見たとき、ここはこうじゃないか？と思うこともあります。自分がたくさんのミスをしてきたからこそ、指摘できる部分もあります。まだまだ、経験の面で先輩エンジニアには敵いませんが日々精進したいと思います。

最後にですが、ソースコードレビューを減らすという目的のもと、始めた`review貯金`ですが回数自体は減ってきましたが、完全にゼロにはなりません。レビューしていただいている方に感謝しつつ、無駄な指摘が増えないように頑張りたいと思います。

# 補足
書き始めから、記事をあっためてしまっていたので、レビュー回数が増えてしまっています。
現在のレビュー指摘回数は**278回**になっています。卒業まであと約半年ですが、なんとか400回には収まるように、気をつけたいと思います。