仕様書について

ちょっと前まで仕様書を書く＝アジャイル開発の失敗、と思っていた。
アジャイル開発において、理想的にはspecが仕様書となり、あるいはソースコード自体が可読性が高く保たれていればドキュメントや仕様書は不要なものだと思っていた。しかしこれは間違いだ。まずspecは思っているほど仕様を語らない。

そして最近書いていて思うのは、本当にコードがよくわからなくなるのはコード自体が汚くなるというよりそもそものビジネスロジックが汚いケースも多い。
例えば
「商品XをAさんが買った時、以前Aさんが商品Yを買っていたら-10%, そしてAさんのfacebookの知り合いBさんがXを購入していたらさらに-10%したうえで、Bさんに５％キャッシュバック、ただしクレジットカードの決済の場合は割引率は最大15%。。。」

みたいなビジネスロジックはどう書いたって複雑になる。
エンジニアは汚いコードを書いてビジネスロジックの意図が見えづらくなる＝ビジネスロジックの複雑性を相対的に大きくしないことには敏感だけど、案外ビジネスロジックそのものの複雑性について直視していないことが多いと、自戒を込めて感じる。

まぁ上のケースは、いっけん複雑そうだけどコードに落とせば長いだけで、案外将来的に破綻するほど複雑というわけでもない。たぶんコードが長くなるだけで、分岐がいく通りにもなるようなものではないのでましなほうだと思う。

怖いのは分岐がすさまじくなるようなケースで、３カラムくらいにまたがっているステータスが複雑に絡み合ってるようだともうアウト。
payment_status #=> deposit(与信) | captured(決済済み) | cancel_not_paid(キャンセルして未払い戻し) | cancel_paid(キャンセルして払い戻し済み)
delivery_status #=> at_storehouse(倉庫) | on_track(配送中) | at_shopping(店頭) | at_home(自宅) | on_track2(配送後、戻し)
delivery_to_owner(決済者と配送先が同じか) #=> true | false

こうなるともう絶望的で、ここで「商品配送先がマイページから変更可能である」というメソッドを書こうと思うと、これはコードが複雑云々の前に考えないといけないことが多い。そしてこの手の複雑性から生まれる仕様的なバグは、プログラムのバグと違って音を立てずにビジネス全体を侵食していくので、最も恐ろしいもののような気がする。