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

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

既存のA,B,C最適の実装に対して、歪なif文を生やして「Dは緊急対応！」とはしない

歪なifとして扱うのは(悪い意味で)考えることが少ないので楽だがそうしない

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

後に、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であることや、疎結合であることや、良い抽象化が為されていることがが効いてくる

「疎結合」みたいな話って、プログラミング入門して1年以内に1度は触れることがあるぐらいに有名な話題だけど、やっとそれを1周回って自分で到達する手前までこれている気がする

手前というか、

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

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

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

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

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

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

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

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

新機能追加する際に、画面に1つ要素を増やせばokというわけではない

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

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

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

これを防ぐためにも、タスクを寝かすのが大事

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

他の人の書いた実装に対して新たな要件が見つかるたびに0から構成し直すのはさらに難易度が高いだろう

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

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

その方針の決定もcode reviewerの役割とも言えるかもしれない

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

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

さてこれは、請負等の場合はどの程度予算として取って良いんだろうね

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

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

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

そのためには、

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

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

Dも追加する

という風に時間もかかる

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

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

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

面倒なら「Dの追加ムズいねん」と説明する

説明の仕方にもよりそう

この2つを比べている

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

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

これが一致してるのが理想だとは考えている

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

ただ時間が経つほど変更が難しくなる可能性はある

寧ろ、ここが最も争点だろうな