Never Ending

Golive不出意料的被推迟，总算有了点喘气的时间。

忙里也有偷闲的时候，看了几篇Mr.V推荐的文章。

其中一篇是关于MULE的CTO关于如何选择ESB的文章。文章里有一句话提到，那些滥用ESB的架构师和开发人员都是“简历驱动开发”（Resume-driven development）。他们使用ESB大多是为了面对下一次面试的时候，当面试官问“用没有过ESB”的时候能回答一个“yes”。

事实上，简历驱动开发（RDD）已经不是一个新鲜单词了。《架构师应该知道的97件事》里面，第一条就是“不要把简历看得比需求重要”。

在做设计的时候，我们不可避免的要去做技术方面的选择，从众多技术门类、流派甚至工具种类中组合出解决现实问题的合适方案。这时候，大多数人都会陷入这个误区：有意无意的自我中心，以自己的经验或者感觉给出一个解决方案。而这种解决方案的根源不过是为了突出自己简历上的亮点或者想给自己的简历再加上辉煌的一笔。更有甚者，因为懒于分析，而直接给出一个自己认为百试不爽的架构。

也许这样能得到一个能用还可能是好用的架构。但我们不能总是寄希望于“可能”和百分比。需求分析缺失的架构，总有人会为它买单。当客户的需求变得超出架构师的想象以后，团队如何面对推倒重来。

其实我也是一个“简历驱动开发”的人。我也盲目的为了那些高热度的技术名词把一些东西拉到项目里来。当时没有在需求方面进行太多考虑，只是关心这个东西的适用范围怎么样，延展性怎么样，支持怎么样。后来证明我是比较幸运的，功能性需求的发展没有超出我当初的预想。而且这个项目也迅速结束了。当时的团队也躲开了那好无止境的维护黑洞。

但我也听同事交流另一个项目的故事：那个项目里基本上把入时的那些技术都用上了，甚至模块之间都要用ESB通信。设计的时候来看，构思不可谓不精妙。但到了交付的时候，以性能为中心的各种各样的问题层出不穷。而在修正的时候发现整个系统牵一发而动全身，极其痛苦，改一个小bug都感觉难以入手。

我不想说当时的设计者是RDD，但是他们至少没有保证需求挖掘的深度与技术保证能力的并行。过多的估计需求，与新加技术的滥用，导致了最后的盘根错节。

一年半以前，我加入现在这个项目的第一个任务给我很好的上了一课：客户的一个系统内有很多load balanced的登录用的服务器，我们的任务是捕捉用户的登录信息然后分发给其他系统。我当时也是一个ESB/SOA这些“Service”概念的狂热者，我的主张是一个消息队列接受登录服务器的登录消息，然后再分发给消息的subscriber。我认为这个方案很自然。但这个消息提交给客户以后客户给予断然否决，第一，他们不能随随便便的给他们的内部网络里添加一个消息服务器；第二，谁给他们出消息服务器的钱，开源的谁来维护。

最终的方案很简单，写一个插件，捕获用户登录的事件，然后去touch一下客户的profile文件；用cron job去调用cpio命令通过ssh将所有文件同步到一台机器上；最后随随便便写个什么程序将这些文件携带的信息推出去。整个解决方案实现完，只用了一个配置文件保存各个服务器的信息，和不到100行代码实现各环节的调用。

不需要安装任何软件，不需要调整现在的任何程序，只是把我们的东西加到现有系统上。性能也很高，因为操作系统和现在服务器代替我们去操作文件和信息。客户很满意，我们也很满意，不到100行的代码，我们看起来也很舒服。扩展性？用户过去没有提扩展需求，而且现在也没有提。就算以后真的需要扩展，就算丢掉这100行不到的代码重新设计也不可惜。

在刚进公司的时候，和Mr.V聊天时就谈到，不要相信专家。换言之，不要过分依赖经验，更多的要依赖与你的自觉与理性。

我曾经认为自己应深谙开发之道，我把计算机程序归纳为数据获取、数据处理与数据转移三部分。而且我坚信我能找到一个统一的解决方案让三者自然的结合起来，而我们只需要关注于业务，不用纠缠于技术细节。我做了很多努力，并把我的想法和很多架构师和面试官进行交流。最后我兴致勃勃地将这个想法告诉我女朋友时，我女朋友蔑视地说“你个过时的本质论者”。

这句话让我从过分的自负中解脱出来，接受了一些“敏捷”的设计原则：

1. 只关注用户提出的需求，并且去挖掘，而不要去臆测。如果有些东西不明确的话，就问一句“谁为这个功能付钱”。

2. 设计的方案应该是满足需求的最小技术集合。一个小的系统更容易拆分和进化。

3. 尽力保持现有系统的稳定性。谨慎但不保守的面对扩展。

4. Retrospective meeting的时候，系统技术架构也是需要review的。要搞清楚现在系统里的哪些东西还能给我们带来便利，而哪些我们在拼命的回避它的缺陷。保持一个有活力的不断演进的技术设计。

一个Magic word：Balance。无论做什么，其实都是平衡的艺术。平衡用户嘴里“一定”和“可能”的需求；平衡功能实现和开发消耗；平衡个人兴趣和项目选择，等等。但平衡不是中庸，平衡的目标是娱己娱人。

一句话：just enough is enough。够用就够了，有谁愿意为了你那些精妙的点子付钱或者买单呢。

另外，其实很多时候我都在回避“架构设计”这个名词。人总是一种过于高估自己的动物。当我们讨论架构设计的时候好象是颇具大将风范的指点江山，但面对问题却很难大义凛然，心中常有戚戚。其实engineer就是一个engineer，冷静地做好自己工作，不要头脑发热的去拍胸脯就可以了.

再拉回个人兴趣和项目抉择上来。作为一个技术人员，保持对技术的热衷和对技术走向的敏感是非常重要的。但直接把自己感兴趣的东西加到项目里是非常危险的。摸着石头过河需要更大的勇气和控制能力。所以对一些技术感兴趣的时候就要积极参与到它的社区中去，并积极线下实践，和别人积极交流best practice。对一个公司而言，一些internal的项目也可以作为这些技术的试验田。自己为这些东西买单是相当有价值的。