初めてのソースコードレビュー

私は「プログラマ」というポジションで仕事をしたことがなく、ソースコードレビューというのも受けたことがありません。
そもそもプログラミングするのかっていう話もありますが、一応業務で使っている仕組みをVBAで組むくらいのことはしています。
そんな話を愚痴まじりにTwitterでつぶやいていたところ、VBAでツールを作ってくれないかというお話をいただきました。
こんななんとかのたまごもいいところな私に、です。
ありがたいお話ですね。

要件を聞いてみたところ、私にも作れそうだったので引き受けさせてもらいました。

こんな形で成果物を要求されるというのもそういえば初めての話です。
業務担当者に向けてツールを作っている私が成果物として求められているのはその仕組みからアウトプットされたものであって、仕組みそのものではなかったりします。

”自分以外の誰かに向けてモノを作る”
ということに、最初の最初から疑問がわいてきました。
変数名はどうしようとか　笑
コメントはどれくらい入れたらいいんだろうとか、そのコメントも誰にでも理解できる内容になっているのだろうかとか。
プロシージャはどの機能単位にしたらいいのかというのも疑問でした。
どこまで細分化するのか、結構悩みました。

テスト段階までは1プロシージャ15～20行くらいで4つのプロシージャでしたが、動作確認の後全部まとめて1つのプロシージャにしました。
小さなプログラムだったのでここまで分割する必要はないのかな？という疑問符付きの状態で納品しました。


さて、今日納品物のレビュー結果が返ってきました。
指摘されたのは「仕様変更に対応できない」という点でした。
なぜか。
ひとつのプログラムに全部の機能を記述しているから。
仕様変更できるけれど、その度に全部のソースを解析する必要があり、無駄な時間を使ってしまう。

・・・おおぉ、、私は何をしているんだろう。
頭ではわかっていたことが実際には全くできていませんでした。
プログラミングの本を読めば必ず書いてあるようなことが、プログラミングの本を読んできた私にできていなかったのです。
と同時に疑問に思っていたことがすっきり返ってきました。
どんな小さなツールであっても、プログラミングをする上で考えてあげなくちゃいけないことは同じ。
可読性だったり保守性だったり、ソフトウェアとして持っておくべき品質は規模に関わらず同じなのですね。


教科書に書いてあることと自分がやったこと、現場で求められているもの、その3つが同じフィールドに並んだ瞬間でした。
自分だけで完結していては見えなかったものが見え、また自分がやるべきことが明確に現れてきました。
自分のたまごレベルもよくわかりますね。


勉強だけしていても実際にはわかったつもりのことが多いのかもしれません。
こうして実践して指摘をいただいて、何が失敗だったかを理解すること、そこからまた次の成果を出すこと、この過程こそが本当の勉強なのかもしれないですね。
机上で教科書を読むのなんて、予習くらいにしかならないのかもしれません。