TDDをはじめる条件 #tddbc #tddconf
色々と忙しすぎてブログが書けません。
JavaOneの話とか、JUnitの話とか色々書きたいんですが…もうしばらく我慢なのです。
で、TDDの前方依存と後方依存で意見が欲しいとのことなので自分なりの意見を。
技術的な前方依存
『TDDを始める前と終TDDを実際やるために必要な技術』
・最低限対象言語でコードがかけるようになって
・最低限テスティングフレームワークを使えるようになって
・リファクタリングをしっかり学んで
・対象言語でのきれいなコード、設計とは何かを知って
・テストファーストを知ってこうしておそらくスタートライン。
自分はこれは疑問です。
最後の「テストファーストを知って」という部分はTDDに関することですけど、それ以外ってTDDを始めるスタートラインではなく、ソフトウェア開発としてのスタートラインかと思います。
言い換えると
- 最低限対象言語でコードを書けないと、ソフトウェア開発できない
- 最低限テスティングフレームワークを使えるようにならないと、ソフトウェア開発と言えない
- リファクタリングができなければ、ソフトウェア開発と言えない
- 対象言語でのきれいなコード、設計とは何かを知ってなければ、ソフトウェア開発と言えない
つまり、ソフトウェア開発をする上で、ユニットテストとリファクタリングが必須であるならば、それはTDDの条件でもなんでもない。設計とかについてもメンテナンス性を考えれば必須。これはTDDを採用するか否かはあまり関係ないと思う。
それが出来ているかは別として。
で、じゃあ出来ないやつはソフトウェア開発をする資格ないので開発するな、ということかといえば、半分は正解で半分は間違いだと思います。
最初からそんなスキルがある人はいません。早い人でも２−３年、普通な人では５年くらいはかかると思います。だから、それらを教え、共に学ぼうとする文化がチームに必要と考えています。また、比率的にも1人の熟練者に5人の弟子とか無理ゲーですから、4人の熟練者に2人の弟子くらいの割合でなければいけない。勿論、弟子がリソースとして1人とカウントされるのもまずいです。
つまり、そこそこ技術のある組織で、チームで育てる余裕があるのは必要な条件なんかと。そんなチームでやるならば、TDDを始めるのに前提条件なんて何もないと思う。逆にどれもできていないチームでやるならばTDDどころかソフトウェア開発をやめた方がいいと思う。
そんなことを、来年から社会人らしい @pocketberserker へと、書き殴っておきます。
追記
問題点としては、意欲のある人しかそこら辺の技術を身につけようとしないこと。あるいは、ここら辺の技術を教える時間がない/あるいは会社が認めてくれないこと。
伝わっていなかったようなので、大切なことなので、書きますが、そんな会社は「ソフトウェア開発をやめた方がいいと思う」。
経験が浅くて（まだ）できない人は許容されるべきだけど、ソフトウェア業界として、リファクタリングやテストを軽視する会社は滅ぶべき時代だと思います。
