新たな要件が見つかるたびに0から構成し直す

例えば、現状見えていた要件がA,B,Cの3点だった場合、この3点をカバーできる最適な実装をする

その後、新たな課題Dが見つかった時、A,B,C,Dの4点をカバーするような構造で実装し直す

短期的には速いが構造を歪にするので長期的には遅くなる

後に、A,B,C,D全てを知っている人がコードを見ると間違った抽象化に感じる

そういう意味で、可読性が低くなる

実装と開発者のメンタルモデルがズレる

このアプローチを取って修正するためには当然難易度は上がる

A,B,C最適の実装がどういうものなのかを深く理解する必要がある

規模が大きいとそもそもA,B,Cの3つが関連していることを把握することすら難しいかもしれない

本当にA,B,CとDを一緒に解決すべきなのかの判断をし、

A,B,C,Dを抽象する構造を発見し、

それを実装に落とし込まないといけない

もしかしたら、A,B,Cを纏めていたのが誤りで、A,BとC,Dの組で抽象した方が良い、とそこで気付くかもしれない

そもそもA,B,C最適の実装が、筋良く実装されていると、自然にDの追加ができる

Dを生やしたものと、0から考え直したものが一致する

あるいは変更が必要になったとしても、最小限の修正で済む

A,B,Cの実装の時点で、良い抽象化を目指したり、ある程度未来を予測したりしておく

ここでもやはり、modularであることや、疎結合であることや、良い抽象化が為されていることがが効いてくる

手前というか、

向こうの方にぼんやり見えてきた感じ

あー、色んな面を考慮して良いものを目指した先にはちゃんとそれがあるんだぁ、というのを改めて感じる

同様に、Dを生やしたときにも、将来のEの追加に備えておく

0から構成し直す、というゴールへの経路はいくつか存在するだろう

気合でえいあ！と全てを一気に直す方法もあれば、

順々に移行できるような筋道を設計し、それに沿って進めていくやり方もある

対象の複雑さや影響度合いや工数を鑑みて判断する

上述のことは主にコードに対して書いていたが、これはUIに対しても同様に言える

それを繰り返していくと画面がゴチャゴチャしていく

ただし、ユーザに露出している分、0から変えた変更が大きすぎるとユーザ混乱する恐れがある

大きなUI変更はぽんぽんできない

コードレビューをしていると、そういう修正方針が人によって異なるのが見えてくる

コードと仕様に対して、ちゃんと理解していないとできない

他の人が書いたA,B,Cを満たすコードを、Dを想定していたものなのかを読み取る必要がある

全体が見えている人が、レビュイーに見落としている箇所を教えてあげる

人が介在せずに、誰でも自然にそれが読み取れるような構成になっている方がもちろん良い

時間だけで見るなら、表面にぴょっとDを付けるのが最速

これで顧客の要件は満たせているわけである

一方で、将来のメンテコスト等を考えると、ABCDを再度構造化する方が良さそうと感じたとする

そのためには、

どういう構造にするのが良いかを考え、

それで再設計して実装し直し、

Dも追加する

という風に時間もかかる

(Dを使える状態にしたあとで構造化し直して納品、というフローにもできる)

顧客からすると、「いやそれやる意味あるんか？？」という気持ちになりうる

誠実に対応するなら、そういう背景を説明するのが良さそうだが、

面倒なら「Dの追加ムズいねん」と言ってがっぽるしかないのか

説明の仕方にもよりそう

この2つを比べている

本来、0から開発する際にA~Dまで見えていたら出せていたもの

A~Cがある状態で、Dを追加したもの

しかし、これは結局どこかのタイミングで支払う必要のあるコストなので別にいいっちゃいい