本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/08/kiss-with-you/

看到一个同事邮件里面提到的项目困扰，结合过去一个失败案例，写的一段文字供产品人员和程序员参考以应对项目复杂性。

keep it simple,stupid!

武侠小说里面，招式唯快不破，田伯光的快刀碰见令狐冲郁闷了，独孤九剑以无招胜有招。没有招式敌人再快也无用。

招式唯快就是性能至上主义，以前见过一些天书般的代码（代码足够长、足够复杂、足够你细细品味也看不懂），然后自我得到“极大的满足”，就算有“极好”的性能（好不好谁也不知道），出了bug或者升级的时候就抓狂了，自己都理不清楚了。

招式唯快就是功能至上主义，客户核心的需求就是那20%的功能，然后进入一个天花乱坠的页面，还有“强迫需求”，然后郁闷了，跑了。

简单是世间最美的事情，简单首先保证不会有错误，简单意味着更加易用以及易于维护。

有两条建议与大家分享：

第一条：keep it short，sweety.

过长的代码不容易理解（看了后面忘记前面），很多人说如果一个函数的行数超过70行，一个文件代码超过500行，这个函数，这个文件就太长了，怎么办？看第二条。

第二条：keep it separated,sweety.

过长的代码，把他们分开吧。

什么时候需要分离代码？有重复代码（重复是邪恶的）、一个函数超过70行、一个类有数十个成员函数或方法，把他们拆开吧。

什么地方需要分离代码？martin fowler的建议是如果你在程序里面有需要的注释的时候，就想想能不能拆开，用一个函数去取代。

分离的代码更好理解，想想你要看一个30行的程序，看到最后才知道是获取用户信息的操作，如果把这30行程序拆出来新建一个函数getUserInfo(),噢，整个世界都清净了。

分离的代码更好维护，因为分的足够细，哪个环节需要都可以做局部的修改而不至于影响整个系统。

对于产品，求你了，不要把我用不到东西呈现给我，我想用的时候我可以点开。