かれこれ12～3年前、僕が最初に入社したSIerでのお話。
同じ職場の若い技術リーダーが、僕を含む新人プログラマにこんなことを何度も言ってきました。
「プログラムのテストはコーディングが全部終わってからにしてください」
つまり、最後の最後までプログラムを動かすな、全部作り終わってからテストとデバッグを始めろ、という意味です。
今思えばあれは完全に間違った指導だったよなあ、と思います。
プログラムはちょっと書いてはデバッグ、ちょっと書いてはデバッグ、を繰り返す方が絶対効率が良いです。
理想的にはTDDのサイクルがよいと思います。つまり、
- テストを書く
- テストが失敗することを確認する
- コードを書く
- テストがパスするのを確認する
- gitにコミットする
- リファクタリングする
- テストがパスするのを確認する
- gitにコミットする
・・・というサイクルをちょっとずつ繰り返した方が堅牢なプログラムを効率よく作れます。
さっきもそんなサイクルでコードを書いていて、ふと新人だった頃の思い出が頭をよぎったので、こんなポエムを書いてみました。
とはいえ、
僕が入社した当時はVisualBasic(VB)の開発がメインで、TDDという考え方も全然浸透していませんでした。
プログラムの動作確認は手で動かして目視で確認し、Excel方眼紙で作られたテスト項目一覧に丸を付けていく、そんな開発プロセスになっていました。
（僕が知る限り）当時は世間一般でも「一度作ったものは必要が無い限り絶対変更するな！」というリファクタリングと真逆の考えが是とされていたので、「そういう考え方になるのも仕方なかったのかなあ」という気がしなくもありません。
ただ、それでも「コードを全部書き終えるまで絶対動かすな」というのはやっぱり極端だと思うし、タイムマシンで当時の現場に今の僕が放り込まれたとしても、たぶん「ちょっと書いてはデバッグ」の繰り返しでコードを書くと思います。
ちなみに、
冒頭の先輩プログラマのセリフは、厳密に言うとちょっと違います。
当時言われていた言葉をそのまま書き写すなら、
「プログラムのテストはパンチが全部終わってからにしてください」
でした。
パンチって何？って思った若いプログラマの方は40～50代ぐらいのおじさんプログラマを見つけて質問してみてください。
いや、僕は実際には「パンチ」はやっていませんよ！
ただ当時の現場に「パンチ」という用語が残り続けていた、というだけのことです。
