qiita.com
コメントが炎上ぎみでして。
これを読んでて、もしかすると私たちは
ちょっとずつ違うことを考えているのではないかと思いました。
私のTDDは、と言えば、
簡単な動作確認プログラムをさっと書いて、
それを使いながら機能を成長させ、コードを整えていく、
というのをときどきやっています。
テスティングフレームワークは使わず。
後で使えそうなものなら、テストコードとして置いておきます。
...といった程度の、ひじょうにゆる～いやり方しています。
これを TDD と名乗ってよいものか。
でもこれで設計考えてるんだから。「ぷちTDD」とでも言っておきましょうか。
組込みって、動かす環境を用意するだけで大変だし、
ROM焼きだ、ICEだ、デバッグ出力だ、みたいなところもあって
確認方法の用意も考えないといけないし、
まぁとにかくめんどくさいので。
TDDやるには、
ある程度、コードの設計ができないといけないな、と思います。
みんなどうやって（仕事の）コード書いてるのかな？
いきなり書き始める？ どこまで仕様書に落とす？
詳細設計書があって、関数仕様書があって？ クラス設計とか？
ひところに比べると、いちいち関数単位まで仕様書起こしたりする仕事は
減ってきているように思います。
が、私がちょード短期のちっちゃな案件ばかりやってるせいかな？
だからみんながどうやってコード書いてるのかは興味あります。
私にとって TDD は、そういうことの一部なので。テストと関係なくて。
twop.agile.esm.co.jpいろいろ言われてるけど、意味はある、と思うよ。
diskogs.hatenablog.com↑結局、ここがいちばんまとまってそうな。感情穏やかに読んでいられる。
組込み TDD の勉強会のキックオフに、先日参加しました。
モブプロ、無条件に楽しかったです。
せっかくの場なのでこれからも続けていきたいです*1。
↓このへんのことにもコメントしようと思ってたけど、自分流は↑に書いたから、まあいいか。
ubiteku.oinker.me
ubiteku.oinker.me
ubiteku.oinker.me
ubiteku.oinker.me
ubiteku.oinker.me
ubiteku.oinker.me
*1:そのためには、いまの職場の働き方をどうにかしないとな！！
