Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

TDD is ...

qiita.com
コメントが炎上ぎみでして。
これを読んでて、もしかすると私たちは
ちょっとずつ違うことを考えているのではないかと思いました。


私は、簡単な動作確認プログラムをさっと書いて、
それを使いながら機能を成長させ、コードを整えていく、
というのをときどきやっています。

テスティングフレームワークは使わず。
後で使えそうなものなら、テストコードとして置いておきます。

...といった程度の、ひじょうにゆる~いやり方しています。

これを 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

d.hatena.ne.jp

*1:そのためには、いまの職場の働き方をどうにかしないとな!!