製造業の設計者からプログラマに転身したので、少しは製造業での生産性の見方は分かってるつもり。で、そういう視点からソフトウェアの生産性について呟いてみたら、意外やたくさんRTしていただいちゃったので、とぎゃっておくことにしました。
ソフトウェアの生産性について
製造業の設計者からプログラマに転身したので、少しは製造業での生産性の見方は分かってるつもり。で、そういう視点からソフトウェアの生産性について呟いてみたら、意外やたくさんRTしていただいちゃったので、とぎゃっておくことにしました。
ToDoリストのすすめ - 日々常々
TDDBCでTAやってぼやっと思ったことシリーズ。シリーズ？続くの？ - TDDBCのお題はざっくり「何ができるか」が書かれてることが多いですが、これはテストを書くのに十分な粒度ではありません。少なくともお題をそのままテストメソッド名にしてしまうのはダメなパターンです。簡単なところは上手く行くこともありますが、すぐに厳しくなると思います。 これは実際の開発でもよくあります。例え設計者が別に居たとしても、詳細設計書に書かれているものが十分であったことはあまり記憶にありません。咀嚼して適切な粒度に整理し直す必要があります。*1 TDDでのテストの歩幅は人それぞれだなので、明確な答えを示すことはできませんが、「何をテストすればこれができたと言えるか」が明確でない……言うなれば assert から書き始められない場合は、階段の段差の高さが自分のスキルに見合っていないと言うことです。 まず全体を見て
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンタープライズ分野での分散バージョン管理システム
6/23 .NETラボ勉強会で話してきます！ - the sea of fertility