庄周梦蝶

    入这行也有四年了，从过去对软件开发的懵懂状态，到现在可以算是有一个初步认识的过程，期间也参与了不少项目，从一开始单纯的编码，到现在可以部分地参与一些设计方案的讨论，慢慢对设计方案的评判标准有一点感受。读软件工程、架构设计、模式之类的书，对于书中强调的一些标准和原则的感受只是感官浅层的印象，你可以一股脑从嘴里蹦出一堆词，什么开闭原则、依赖倒转、针对接口编程、系统的可伸缩性、可维护性、可重用等等，也仅仅停留在知道的份子上。不过现在，我对一个设计方案的评价标准慢慢变的很明确：简单、符合当前和一定预期时间内的需求、可靠、直观（或者说透明）。
   简单，不是简陋，这是废话了。但是要做到简单，却是绝不简单，简单跟第四点直观有直接的关系，简单的设计就是一个直观的设计，可以让你一眼看得清的设计方案，也就是透明。一个最简单的评判方法，你可以讲这个方案讲给一个局外人听，如果能在短时间内让人理解的，那么这个方案八成是靠谱的。记的有本书上讲过类似的方法，你有一个方案，那就拿起电话打给一个无关的人员，如果你能在电话里说清楚，就表示这个方案相当靠谱，如果不能，那么这个方案很可能是过度复杂，过度设计了。
   简单的设计，往往最后得出的结果是一个可靠性非常高的系统。这很容易理解，一个复杂的设计方案，有很多方面会导致最后的实现会更复杂：首先是沟通上的困难，一个复杂的方案是很难在短时间内在团队内部沟通清楚，每个开发人员对这个方案的理解可能有偏差；其次，复杂的方案往往非常考验设计人员和开发人员的经验、能力和细致程度，复杂的方案要考量的方面肯定比简单方案多得多，一个地方没有考虑到或者不全面，结果就是一个充满了隐患的系统，时不时地蹦出一个BUG来恶心你，这并非开发人员的能力问题，而是人脑天然的局限性（天才除外，咳咳）。
   第二点，符合当前和一定预期时间内的需求。我们都知道，不变的变化本身，指望一个方案永久解决所有问题是乌托邦的梦想。复杂方案的出炉通常都是因为设计人员过度考量了未来系统的需求和变化，我们的系统以后要达到10倍的吞吐量，我们的系统以后要有几十万的节点等等。当然，首先要肯定的是对未来需求的考量是必需的，一个系统如果实现出来只能应付短时间的需求，那肯定是不能接受的。但是我们要警惕的是过度考量导致的过度复杂的设计方案，这还有可能是设计人员“炫技”的欲望隐藏在里头。这里面有一个权衡的问题，比如这里有两个方案：一个是两三年内绝对实用的方案，简单并且可靠直观，未来的改进余地也不错；另一个方案是可以承载当前的几十倍流量的方案，方案看起来很优雅，很时尚，实现起来也相对复杂。如何选择？如果这个系统是我们当前就要使用的，并且是关键系统，那么我绝对会选择前一个方案，在预期时间内去改进这个方案，因为对于关键系统，简单和可靠是性命攸关的。况且，我坚定地认为一个复杂的设计方案中绝对隐藏着一个简单的设计，这就像一个复杂的数学证明，通常都可以用更直观更简单的方式重新证明（题外话，费尔马大定理的证明是极其复杂的，现在还有很多人坚信有一个直观简单的证明存在，也就是那个费尔马没有写下的证明）。最近我们的一个方案讨论也证明了这一点，一个消息优先级的方案，一开始的设想是相对复杂的，需要在存储结构和调度上动手脚，后来集思广益，最后定下的方案非常类似linux的进程调度策略，通过分级queue和时间片轮询的方式完美解决了优先级的问题。这让我想起了软件开发的“隐喻”的力量，很多东西都是相通相似的。
   上面这些乱弹都是自己在最近碰到的一些讨论和系统故障想起的，想想还是有必要写下来做个记录。