今のやつを維持しつつ、新しいものを足していく。

よくある要望ですね。

「現在のシステムや内容を変更することなく、でも新しい機能を取り入れたい」

これは可能なのか？可能ではないのか？

それは初期実装にも、そのプロジェクトで利用されている各種の部品にも影響されるところです。

イケる

イケるパターン。
イケるパターンとしては、そもそも最初から「拡張」「変更」を意識した設計、製造方法、実装。
それらに耐えられるような部品やフレームワークを利用していることです。
これであればある日突然機能を追加となっても、まずはデータ保存先に多く使われるであろうDBのテーブルには、はたから見ると
「こんなに使わなそうなカラムがいっぱい無駄じゃないか」と言うのが
テーブルへの変更なくしてできます。
フレームワークは柔軟にできていてそもそも差し込みやすい機能実装になっている。
理想的ですね。

イケない

イケない。生きにくい…そんなパターン。
まず最初の製造段階からその後の拡張については一切考慮されていないもの。
行き当たりばったりに製造され、フレームワークさえも使っていないパターン。
そして、こりゃ無理だとなる大きな要因が
初期構想段階がきちんとまとまっておらず、後から後からの要望を最初の段階からどんどん足していき
所謂「カオス」な状態になっているとき。
これは、新しいことを取り込みたいが難しいことになります。
でも、多くのプロジェクトはこうなりがちです。

やばみ

プログラマーはフルマネージドサービスを利用し、プログラムだけ、製造だけに集中できます。それが利点です。
しかし、もしかしたらそれを前提にしていたのにも関わらず
ちゃぶ台返しを食らうこともあるかもしれません。
そう、フルマネージドサービス前提で作っていたプログラムをオンプレミス環境に結局作り直さないといけなくなった時です。

普通は、オンプレミスから…クラウドへの流れなんですが逆行するプロジェクトもあったりするのです。
そうなるとフルマネージドサービスの前提であるAPIやlibrary群は、使えません。
全部作り直しです。

そんな苦々しい思い出も今は昔です…