このエントリはTDD Advent Calendar jp: 2011のエントリーとなります。
前日の@yuri9976さんのエントリ「TDDと共に（成長記録としてのTDD）」に続く23日目の記事です。
23日目はTDDを初めて2年目のオム子がエントリを担当します。
ラスト3の座をゲットしてしまい、さらに電子書籍化の話…と気が遠くなりそうになっていましたが、がんばります。
職業プログラマ
まずは、タイトルの「職業プログラマ」って何さ、って話からしましょう。
職業プログラマとは（※オム子定義による）
「プログラミングを職業としているので勤務中はコードを書くがプライベートではほとんど書かない」
「詳細設計書通りにプログラムができていればそれでよい」
「与えられた環境と技術以外のことは求めない」
「コードよりもExcelと向き合っている時間が多い」
「割と大規模なプロジェクトで昔からの文化に染まり、それが常識だと思って仕事をしている」
「何かを始めようと思っても何かしら職場の敷居が高い」
「（だから）新しい技術がたくさん出ているけれど、それは自分の職場には関係のないことと割り切る」
「だけど、ちゃんとものを作りたいな、って思っている」
「ちゃんとものができて、職場から早く帰ることができたら最高」
そんなプログラマです。
「コードを書くのは仕事だから。仕事は与えられた通りにやる」
「一応、仕様書で求められていることには答えているはず」
「こんなコード量産していいんだろうかとちょっと不安になる」
「でも今更何か新しいことをやってみようとか言えるような環境じゃないから割り切るしかない」
そう思っているプログラマは結構いると思います。
「これでいいんだろうか、一歩先に進みたい、でもどうしていいかわからない」
「もうすこし、効率的に、品質の良いものを作ることができないだろうか」
そんな人もたくさんいると思います。
まあ、それは、まさに数年前の自分だったりします。
2年前に受けた衝撃
さて、そんな職業プログラマだった自分は一歩先に進みたくて転職をしました。
（転職によって、問題解決しやすくなっているだろというツッコミはご容赦を）
転職直後には本当に色々なカルチャーショックを受けました。
昔の自分にとってのテスト
自分にとっての「単体試験」は「Excelの”単体テスト項目表”に”詳細設計書”の内容を写すこと」でした。
“詳細設計書通りに作ったプログラム”を”テスト項目表に書かれている通りに”動かして、問題なければ日付と名前と○を書いて…。
テスト項目表のフォーマットや誤字脱字のレビューをされて、プログラムと一緒に納品する。
それが当たり前で「正しい方法」でした。
納品後プログラムにバグがあったり仕様が変更したりしても、詳細設計書や単体テスト項目表には触らない…そんなことも、ありました。
テストコードに出会った話
そして、転職先での初めてのプログラミング。
「まず、テストコード書いてみようか」
衝撃でした。
テストコードを最初に書いたことと、テストコードを書くことによっていろんな事が見えてきたことが。
- 使いやすいインターフェースを考えるようになった
- エラーハンドリングや例外系に早めに気がつくようになった
- バーが緑になることで安心してリファクタリングができた
- テストコードでバグを再現してから修正することでバグ修正に自信がついた
「TDDの良さ」と言われる部分を身をもって体験したのでした。
まったく同じようなコードの書き方をしていたので、17日目のmao_instantlifeさんの記事には深くうなずくものがありました。
衝撃の体験を繰り返すことにより、テストコードが当たり前となっていくと、
プログラマがプログラミングをする責任っていうのは
「”仕様書通り”という第三者のチェックを通ったコードを納品すること」
だけじゃなくて
「自分が自信を持ってコードを世に送り出すこと」
なんだなぁと気がついていきました。
数年前に戻れたら、何ができていたかな
その他にも、CI環境の整備であるとか、プロジェクトの進め方であるとか、ドキュメントについての考え方であるとか、コミットのタイミングであるとか、新しく気がついたことはたくさんあるのですが。
「数年前、職業プログラマの自分が一歩前に進むために何ができただろうか」
と考えてみたとき、一番やりやすいのはTDDだっただろうな、と思うのです。
TDDは一人でもできる、最悪ローカル環境だけでも勝手にやれば良い。
一番小さく始められて、仲間を増やしやすい方法がTDDじゃないかな、と。
今の自分なら、できる気がする。
でも、数年前の自分だったら始められなかったと思います。ノウハウがあまりにも乏しかったから。
今すぐはじめられること
もし、今、昔の自分と同じような境遇の人で、何かを変えたい、だけどやり方がわからない、
そんな人がいたなら何をするのがよいか、考えてみました。
TDDBCに参加する
全国各地で開催されているTDDBCに参加する、これが短期間でTDDを学ぶのに一番良い機会だと思います。
何より、自分でコードを書いてみることができる。
普段使っている言語のテスティングフレームワークを知ることができる。
TDDの流れをつかむことができる。
経験者の話を聞くことができる。
今すぐ職場でTDDを導入できる機会がなくても、休日を1日潰して1回参加してみる価値はあると思います。
自分が1回経験しているかどうかで、いざ現場で導入しようとなった時の心の敷居はずっと下がります。
自分でゼロからプロジェクトを構築できるようにする
大規模案件が続くと、自分でゼロからプロジェクトを作ることがなかなかないのですよね。
プロジェクトを作って、動く環境を作って・・・という機会がなかなかない。
ビルドや実行環境はよくわからないけどちゃんと動く仕組みができていて（あるコマンドを打てばそれでOKで）、普段は自分が担当するソースコードだけを触ればよいだけ。
でも、その環境にテスティングフレームワークをどうやって取り込んでいいのかわからない。
プロジェクトを触ることが怖いと感じてしまったりします。
これでは、なかなか自信を持って導入しよう、と周りに勧めることはできません。
だから、ブランクプロジェクトでよいので、いったん自分で環境をそろえてみることお勧めします。
JavaであればEclipse+Mavenなんかを使うと、思っている以上にすぐにプロジェクトを作ることができます。
たとえば、TDDBCに参加して、「自分のチームの開発環境準備を自分がやります！」と宣言してみるのはとても良いと思います。
詰まったら教えてもらえるし、失敗しても損害にならないし、お題の規模そこまで大きくないのでスモールスタートで肝を押さえられると思います。
自分が1回経験しているかどうかで他の人に勧める際の自信がぐっとつきます。
TDDBCのお題の復習をする
上記ができれば、もう大丈夫。自宅でTDDを行い技を磨く準備ができています。
TDDBCのお題であれば、どこかに他の人が実装したコードもあるはず。
自信を持って、仕事以外でも手を動かすプログラマになりましょう。
職業プログラマをDisってるわけじゃない
職業プログラマであっても、「良いものを作りたい」という気持ちがある人はいると思います。
「効率的に仕事をしたい」そう思っている人もたくさんいると思う。
ただ、文化の違いや決定権の有無などで、どうしても新しいものを導入する敷居は高くなる。
簡単にできないことも多いし、守っていかなければいけないものもある。
そんな中、色々諦めざるを得なかったことがたくさんある。
職業プログラマとして割り切っているつもりでも、なんかやるせないな、モヤモヤするな、もっといい方法あるんじゃないかな、と思っている人はたくさんいると思うのです。
- 自分の気持ちを落ち着けるために
- 作っているものに自信を持つために
- 効率的に楽しく仕事ができるようにするために
- 今後周りと一緒に文化を変えいくために
TDDをはじめてみませんか？
自分の経験から自信を持ってお勧めします。
来年もたくさんのTDDBCが開催されると思います。
是非一度、その扉を叩いてみてはいかがでしょうか？
明日は24日、イブですね！ラスト2エントリーとなりました。
aoki1210さんのエントリ「TDDに関する記事のリンク集」です。
One comment: