これを読んでいてTDDっていいな…と改めて思ったのだが、、
プログラミングで「もっと早く知っておけば良かった」と思う知識はなんですか？「TDD（テスト駆動開発）。すなわち、テストコードを書き、実行して失敗し、それが成功するコード実装を書き、テストを成功させる。そして、リファクタリングをする。」
https://qr.ae/pvs79K
既存プログラム回収後のテスト作業が増大する…これを解決する手段がTDDなんだなというのがなんとなくわかったのが…
個人的な…極めて個人的には、TDDって感覚的にメリットが分かるんだけど、個人レベルだと「いえや！」（気合）で作るなり保守・拡張してしまったほうが圧倒的に早い気がしていて、導入するには及ばない。
求められた要件が、とある既存プログラム/既存モジュールの使い回し＆拡張でなんとか対処できそうだという確信を得るために、すごーい昔に書いた（脳にまったく記憶されていない）コードをトレースして、ここをこうしてああすれば行ける…と目算を立てられたものの、すでに実行中の処理系に影響を与えずに機能拡張した部分のテストを適切にできるのか？は自信がない。
しかし、テストプログラムなんてないぞ…この拡張要望からの拡張処理を書いていく繰り返しの中で「もっと早くからTDDを導入していればこんな苦しい状態」にならず、ビジネス的にもコストが上がってしょうもない状況にはならなかったのに…ということになるのは分かる。
分かるのだが…
その既存プログラムが将来にビジネスにおいてキモになるかどうかって…未来にならないと分からないわけです。
…すでに開発中の段階で、将来どういうシステム要求が生まれてくるのかの予想を踏まえてシステム開発するくらいじゃないと、独りよがりにならないだろうか？
このへんって拡張が今後求められまくるからTDDしておこう…という判断が吉と出るような分かりやすいビジネスを展開している場合、そのシステム改修コストはあらかじめ盛り込まれているはずなので、TDDじゃなくてリプレイスもしくはプロトタイプ→新規作り直しって選択肢なんかもありうるわけで、勝手にTDDしておきましたというのもおかしい。
最高技術責任者あたりがシステム保守戦略的に導入するものになるんではないか。そこに合わせて自主的に経験しておくってかなり独りよがりのシミュレーションや自己学習になる気がしてためらわれる。
この表にある通り、導入コストがかかるということと、また将来にわたっての拡張性が求められることが不確実だということを踏まえて、TDDの知識に投資すると自分が果たして活かせるのか？が進んで学ぶ意欲の妨げになっている。
しっかり学ぶなら自分のプロダクトにがっつりTDDを盛り込みたいですし。
なんか言い訳臭くなった（汗）
でも、既存プログラム回収後のテスト作業が増大する…これを解決する手段っていうならやはりどこかで導入したい。
また、あの複雑な処理へ手を加えるの？…リファクタリングどうしよう…が「えいや」と気合で対応するにしても、その気合いが小さくて済むのならぜひ試してみたい。感覚的にやっているテストに漏れがなく品質が高まり、なにより開発コストが下がり、自分の余暇が増える方へ光のある方向へ進みたい。それが生物の性。
PHPUnitはちょっと使ったことがあるがJestは使ったことがないな…さっきまで何なのかよくわかっていなかった（汗）
コメント