23 年卒の新卒エンジニアが 2 年間のコードレビューの中でぶつかってきた壁とそこから得られたもの
こんにちは、コミュニケーションポータルを開発している株式会社PHONE APPLI にて Android エンジニアとして所属しているタクミです。
今回は、プログラムの開発工程の一つであるコードレビューを実務で約 2 年間行ってきた中でぶつかった壁や気づき、そしてそこから得た成長についてお話しします。
コードレビューとは何か?
コードレビューとは、簡単に言うと「プログラムの品質のために、他の開発者も交えて確認する工程」です。
株式会社PHONE APPLI では、この工程に Github を利用しており、そこでソースコードの管理を行っています。
具体的には、開発者がそれぞれプログラミングをした後は、プルリクエストという確認依頼を Github 上で出します。
それを、他の開発メンバーがプログラムの動作確認や、プログラムの書き方でさらに改善できるところがないかなどの確認を行います。
この工程を通じて、バグの発見やより効率的な書き方の提案が行われ、完了したら大元のプログラムに実装内容を統合します。
コードレビューを受ける側としてぶつかった壁
学生時代、私はプログラムを独学で作成していたもののコードレビューを受ける機会がありませんでした。
そのため、社会人になって初めてコードレビューを経験した際に大きな壁に直面しました。
特に、コードレビューではプログラムが動けば終わりではなく、可読性やメンテナンス性も重要視されることを初めて痛感しました。
コードレビューを受ける立場 ( レビュイー ) としてぶつかったコードレビューに関する壁は、こちらです。
終わらないレビュー指摘の数々
以前の私がプログラムを作る時のマインドは、「プログラムは多少めちゃくちゃな書き方でも動くからとにかくスピード重視でやっていこう」でした。
しかし、社会人になって仕事でプログラムを書くようになってこの考え方を改める必要に迫られました。
入社後初めて出したプルリクエストでは、 Java で書かれたプロダクトコードを Kotlin 移行させる作業を担当しました。
そこでまず指摘されたのが、プルリクエストを出す際に記載する説明欄があまりにも簡素すぎるということでした。
すでに説明欄のテンプレートは用意されていたものの、当時の私はこうしたものを書くのが初めてで、どう書けば良いか分からず「既存の動作と変わらなければ問題ありません」程度にしか書いていませんでした。
この指摘を受けて、過去のプルリクエストを参考にして、プログラムの変更によりどのような機能に影響があるのか影響範囲を書いたり、今回はどのような変更を加えたのかを付け加えました。
説明欄を修正し終えると、指摘されたのが Kotlin の機能を活かした書き方になっていないということでした。
例えば、変数をプログラム内に定義する時に Kotlin ではその変数が整数型なのか文字列なのかを、基本的には明示的に宣言する必要はありません。
一方、 Java ではそうした型の宣言も行う必要があるため、移行前のプログラムにはそうした型宣言が多く残っています。
この型宣言を消す作業の漏れがあったため指摘されてしまいました。
ほかにも、移行の際に条件式を間違えてしまっていた箇所なども指摘されました。
こうして、数日間修正に修正を重ね、なんとか移行作業を終えることができました。
かなり苦戦することになったプルリクエストになりましたが、これがプログラムを作る上でプルリクエストを出す前の自己点検がどれだけ大切かを知るきっかけにもなった経験です。
次にコードレビューをするレビュアーになった時にぶつかった壁についてお話しします。
コードレビューをする側としての壁
レビュアーになった時にぶつかった壁はこちらです。
何もわからず暗中模索状態に陥る
コードレビューを始めたての時は、いくら他人が書いたプログラムを読んでみたり、アプリを動作させたりしてみても、どこに問題点があるのか全くわかりませんでした。
そもそも、これまで他人が書いたプログラムを読むという経験がなく、慣れるまでにかなり苦労しました。
最初は、プログラムの動作確認をして問題なければ「動作確認 OK です」というようなコメントしか残せず、情けないなと自分自身に思いながらもがいていた時期もありました。
現状打破のためには経験と学習だ !
少しでもこうした状態から抜け出すために行ったことが、過去のプルリクエストで記載されたコメントを読んで、先輩たちがどのようなところを指摘するのか学習したことです。
過去のコメントを読むと私と同じようなところで指摘されているものがいくつかありました。
先輩たちも同じような苦労をされてきた、自分一人ではないと自分を鼓舞しながら学習を続けました。
ほかにも、入社した時に読んだトレーニング資料のなかにコーディング規約があったので、それを読み返して基本的な押さえるべきポイントも復習しました。
今でも他の開発メンバーが書いた自分が担当していない機能のプログラムを読むことは、苦労しますしプレッシャーを感じます。
しかも、私がレビューで OK を出した後に新たな指摘コメントが入ることがあります。
初めは落ち込みましたが、最近になってようやくこれは経験の一つだと割り切ってレビューを続けられるようになってきました。
コードレビューの中で直面してきた壁はいろいろありましたが、その反面コードレビューを通じて得られた喜びや達成感もありました。
コードレビューを通じて得られた喜びや達成感
「ここまでコードレビュー・実装が細かい人は今までどの現場でも見たことがない」と他のメンバーが口を揃えていうほど実力があり、Android チームメンバーの中で最も在籍年数が長い A さんが出したプルリクエストをレビューした時のお話です。
動作も問題なく、コードの書き方もほとんど指摘する箇所が見当たりませんでした。
ただ、その中で 1 つだけ私の中でどうしても気になる部分を発見しました。
その部分でエラー発生時の処理で出てくるエラーの種類が今実装しようとしている機能と少し噛み合わないのではないかと考えました。
そこで私は、 A さんが使用していたメソッドのことを調べ、そこからさらにメソッドを調べてプルリクエストのコメントに記載しました。
すると A さんから
「そんなものがあったんですね、勉強になりました。ありがとうございます。」
と返信が寄せられました。
これまでは、自分よりも圧倒的に勤務年数・業務経歴が長い人に向けてレビュー指摘をすることに対して
「こんな未熟者がそんなことをしても良いのだろうか」
という後ろめたさを感じていました。
しかし、今回の体験を通じて、年齢や経験年数にかかわらず、自分の意見を出すことがプロジェクトの円滑な進行につながると実感しました。
このことは、今までのコードレビューの中で最も大きな達成感を味わったレビューとなりました。
こうした経験を通じて、次のような成長を実感しています。
2 年の経験は私をどう変えたのか
この 2 年間におけるコードレビュー経験を経て、私はこのような成長を実感しました。
自分が作ったプログラムを他人がどのような解釈で受け取るのか考えるようになった
新しい技術や効率的な書き方への気づきが増えた
問題点を振り返る習慣がついた
順番にお話しします。
自分が作ったプログラムを他人がどのような解釈で受け取るのか考えるようになった
この意識は、いかにプログラムの品質を向上させられるかを考える元になりました。
仕事では同じアプリ・プログラムに何人もの人が手を加えています。
そんな中で大切なのは、自分の作業も相手が理解できるようにしないと思わぬバグが発生して、結局自分が責任を負う羽目になってしまうのを頭に入れて作業することだと実務経験から学びました。
また、他人から見てわかりやすいプログラムは自分自身が何ヶ月後、何年後に見返した時にもその時やったことを思い出しやすくなるというメリットもあるため、この考え方を持ってよかったと思っています。
新しい技術や効率的な書き方への気づきが増えた
私と同じ Android チームで働く経験豊富なエンジニアが書いたプログラムを読む中で、これまで知らなかったメソッドやもっと効率的な書き方を学ぶ機会が、この 2 年間の間でたくさんありました。
特にインパクトが大きかったのは、Android アプリのライフサイクルを使った記述方法で API を呼び出すか否か判定できる記述法です。
こちらの詳細についてはまたどこかの機会で記事にしたいと思います。
お楽しみに !
問題点を振り返る習慣がついた
自分が出したプルリクエストだけでなく、他のメンバーが出したプルリクエストに対して OK を出す時もなぜこの内容で問題ないと判断したのかということを頭の中で振り返るようにしました。
私が携わっているアプリは多くのお客様にご利用いただいています。
もし適当なレビューをして OK を出してしまったら、障害が発生する確率が高まってしまうため、コードレビューをする時はいつもこのことを念頭に置いています。
これからもコードレビューに真摯に向き合う
これまでの 2 年間、コードレビューと向き合ってきました。
この 2 年の間に経験した苦労や成長できたことがたくさんあります。
経験してきた苦労のブロックが得られた成長よりも小さいですが、重みがあるため重さが釣り合っています
しかし、これで終わりではありません。
むしろ、これからが本番だと考えています。
この 2 年間の経験を活しつつ、これから先もどんどん経験を積んでさらなる高みを目指していきます。