20181103 ミニTDDBC振り返りその1
都内某所でミニTDDBCみたいなものに参加しました。
今回学んだことは
1. きれいなコミットメッセージの書き方
2. 学習テスト
3. DDDなリファクタリング
この記事では、「1. きれいなコミットメッセージの書き方」について書きます。
今回の題材はこちら
我々のGitHub
1. きれいなコミットメッセージの書き方
問1で最初下記のような仮実装をしていました。
import unittest class SemVer: pass def get_notation(self) -> str: return "1.4.2" class TestSemVer(unittest.TestCase): def test_major_minor_patchにそれぞれ1と4と2を与えてバージョンオブジェクトを作成(self): semver = SemVer(1, 4, 2) actual = semver.get_notation() expected = "1.4.2" self.assertEqual(expected, actual) if __name__ == "__main__": unittest.main()
他の数字でも通るか不安なので、「1.4.2」以外のテストケースを加えました。
def test_major_minor_patchにそれぞれ2と30と400を与えてバージョンオブジェクトを作成(self): self.assertEqual("2.30.400", SemVer(2, 30, 400).get_notation())
テストケースを加えた後、「コミットすっぞ!」ということで、最初下記のようなコミットメッセージを書きました。
「major=2, minor=3, patch=40でSemVerを作るためのテストを追加した」
これに対して、モブメンバーの方から、こんなふうなご指摘が
「コードに書いてること文字に書いてるだけなので、コミットメッセージにする意味ない」
なんと、意味のないコミットメッセージを書いてしまったようです笑
「コミットメッセージは、なぜその変更をしたのか書くもの」
とのこと。
ここで、t-wadaさんの名言を教えてもらいました。
コードには How
— Takuto Wada (@t_wada) 2017年9月5日
テストコードには What
コミットログには Why
コードコメントには Why not
を書こうという話をした
そして、コミットメッセージのリファクタリングが始まりました。
コミットメッセージも仮実装から始めるスタイル?で、
最初とにかく書く→音読する→書いたことを解釈する→コミットメッセージのリファクタリング
という形で実装。
最終的に、
「入力値が異なると通るか不安なので、テストケースを追加した。」
というコミットメッセージになりました!!
これで、パンセン方もニッコリだそうです!!
(2. 学習テスト につづく・・・)