过度工程

过度工程，最初我知道这个词是在Rod Johnson的《J2EE Development without EJB》，随着阅历地增长，渐渐发现书中熟悉的场景也在身边再现了。

 

敏捷、还有设计模式，给一个团队带来了什么？

我之所以把这两个词放在一起讲，是因为我要说一件显而易见的事情，可是这样一件事情很多人又不愿承认。

团队，是有风格个性的；团队，也是有能力强弱的。不管你承认不承认，整体来说，我们都还不是精英团队，因此相对于某些公司成功的案例来说，我们有很多事是不适合做的。

敏捷强调了主动性，强调了沟通，事实上并不是身边所有的团队都能做好敏捷管理的，譬如一支过于年轻化的团队、一支基本由外包人员构成的团队，甚至一支连转SDV版本都要熬一个通宵的团队，我认为是不适合实施敏捷流程的，至少，大部分所谓的敏捷实践，都是走样的。

关于设计模式，我要说什么？

我可以在板书上用Java和C++写出GoF 23种设计模式中的每个例子，也学习过J2EE Core Pattern，可即便这样，我依然在实际的软件开发中的某些情况下，避免使用它们。因为即便一个设计再过精巧，它依然是要和团队的风格和接受能力想匹配的，我们都是工程商人，公司也不以追求完美的代码为己任，需要的是一个一个项目坚实地交付，可以踏踏实实地赚到钱。

我觉得，“某一些精巧的设计，恰恰是以降低代码的可维护性为代价的”，当然这一句话在不同的团队场景中是不尽相同的。举例来说，一些回调方法、闭包的使用，还有庞大的职责链，都给代码的识别和单步调试带来困难。成熟的开发者，能够克服总想要引入新技术的冲动，并且不会在项目中去写只有少数人才能理解的奥义代码。

我相信会有很多人不认可我的观点，不过我相信并不一定要谁说服谁，有不同的想法经常是好事。

 

分布式对象，我们遇到了什么问题？

为什么使用分布式对象？看起来根本似乎是因为整个解决方案过于庞大了，软件工程中一切不好解决的问题都是由问题复杂引起的。分布式对象在SOA架构中有着不可替代的作用，也许遗憾的是我并不在这里强调问题的严重性，然后“啪”扔出一个传说中的最佳解决之道。

不过开发人员天生的本事就是善于抱怨，分布式对象确确实实带来了许许多多的麻烦，最典型的“阻抗不匹配”，是说无论是人力成本还是性能成本，都把精力耗费在传输对象和领域对象之间的数据交换，甚至数据同步上面。

我还记得Martin Fowlor提到：“分布式对象的第一条准则：不要使用分布式对象”。

举一个产品的例子，我们所有的产品处理逻辑全部都要通过SOAP接口中调用别的部件来实现，本地是没有持久化了的产品对象的，随着这一堆的接口愈加复杂和庞大，许许多多开发人员都希望有一天产品能够同步到本地来，落到存储中，一些流程上的接口性能问题就迎刃而解了，而这些问题，都是自己给自己造的绊脚石。

 

是否有过度的架构和过多的框架代码：

架构的价值在于为常见的问题找到好的解决方案，而不是一心想要解决更复杂也更罕见的问题。

这里遇到一个矛盾，产品的发展过程中，系统架构确实是在不断调整的，这些事情现在就是由开发人员完成的。问题是这过程中，到底应该分析到怎样的粒度？

问题不是分解得越细致、考虑得越多越好。在细节上挣扎得越久，就越难以设计出简洁和清晰的方案来。复杂，是软件的唯一天敌。可是简单的设计，又会令人不住地担心，是否会带来不易解决的问题。

这是一个不可调和的矛盾。其中一个好的办法是做纵向切面，设计一个系统架构时，做一个合适位置的纵向切面，能发现一些潜在的问题，作为可行性分析的重要依据。最典型的例子是性能问题，这些问题到了项目中后期很容易就能将一个工程陷入挣扎的境地。

框架代码是没有净生产力代码的一种。产品的代码，就像一只羽翼丰满的鸟，当这只鸟儿的骨架过于庞大，便难以飞远、飞高。简单的框架代码，意味着较高的可理解性，整个工程对新员工来说，是清晰的，易于业务技能的传递。

 

糟糕的可选性功能：

我们经常听到这样的对话：

——请确认这个功能需要实现吗？

——这个功能目前需要实现，但必须考虑到未来xxx的情形，保持灵活性，请做成配置项：1表示开启；0表示关闭。

于是，我们就有了漫山遍野的配置项。

我认为，这是最糟糕的回答了。我们不是在做一个刚好交付的产品，而是在做一个超级“灵活”的变形金刚，代码里面布满了配置项判断逻辑。

 

又是框架、又是平台……

框架、平台，这是很多学习J2EE的朋友最害怕听到的两个词语。身边似乎有无数这样的东西，产品能不能简单一些？使用硕大的框架和平台确实能够具备一些便利的功能……可是，我真的需要那么多吗？

开始理解代码了，有数种不同格式的模板、不同类型的标签，甚至连会话，都经常需要操作多种类型的会话获取接口。一个问题出现，我们从一个模块定位到另一个模块，从一个抽象层定位到另一个抽象层，最后吐血地发现，不是我们的代码问题，是框架或者平台的问题……

另一个同类产品Dev Portal，就开始尝试采用简洁的框架来实现，也不打算搬迁到什么复杂的平台上了。框架和平台的使用，一定要评估好必要性和影响，能简化的实现就不要作茧自缚，软件的本身，WEB应用的本身，是否就该追求简单的美？