hitode909の日記

趣味はマリンスポーツですの日記です

コミットメッセージちゃんと書こうっていうの,まあそうだけど,どれくらいちゃんとしたらいいか,よくわからない.
たぶん,コード読んで分からなかったらコメント読んで分からなかったらコミットメッセージ読んでわからなかったら社内Wikiとか検索しまくるみたいな感じだと思う.
コードとコメントは普通にファイル開いたら読めるから,そこで分かるようになってれば,コミットメッセージ適当でいいと思う.
GitHubとか使ってレビューするなら,コミットメッセージが全面に出てくるから,作業の説明をまとめる変わりに,コミットメッセージ読んでください,くらいで済むと思う.
けど普通のソフトウェアを理解しようというときに,コミットメッセージをめちゃくちゃ利用しようということはあまりなくて,困ったときに読むみたいな感じだと思う.
コミットというのは変更であるから,変更の理由とか事情を説明をして,コードそのものはコミットメッセージなくても理解できるのが自然だと思う.いまのコード読んでる人にとって,前はこうで,今はこういう事情でこうなっている,という事情はあまり重要ではないと思う.前がどうだったか知らなくていいと思う.さらに変更しようと思ったときに前の状態に戻ってしまると困る,というのはあるかもしれないけど,そういう,普通に考えたら前の問題ある状況に戻るような微妙なことはコメントに書いておくべきだと思う.


コメントが不要なくらいきれいなコードを書こうって言ってる人いるけど,普通はそんなにきれいに書けないと思うから,現実的でないと思う.
普通はコメントが不要なくらいコードきれいにしている間に気まぐれで仕様とかが変わって,「ここはこういう事情でこうなっています」とかコメント書かざるを得ない状況になると思う.
アプリケーションの仕様とかはそうだけど,ライブラリとか書く場合には,気まぐれで渋々こうなってるライブラリとか誰も使いたくないだろうから,コメントなくせるくらいきれいに書けるのかかもしれない.


それと,コミットメッセージには変更についての情報しか持てないから,変更しなかった理由とか,変更についての意見とか,ここに苦労した,とかは別のところに記録するべきだと思う.グループウェアとかあるなら,そういうところに書いたほうがましで,こういう設計が最近かっこいいと思っていますみたいな話とかがいきなりコミットメッセージに出てくるのは変で,日記とかに書いたほうがいいと思う.


これくらいの温度感だから,自分でもコミットメッセージちゃんと書けてるか分からないし,コードもきれいに書けてないと思う.つらい.