功能与结构的关系

加入公司快一个半月了, 对这里的系统整体印象还是不错的: 首先”她”规模大, 应用多, 应用职责划分较明确, 应用间契约也比较清晰. 但是深入到各个应用的代码级就会发现很多的问题. 这些问题总结为一句话就是: 结构不太清晰. 我深知这个问题的产生是有很多原因的.

记得刚刚从师兄手里接管TBC开发的时候, TBC的结构很好. 但是由于当时对系统缺乏一个整体的把握, TBC在我手里经过两次较大变化后(由功能需求和性能需求驱动), 开始变得臃肿, 脆弱. 更可怕的是, 这种状况对我工作态度的影响----我开始惧怕变化. 这是我最不能容忍的! 于是我开始进行重构, 花了将近两天的时间让TBC具有合理的结构, 并且在以后的演进过程中, 保持其结构的合理性, 而不是保持其结构, 这点很重要. 这让我由惧怕变化转变为渴望变化. 因为每一次的变化都是对TBC适用性的一次提升, 对其结构的一次检验, 而且还有合理的结构所特有的----良好的可扩展性做支持, 使得做改变的体验很美妙.

总结起来, 结构不清晰的原因有三条:
1.    开发者对系统不了解, 时间紧.
比如我上面的例子. 可以使用重构的方式来弥补.
2.    开发者不具备一定的架构分析和设计的能力.
可以通过多种途径, 主动学习相关知识.
3.    开发者对结构不重视.
目前阶段公司业务发展过快, 用户量激增造成战略上更重视系统的功能及其性能, 而不是结构. 而且由于结构自身难以量化的特性, 也决定了管理层难以进行相应的考核, 进而无法推动开发者对结构方面给予足够的重视. 但是作为开发者如果对<<结构>>与<<功能, 性能>>之间的关系有深刻的体会, 这个问题就迎刃而解了.

<<结构>>与<<功能, 性能>>间的关系本质上讲, 就是形式和内容的辩证关系:
1.    内容决定形式, 有什么样的内容，就有什么样的形式.
软件有什么样的功能和性能, 就应该有什么样的结构, 可称其为合理的结构. 合理的结构不是只有一个, 是一个集合. 我们要做的是找到他们, 并且从中挑选出适合目前以及将来的系统演进的结构. 判断结构是否合理的原则很简单: 合理的结构一定是简单的, 朴素的. ----这是我的观点, 证明其正确性超出我能力范围. 简单性源于深入的分析, 清晰的思路以及丰富的经验. 正是这种简单性构成了软件结构的优雅.
2.    形式必须适合内容, 凡是适合内容的形式, 对内容的发展起积极的推动作用; 反之, 就起消极的阻碍作用.
很明显, 拥有合理结构的系统更容易被扩展, 被理解, 以及被改变----这个永恒的话题, 使其能够更快的响应功能和性能需求的变化. 合理的结构会让事情变得简单, 让开发者心情愉悦, 能够欣然的接受系统功能和性能变化的需求, 以达到”拥抱变化”的境界.

综上所诉, 作为开发者一定要时刻保持警惕, 当系统出现结构不合理时, 要在合适的时间及时的进行弥补. 同时要多多的学习结构设计方面的知识. 最重要是要知道”磨刀不费砍材功”, 要在思想上给予结构足够的重视.