上周我们的product刚刚release了一个新的version.看了change log.大概有一半都是砍feature,砍configuration option.
我们一直都是用XP开发,但是回过头来,我们的configuration的确太麻烦。我的新版本的installation guide从原来的10 page缩减成1 page。虽然颇有成就感,但是不时地要反省一下 一开始我们为什么要那么做。
归其原因不外乎
1。现在砍feature是因为customer的无知(我们不是真的customer, 是proxy customer 这个东西本事就是个自欺欺人的名词 更多的可看我的另一篇讨论 自欺欺人的proxy customer )
2。现在砍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<String, Properties>. The Key will be the file name, and the value will the properties in the file.
developer拿到之后,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 有一个setter 可以inject所需要load的configuration file. 如果我们用spring 这可以extract到一个configuration file里面,最后的结果是我们有一个configuration property
filesToBeLoad=c:/config/config1.properties, c:/config/config2.properties,c:/config/config3.properties
在intial 测试中都没有什么问题,我们顶多也就是有3-4个file要去load。 developer觉得简单,customer也满意。结果一旦deploy, 问题来了,1. 经常有人拼错文件名, 2. 大小写敏感(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, 使用 都要简单。 为了追求code简单而去牺牲配置的简单是不可取的。我虽然少写了10行code, 而配置文件多了容易出错的1行, 都是要不得的,去remove那多余的一行configuration的cost 要比你当初多稍微的“复杂化”以下你的code的cost多很多。