ソースコメントはエンジニアの優しさを表している

1人のエンジニアが生涯１つの案件を見ることはない。

裏を返せば、1つの案件のすべてを知っているエンジニアは存在しないということです。

１つの案件のプログラムソースのロジックや意図をすべて知っているエンジニアは存在しないのです。

となると例えば、10年前に改修をした箇所のロジックやその意図はどうやって引き継ぐのでしょうか。

内部資料に残すのでしょうか。

すべての改修箇所を残すのはほぼ不可能ですし、非効率です。

口頭で伝える続けるのでしょうか。

日々、目まぐるしく改修が発生する中、口頭で伝達できるほどプログラム改修は簡単ではありません。

最も効率的な引き継ぎは１つ。

ソース中にコメントで残すことです。

プログラムソースにそのプログラムが何をしているか分かるようにコメントを用いてロジックや意図を引き継ぐのです。

例えば以下のように、

/*AテーブルのaカラムをベースにしてBテーブルのbカラムを外部結合しているのはaカラムにはすべての対象データが入っているからです。*/

/*String型変数Xをint型に変換しているのは数値でif文条件を判断しているからです。さらにString型ですが、この変数XにはYテーブルのyカラム（データ型：number）からデータを取ってきているため数値しか入るはずがないので、int型に変換しても問題ありません。String型のままだと○○行目でエラーになります。*/

（少し大げさな書き方をしていますが）このように書いてあればそのロジックがどんな目的で書かれているのかが分かりますし、今後のプログラム改修の助けになります。おかしなロジックだなと思ったとしても意図的にしているのならそのままにしておこう。と思えます。

しかしこのコメントがなければどうでしょう。

コメントがなければ将来のエンジニアが外部結合を外してしまい、誤った情報をDBから取得してしまうかもしれませんし、int変換をやめてString型のままにしてエラーを起こしてしまうかもしれません。

バグが発生します。

ただ、実際のところコメントを書かなくてもプログラムは動作するため、書くか書かないかはエンジニアの考え次第です。

しかし、だからこそコメントを書くエンジニアは思いやりの心を持った優しい方だと感じます。

会ったことのない10年後の担当者のために丁寧なコメントを書く。

直接的な感謝をされないのに、コメントを書くプログラム改修者はきっと気遣いできる方なんだろうなと感じます。

きっとタイピング音も静かなんだろうなと思います。

そんなエンジニアで構成されたプロジェクトはおそらく十中八九うまくいくのでしょうね。

僕はあいにくそのレベルに到達していないのですが、できるだけ丁寧にコメントを書くようにしようと思います。

知らないところでいつか誰かに感謝されるために。