プログラミングの手法は世の中に様々あり、TDD（テスト駆動開発）・BDD（ビヘイビア駆動開発）・DDD（ドメイン駆動開発）など○○駆動開発の名がついたものがいくつかあります。
個人的に気に入っていてよく実践している、PDD（プロトタイプ駆動開発）とでも呼ぶべき手法があります。
例えばある機能Xを仕様変更するチケットを例にとってみましょう。
”行儀が良い正統なやり方”をとるのであれば、実装に着手する前に、仕様修正点・テスト観点を明文化したりソースコードの調査を行うかと思います。
実装に着手する前に、『何をどう実装すべきか』をある程度明確にしておくきっちりしたやり方です。
TDDもこれに近いスタイルです。TDDではソースコード修正を行う前にその修正に対するテストコードを書くことで、修正後のコードの振る舞いを修正前に決めます。
こういった”行儀が良い”方法を使うとコード品質向上・バグ数削減につながり、またレビュープロセスもある程度きっちりすることになるのでチームメンバーのスキル向上も期待できます。
一方”やんちゃで実践的なやり方”をとるのであれば、とりあえず勢いで実装してみて、セルフレビューしたり他者からのコードレビューを受けて、修正しつつマージまで持っていくというやり方もあります。
当然危険は伴う上ソースコードの質がどうしても低くなってしまいがちなのですが、ある程度ゼロの状態から機能を作り上げる時などは勢いが大事なので非常に有益なやり方です。
またほぼ全てを自分が書いているコードを修正する場合などは、事前調査せずとも隅々まで理解しているため、すぐに書きはじめたほうが圧倒的に早かったりします。
スタートアップでは重宝するスタイルです。
ではPDD（プロトタイプ駆動開発）ではどうやるのかというと、”やんちゃなやり方”で何度か事前調査を行った後、”行儀が良い”やり方で本実装を進めます。
どういうことかというと、プロトタイプ実装を何度か作っては捨てることを通じて調査を行い、理解が深まってきたら問題解決のアプローチについて文章化したりして考え、その後本実装に移るというやり方です。
プロトタイプ実装を行う際には、理想としては「こう実装すればこういう理由でうまくいくんじゃないか」仮説を立てた上で実装を始めます。逆に複雑すぎて何から手をつけたらいいかわからないときは、何も考えずガッと思うがままに実装してみます。指を動かしているうちに頭も回転してくるので、次第に仮説が浮かんできます。
プロトタイプ実装を進めると、その問題解決方法の良し悪しや、実装時に突き当たる問題点が様々見えてきます。「この設計の良い点・悪い点は○○だ」「もっと良い設計を思いついた」「実装上の問題として○○も解決する必要がある」等々…。
それらが見えた段階で、書いたプロトタイプ実装はもったいぶらず全て捨ててしまいます。（git stashなどで捨て、復元できるようにしておくとなおbetterです）
1回のプロトタイプ実装はだいたいの場合は10分に満たない程度の時間で行うのがコツです。なんなら3分程で終わることもあります。
1回のプロトタイプ実装で1つの問題解決アプローチについて仮説検証ができるので、そのサイクルを仮説検証したい分だけ繰り返します。大抵は1~3回程度あれば十分で、1回やるだけでも結構効果はあったりします。
プロトタイプ実装をすると、既存のコードベース・問題領域・解決に際しての課題などについて圧倒的に解像度が上がります。
初めからコードを目視で見て調査した場合や、机上で設計をした場合よりもはるかに具体的な知見が得られます。
プロトタイプ実装を行った上で”行儀が良い”アプローチに戻ると、深い部分まで考慮された仕様・設計が考えれたりします。また、本実装するときにも最短経路を突っ走るコーディングができます。
PDDは既存コードが複雑だったり規模が大きいケースにおいて特に強力な効果を発揮します。
もちろんPDDは他の手法同様、全てのケースで通用する銀の弾丸ではないです。
ですがPDDを行うと、現状のコードベースや自身が考えている解決方法に対する解像度が非常に高くなるので、どう解決したらいいのかわからない問題に直面した時や、複雑なコードベースを触るときなどにオススメのやり方です。
