実際のところ、十分に満足のいく状態でのリリースなんて（少なくとも最初のうちは）難しくて、リソースが足りないのが常ですよね。
パーキンソンの法則曰く、「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」、だそうな。覚えのあるエンジニア（や、それ以外の職種の方も？）多いのではないかと思います。
最悪の失敗例は、細部にこだわりすぎた結果全体スケジュールに間に合わないことや、優先されるべきことを後回しにして後に響く問題を残してしまうことです。
なので、与えられたリソースの中で優先度を決めてやることになります。
このとき削減されるのは、機能単位だけでなく、実装の質だったりもします。
実装レベルでの取捨選択の際に重要な発想、それが「リファクタリング可能性」です。要は、後々のリファクタリングがどれだけ可能か、容易かを意識すべきだということです。
具体的方法論について。
1. 優先度
これは単純で、インターフェースの方が実装より優先度が高いです。
例えばあるクラスにおいて、インターフェースは、他のクラスから依存されるため、後から安易に変更できません。一方で、その内部のソースコードの可読性やパフォーマンスは、優先度を下げられます。メソッド単位・API単位など様々な粒度において、同様のことが言えます。
2. テストコード
リファクタリングと言えばテスト。ただ現時点でテストが十分に実装されている必要はなく、リファクタリング時点でテストコードを書くのも可です。ただ、テストを書くことを前提にして設計しておく必要があります。
3. コメント
これは単純ながら非常に重要です。
// TODO: ソースの整理
// TODO: パフォーマンス改善のため、bulk insertに書き直す
とか書いておくだけでも、後々の見通しが全然変わります。実装した人が、そのコードの課題について一番よくわかっている場合が多いです。
逆説的に、リファクタリング可能性を十分に考えている場合において、優先度の低い実装は後回しにしてしまうべきなのです。
優先度決めが肝なのと、しかし後での修正のことをしっかり考え、現時点でできることはやっておきましょう、という話でした。
