dddquickly

在项目开发最初的时候，他也有过一段狂欢般的快乐时光，不久之后，事情就越来越艰难。

项目的代码越来越难以维护，工作越来越像是一种煎熬，合作的同事对他越来越不满。

“该是与这个项目，与这个公司说 bye bye 的时候了”，他想。他换了一家公司，涨了一点工资，开始了另一段狂欢。

周而复始，一年又一年过去了。随着年龄的增长，他不再能够从软件开发中享受到乐趣，软件开发的职业生涯，对于他而言痛苦多于快乐。

学习新的技术，他也比不上年轻人。运气好的话，他可以完全脱离开发，转去做管理、做产品设计、做业务，运气不好的话，

他只得继续做开发，因为毕竟还要养家糊 口。“继续混着呗”，他悲观地想。他从一家公司换到另一家公司，从一次失败，走向 另一次失败，他始终都是一个loser。

在笔者所在的公司里面，有一个很重要的项目，最初的架构师(不止一个人)在错 误的架构设计风潮的影响下，决意把这个项目设计成一个全分布式的系统。

他们设计了 十几个分布式服务，相互之间通过 WebService 通信。他们还引入了一个开源的 ESB (企业服务总线)中间件——Mule。项目开发的鼎盛时期，

曾经有二十几个开发人员， 每个人负责开发不同的分布式服务。因为架构师对这些程序员缺乏必要的指导和控制， 不再关心最初画的那些架构图，

他们开始自行其事，只求尽快完成手头的工作早点下班。应该提前做一些压力测试!项目的开发人员，离职的越来越多，也包括最初的架构师，

每个程序员只熟悉自己负责的一小块工作，相互之间缺乏沟通和协作。这个项目的概念 完整性很快就遭到了破坏，架构师所画的架构图，在代码实现中消失了。

程序员很快就 十几个分布式服务所导致的大量远程调用给系统的性能和可伸缩性带来了巨大损失，每 一个远程调用都有可能出错，全部可能出现的异常情况难以计数，

极大增加了异常处理 的开发和测试工作量。同时给配管、运维人员的发布工作也带来了巨大的困难，每一次 的上线发布都像是一次艰难的战役。Mule 这个中间件，

并不适用于大流量互联网应用 的环境，其性能和可伸缩性有很大的问题。最初引入 Mule 时，架构师甚至都没有想到 最后只剩下了 4 个人。这么少的人很难维护十几个分布式服务，

架构师只好决定将 Mule 完全废弃掉，将十几个分布式服务合并为三个相对独立的集中式应用，将远程调用改为 了本地方法调用。这样做起码配管、运维人员的工作能够大幅减少。

然而，这种合并仅 仅是把代码简单地合在一起，原先因为存在十几个分布式应用，程序员自行其事，所导 致概念完整性遭受的破坏，仍然完全没有解决，因此这个项目的代码仍然难以维护。

这 真是一个 design by buzzword 的典型案例，软件开发的很多反模式都可以在这个项目 中找到。这个项目的开发人员流动性很大，一个重要原因是他们无法从这个项目中获得 开发的乐趣。

--摘自 dddquickly