XPの反省-簡単で容易ではない
先週私たちのproductはreleaseの新しいversionを見たばかりです.change logを見ました.半分はfeatureを切って、configuration optionを切っています.
私たちはずっとXPで開発していますが、振り返ってみると、私たちのconfigurationは確かに面倒です.私の新しいバージョンのinstallation guideは元の10 pageから1 pageに縮小されました.達成感はあるが、最初はなぜそんなことをしたのか、時々反省しなければならない.
その原因にほかならない
１.今featureを切るのはcustomerの無知のためです(私たちは本当のcustomerではありません.proxy customerです.これは能力が自分をいじめている名詞です.私の別の議論自己欺瞞的proxy customerを見てください.
２.今configurationを切ったのはdeveloperがThe Simplest Thing That Could Possibly Workとは何かを誤解したからだ.
では、今から2についてお話ししましょう.当初はこのようなrequirementがありました.
Story 1: I want a module that can read all the property files in a particular location (file system). And return a Map. The Key will be the file name, and the value will the properties in the file.
開発者が手に入れた後、simple designですか.では、PropertyLoaderを設計しましょう.そこで次のclassがありました
このコードは簡単です.PropertyLoaderにはプロジェクトに必要なloadのconfiguration fileがあります.springを使ってconfiguration fileにextractを入れると、最後の結果はconfiguration propertyがあります.
filesToBeLoad=c:/config/config1.properties, c:/config/config2.properties,c:/config/config3.properties
intialテストでは問題はありません.私たちはせいぜい3~4個のfileがloadに行きます.開発者は簡単だと思い、customerも満足しています.結局deployになると問題が来た.ファイル名を間違える人がよくいます.大文字と小文字が敏感です(windows working,linux not working).また,業務量の増加に伴いloadを要するfileは10個を超えた.
このclassが最初に設計されたとき、auto loadを提案したことがあります.つまり、directoryをください.file systemを読みに行きます.しかし、codeを書く人はsimple designべきだと思っているので、そうしませんでした.
このエピソードを経て、簡単とは何かを反省しなければならない.簡単(The Simplest Thing That Could Possibly Work)は決してあなたのcodeが簡単であるだけでなく、全体的に構成、UI、使用も簡単である.コードの簡単さを追求するために配置の簡単さを犠牲にするのは望ましくない.私は10行のcodeを少なく書いたが、プロファイルが多くなって間違いやすい1行が多くなっても、だめだ.removeの余分な1行configurationのcostに行くのは、あなたが当初より少し「複雑化」した以下のあなたのcodeのcostよりずっと多い.
私たちはずっとXPで開発していますが、振り返ってみると、私たちのconfigurationは確かに面倒です.私の新しいバージョンのinstallation guideは元の10 pageから1 pageに縮小されました.達成感はあるが、最初はなぜそんなことをしたのか、時々反省しなければならない.
その原因にほかならない
１.今featureを切るのはcustomerの無知のためです(私たちは本当のcustomerではありません.proxy customerです.これは能力が自分をいじめている名詞です.私の別の議論自己欺瞞的proxy customerを見てください.
２.今configurationを切ったのはdeveloperがThe Simplest Thing That Could Possibly Workとは何かを誤解したからだ.
では、今から2についてお話ししましょう.当初はこのようなrequirementがありました.
Story 1: I want a module that can read all the property files in a particular location (file system). And return a Map
開発者が手に入れた後、simple designですか.では、PropertyLoaderを設計しましょう.そこで次のclassがありました
public Class PropertyLoader{
String[] files;
public Map<String, Properties> loadProperties(){
//....
// for each files, read the properties files content and put them to the map
// return ..
}
// setting injection the location of files
public void setPropertyFileLocations(String[] files){
...
}
}このコードは簡単です.PropertyLoaderにはプロジェクトに必要なloadのconfiguration fileがあります.springを使ってconfiguration fileにextractを入れると、最後の結果はconfiguration propertyがあります.
filesToBeLoad=c:/config/config1.properties, c:/config/config2.properties,c:/config/config3.properties
intialテストでは問題はありません.私たちはせいぜい3~4個のfileがloadに行きます.開発者は簡単だと思い、customerも満足しています.結局deployになると問題が来た.ファイル名を間違える人がよくいます.大文字と小文字が敏感です(windows working,linux not working).また,業務量の増加に伴いloadを要するfileは10個を超えた.
このclassが最初に設計されたとき、auto loadを提案したことがあります.つまり、directoryをください.file systemを読みに行きます.しかし、codeを書く人はsimple designべきだと思っているので、そうしませんでした.
このエピソードを経て、簡単とは何かを反省しなければならない.簡単(The Simplest Thing That Could Possibly Work)は決してあなたのcodeが簡単であるだけでなく、全体的に構成、UI、使用も簡単である.コードの簡単さを追求するために配置の簡単さを犠牲にするのは望ましくない.私は10行のcodeを少なく書いたが、プロファイルが多くなって間違いやすい1行が多くなっても、だめだ.removeの余分な1行configurationのcostに行くのは、あなたが当初より少し「複雑化」した以下のあなたのcodeのcostよりずっと多い.