システム開発におけるソースの修正コメントは善か?悪か?

f:id:stayyou:20160407172306j:plain

修正コメントは古い文化である

ソースを修正する際にコメントを残しているコードをよく見ることがある。これはバージョン管理がされていない時の文化で、今はバージョン管理でどこをどのように直したから分かるし、コードが見づらくなるから不要だ。というのが現代のシステム開発なんだと思う。

自分も先輩に修正するときは「どこからどこまで誰がいつどのように直したかコメントを残せ」と言われたものだが、それから色々成長して勉強していくうちにその文化は古いことに気が付いた。そこから調子に乗っていた自分だったので、コメントを残さない派でいるのだが、やはりたまに上司にコメント残せと言われることがある。

修正コメントが必要になるとき

最初の頃はただ古い考えとしか考えていなかったため、特に気にしていなかったが、最近なんで何も書いてないんだよって思うことがあった。それは現地にいるときとバージョン管理できない環境にいるときにソースを確認する時だった。

受託開発をしていれば当然のことだが、最終的に顧客の実機環境に入れることになるので、当然バージョン管理をする環境でなくなる。今までは自社で開発をして先輩に行ってきてもらうという流れだったため、あまり気にしたことがなかった。バージョン管理していない環境でソースを管理していると、意外と古いソースでファイルを上書きしてしまうことがある。(古いソースを送ってしまうこと自体問題だが、ヒューマンエラーとして考えないこととする)どれが最新のソースかわけ分からなくなったときに、修正箇所に修正コメントが残っていると非常に助かることは誰もが思うだろう。

一方で自社で開発を行っているときにはそのコメントは非常に邪魔になる。同じ個所を一回修正するだけならいいが、複数回修正されるとかなりコードが見づらくなるし、コメントアウトが多すぎてスクロールするのがものすごくイライラする。イライラするだけならまだいいが、本当に修正が多くなってくるとその見づらさが不具合を残すきっかけになることもあるだろう。

結局のところ修正コメントっている?

両方の観点から考えるとどちらが良いとは一概には言えない。自社サービスの開発で最初から最後までバージョン管理できるのであれば、修正コメントは不要だと思う。(コミット時にどのような修正をしたかコメントを残すこと)しかし、受託開発などで最後はバージョン管理できなくなる場合はどうするべきが考える必要がある。

シンプルにバージョン管理している間は修正コメントを書かず、現地試験のフェーズに入り、バージョン管理できる環境でなくなった瞬間から修正コメントを残すというのがベタに良いと思う。そのようにあえて書くには意外とメンバー内でこのことが徹底されていないからだ。

単体テスト、結合テストと開発を進めていくと自分で作った画面で合っても他の人が修正するようになることが多い。その際に修正コメントを残す派のひとはどんどん修正コメントを残してしまい、現地に入る頃には修正コメントでいっぱいになるだろう。

本当はこういうことをプロジェクト開始前に決めておかなければならないのだが、細かいところまで決めておけないのが開発現場の現状だと思う。バグが多発して忙しくなる前にこのような小さいことから気を付けなければならない。