spec考

じつは今までrspecがコスパに見合ったものだとは一度も思ったことがない。

たしかにコードの品質は上がると思うけど、rspecを書くのに時間をかけるより、プロダクト本体のPDCAを回したほうが生産性が高い気がする。

ほとんどのプロジェクトでは、何か合理的な目的があるわけでもなく「それは必要なものなんでしょ？じゃ、書いて」ぐらいのノリで書いているだけだと思う。 SIer系が「これは必要なドキュメントなので作成してください」って言われてしかたなく作る不要そうなドキュメントと実は大差ないのでは？

ただ、今までの経験上、わりかし多くのプログラマーが品質の低い(というか雑い)プログラムを書くので、そこを底上げするためにspec文化の必要性が高まってきたのだと思う。

現在進行形で実装しているコードを可能な限り早く目に見える形で動かして、動作検証しながらゴールとなる処理を組み上げていく、っていうのが自分のコーディングスタイルなので、自分はspecの必要性をあまり感じない。

実は、平均的なプログラマーは上記のコーディング上のPDCAを回さずに、最初に考えたロジックが書けた時点で完成としてしまう傾向があるんだと思う。だいたいにおいて、実装して検証している過程で、最初に考えたロジックにおける間違いや矛盾点があぶり出されてくるので、PDCAを回しながらコーディングするのは大事だと思う。

普通にやると…

　考える→書く→完成

というだけの作業になってしまうが、そこでテストという工程を挟むことにより…

　考える→書く→動かす→検証→軌道修正→動かす→検証→∞→完成

というPDCAを回しながらコーディングする習慣を身に着けさせて、コードの品質をあげるという試み、それがTDDである(たぶん)。

コードをガリガリ書く能力より、出来上がったものがちゃんとできてるか確認・検証する能力のほうが大事。

Tag: プログラミング