まずは単体テストから！

久しぶりに単体テストコードを書いてます。
既存のシステムの移植作業なのですが、
単体テストが無かったので作成しています。
ただ、解析するよりも単体テストを作成する方が理解も深まりますしね！

改めて、つくづくと、単体テストコードはソフト開発には欠かせないと感じます。

そう感じる事をつらつらと。

1)正しいコードに集中出来る
　環境(ハードやOS、etc）的な制約が無く、正しい論理を書く事に集中できる。
　もちろん、処理としては環境依存するものは存在しますが、
　これは設計でカバーすべき。
　結果的に、正しいコード（論理）を書く事に集中出来る。

2)不具合原因の特定が早い
　単体テストにパスしている論理を疑う必要がなくなるので、
　結果的に疑うべき範囲が狭くなり、原因の特定が早くなる。

3)再現可能
　単体テスト環境でほとんどの不具合が再現可能かと思っています。
　実機でしか起きない不具合は極々僅かかと。
　多少の制約や条件はあるにしても、
　すべて論理ですから、単体テストで再現可能になる筈

4)リファクタリングすべきところが分かる
　テストがし難いところは関係性が複雑だったり
　依存関係が強すぎる事が明確となります。
　つまり、それはリファクタリング対象となります。

5)動くドキュメント
　全体の概念図や構成図はドキュメント化が必要ですが、
　詳細な論理は細かなシーケンスを書くよりも
　単体テストを動くドキュメントとすれば十分かと。
　開発者にとっては十分過ぎるドキュメントかと思います。
　シーケンス図は設計作業としては必要かと思います。
　また、イメージとして記憶するのにも役に立ちます。
　ただ、あれもこれもメンテナンスするのは大変なので、
　単体テストだけをメンテナンスすれば良いと思うのです。

6)正しいコードに集中出来る（デバッグ時）
　今回、ある環境で動かすと発生する不具合を
　単体テストを活用して原因特定したのですが、
　関連した単体テストでパスしているテストがあるので、
　正しく動く条件は分かります。
　あとは、その条件をどのように壊すか、
　壊す組み合わせを考えれば良い事になります。
　それ以外は考える必要がなくなります。
　ハード的な要因を疑うよりも、論理に集中する事で、
　原因究明が早くなります。

と、長くなるので、このへんで。
やはり、単体テストが中心の開発が欠かせないですね！
それは、ずばりリボンモデルです！！　

JTBDのいろいろ活用法

先日、ある雑談から、
JTBD(Jobs to be done)の意外？
いや、むしろ当たり前と言って良いと思う活用法を知りました！

それは、自分達の直接の「顧客が解決したいJOBを知る」
と、当たり前というか、基本的なところです…

これって当たり前の事ですが、
なかなか意識されていない気がします。

こう考えると、身近で活用できるシーンが多くある気がします。

ちょっとした頼まれ事や、
クレーム対応などでも、JOBに着目する事で
無駄が無くなり、解決が早くなる気がします。

更には、
改善でも、そもそも我々が解決したいJOBは何か？
提案でも、どんなJOBが解決されるのか？

こちらも、JOBを定義する事で無駄が無くなる気がします。

TOCではUDEやDE、中間状態など、
状態を定義するのに苦労しますが、
解決したいJOBは、DEと同じですね。

JOBとして考える方が考え易い場合もありそうです。
また、ひとつ気づきを得ました！
雑談侮るなかれ！