拡張性を大事にすることは環境の利用頻度にかかわります。
スクリプトをつくってくださいとお願いしたら、お願いした目的に沿っただけのスクリプトが出来上がる。
だけどそのスクリプトは汎用性に欠け、拡張も難しかった。
その場のコスト意識があれば、わりとよくあることかもしれません。
お金をかけずにやるなら、それだけのものしかできない。
後で修正も難しかった。
そうするとまた別の仕事を発注してスクリプトが出来上がる。
よく似たスクリプトが2つになりました。
繰り返すと100個のスクリプトになります。1000個にもなります。
管理工数はその分あがります。
スクリプトなんかは拡張性はかなり高くて、とくに定義しておかなくてもよさそうですが、
道を示しておくことにより、やってほしくないことをけん制することができると思います。
たとえば、芋づる式にスクリプトを引っ張ってくればセッション開始後の拡張は無限に近いです。
けど、これをやられると、制御がきかないですので。
こんなルールです。
・スクリプトはここと決めた場所においてください
・C#コードはこういうふうに書いてここと決めた場所においてください
・クラスを定義するときはこういうふうに書いてここと決めた場所においてください
してほしくない拡張のみちを閉ざすこと、規制することも必要です。
・公開コマンドを制御して設計者の望まない拡張をしづらくする
・ドットソーシングやコールを使ったりしたログをチェックする