软件中的模式

夜深了，也静了。这是近些天来唯一一次晚上没什么事且过了零点还能抬起眼皮的一个夜晚。最近在忙着设计新项目的一些关键点的架构，还忙着做一个性能优先的内存缓存的原型。自己给自己揽了一堆活，而且还有PL和外派同事（被PL任命为这个项目的负责人）给我的若干任务。时间很紧，不少的纯体力工作，同时也感觉到了一些压力。不过，好在那个内存缓存还是让我比较兴奋，毕竟多少可以做点儿高级点的东西了。来这里已经三个半月了，基本上已经适应了，包括工作节奏和职位职务。近期也不想再理会别的工作机会了，还是集中精力把手头的项目做好。这里的PL和Manager还是不错的，使我工作得比较愉快。

好了，介入正题，又说了很多题外话，但愿屏幕前的那位还没关掉页面。
其实，软件模式这个概念很广。从纯技术方面来讲，有实现模式、设计模式和架构模式等等；从管理角度来说，有开发模式、过程模式以及交付模式等等。这里主要还是探讨技术层面上的模式，管理模式也会稍微带一点，毕竟我在团队管理方面的经验还不是很多。

先说说实现模式。所谓实现模式，就是我们在编程过程中的一些习惯和较好的实现方式。这种模式或多或少的会体现在团队的一些编码规范中。实现模式比较注重细节，它的核心思想是符合良好的编码习惯和较佳的实现规范。目的是，使得团队中的代码风格开起来整齐划一。这有五点好处：一、使得团队成员能够很容易的阅读另一位成员的代码，成员之间很容易进行交叉测试，Leader很容易review代码；二、在后期维护时会领会原有代码的意图，并可以很容易的继续遵循一贯的代码风格加以修改和重构，使得代码甚至软件的风格不受影响；三、可以让新进入的开发者了解团队编码风格并快速融入；四、可以使团队开上去更专业，而不是一群无组织无纪律的散兵。最后，有了这么一套带有良好实现模式的编码规范，就可以是团队在最基本的技术层面上达成一致，可以大大地提高工作效率，避免了无谓的争论。良好的或者趋向良好的团队都应该有自己的编码规范，在书写编码规范时应注意因地制宜的吸收一些参考资料中的公认条款，而且可以根据具体情况加入一些团队内部需要都知晓的原则。比如，我这次在撰写编码规范的时候就加入了很多关于OO的原则和实践方法，以供开发人员参考。

下面来说说设计模式。希望提高自身技能的软件开发人员都会主动地去接触设计模式，因为那是N多前辈们总结出的软件设计的最佳实践参考。我相信真正的高级开发人员都至少读过一本关于设计模式的书。当然软件是善变的，设计模式也是如此。在真正理解和熟练运用设计模式之后，就可以根据自己的需要将原有模式进行演变，甚至创造出更好或更适合当时业务的模式来。设计是灵活的，设计模式只能最佳实践参考。所以，我在这里不想过多地说怎样去用模式去设计软件。因为设计是业务的跟随者，是特定业务的技术级支持。没有了业务依托的代码，最多也只能算是个demo程序而已。现在越多越多的软件和框架的目标都在向更好地实现特定业务转移。这是一个趋势，也是人们对软件设计的观念的进步。计算机是服务于人的，软件理所当然也是。所以在学习设计模式的时候大家不要恪守陈规，要学会为了目的而设计，而不是为了设计而设计。软件是有生命的，至少我坚信这一点。既然有生命就需要成长，从呱呱落地到成熟稳健是需要有一个过程的。所以，不要在一开始就试图去想象软件以后会怎么变。因为在软件行当里，盲目的想象往往都不会成为现实。因而，与其费劲脑汁去过度设计，还不如集中精力优化现有的代码。然后再根据需求的变化而动，只作足够的，不做多余的。

架构模式是更高级的话题。我主要说说我从事WEB系统的架构。现有流行框架，比如：Struts2、Spring和Hibernate，都建议开发人员们把WEB系统的架构很为三层是这样理解的：一、使软件的职责分明，比如，展示层主要负责数据的页面展示和用户输入的收集；持久层服务与数据存储介质打交道，负责数据的保存于重用；而控制层负责业务流程的控制、为展示层提供细粒度服务功能、对持久层进行合理调度等等，起到了承上启下的作用；二、各层接口使软件能够以松耦合状态呈现，能够最小化改动带来的影响；三、分层结构使得业务流程清晰，有助于非创建者对软件的理解，有助于其快速了解软件的运行机理。至于其他形式的软件系统，比如：应用程序和C/S软件，最终的架构目的都是为了“高内聚、松耦合”，从而使软件各部件分工明确并能灵活应对变化。架构模式问题很高级，也很繁杂，暂且就说到这里。

再说管理方面的模式，主要说说团队管理。一个的团队的总体水平，往往不是体现在团队成员的技术水平上，而是体现在团队的整体运作上。一个差的团队，往往会计划混乱、做事颠倒，经常加班但还是会拖延交付；而一个运作良好的团队，往往会计划先于执行、措施先于变化，时不常的开会但是照样能漂亮的按时交付。这取决于什么呢、高效的开发方法；二、细致的过程控制和管理；三、有效的沟通。当今的开发方法公认优秀的有几种，包括：RUP、Scrum等等，其实都是在上述那三点上做文章，都是要高速迭代、持续集成，并与客户保持高质量的沟通。但是，RUP更注重规避各种潜在风险，而Scrum更明确了去除杂念、按需而动。管理是一门太深的学问，团队管理亦是如此，人的因素占很大的比重。因此，软件管理模式比技术模式要善变得多，也更容易失控。因而需要花费更多精力去把持。

好了，现在是将近凌晨三点，说的也不少了，眼皮也开始打架了。真诚希望能与各位同仁多多交流，互相取长补短，共同进步。希望大家能够积极回帖，咱们一起讨论“软件中的模式”的机理和实践。谢谢大家能够看到最后。