架构设计有感

架构是一个很直觉化的概念，理解的反差会让设计变得大相径庭。架构设计者（不一定是架构师）对系统的把握、认知和控制力会极大的影响系统开发的走势。需求分析，功能分拆，技术选型，人员控制，规模、进度和质量控制等都是架构设计者的任务，稳定安全，高效、可扩展、可维护、优秀的用户体验是架构设计的基本目标。不过架构设计一直有一个误区：只有在谈到大型项目的时候，才会想到架构，好像数据不够海量、访问不到千万就不好意思谈架构一样。

项目的规模同样是一种直觉上的概念，有的系统功能繁杂，枝节盘绕，但深度不够，中心不定，往往点到即止；但有些系统功能单一，但深度挖掘，中心明确，有很强的辐射性，像twitter、facebook等。其实可以说他们的复杂度是不分彼此的，再加上人员配置的差别，系统的规模也会有所差别。同一个系统，对一个经验丰富的高手和两个生涩的新手，规模可以有完全不同的解释。

这篇文章只讲一些中小规模项目的架构设计。

一、系统需求分析。

这一步至关重要，是整个系统开始的入口，需求把握的准确性、精细度都直接影响其后的所 有步骤。

• 沟通，方法和重要性不必多说，但要注意引导用户的需求，而不是一味应承和满足用户需求。尤其是对那些明显的不合理的流程和细节效果，对于系统实现方式，用户毕竟是外行。
• 需求分析的分析。这点很多人不太在意，但却是很重要的一步。进一步的分析不仅会发现许多隐性需求，而且会有更深的全局观念。

二、评估系统规模、系统拆解、技术选型、人员配置

作为一个中小型的项目，明确需求以后，评估系统、系统拆解、技术选型、人员配置要同时进行，他们之间相互作用，互为补充，同时进行更容易把握。

• 评估系统。根据需求评估系统需要的规模、时间、人力、物力。
• 系统拆解。这点我不太建议将系统拆解到元件级别，确定需要的模块即可。过于精确的元件会影响开发者的思路和具体实现。
• 技术选型和人员配置。这两者既要看系统需求，又要明确人员的技术类型和能力。比如系统开发可能的困难度，例如：系统中有数据量特别大的处理模块或用户体验很高的模块就需要有有经验、能力或某项技能突出的开发人员、设计师参与，抑或使用更高效的实现技术。反之可使用的开发人员的技术类型和素质也会影响甚至决定你的技术选型。
• 关于技术选型的问题。技术选型包括实现语言选择（如java）、系统组织模式（如mvc）、基本设计模式（如factory）、设计方法论（如面向对象），几乎每个公司都有自己的比较成熟的开发模式，它们或自主设计、或基于成熟框架开发，通常新系统都会沿用旧系统的一套东西，以便于系统维护。但作为设计者不可拘泥于此，要随时收集原有系统的漏洞，及时修补，而且要审时度势，认真把握系统将来可能出现的问题，比如旧系统使用php4开发，那么新系统就不要为了适应旧系统继续沿用php4，因为它已不能适应php的未来了。再比如，java、c#、ruby、php都有自己优秀的开发组件和框架，假如以前的系统都使用框架开发，那么你就要实时、严肃的评估该框架的发展前景、开发团队以及社区活动，一旦框架无人维护或出现大幅变动，对将来系统的维护都是十分不利的（或许将来你难以找到熟悉此时版本框架的员工）。
  注：框架要为系统服务，切不可先入为主，让系统来强硬适应框架。同时要避免框架的叠加，就是框架上的框架。

三、实施与控制

这是系统成型的阶段。这里主要说控制，控制力对整个系统的把握和走向极其重要，不光要控制系统的质量、周期，还要控制人员、资金变动带来的骤然不适应性。

四、测试与修复

可以说这是系统的攻坚阶段。即将接近尾声，问题会随着全面测试的展开逐一显现。测试对于国内大部分的中小项目来说非常不重视，没有专门的测试系统和测试人员，甚至连服务器压力测试、环境测试都没有，有的甚至于页面兼容性测试也给省了。结果就是，没问题皆大欢喜，有问题就会发现问题层出不穷，反复测试也无穷尽。其实一个测试系统并不尽复杂，只要按照按部就班、完整合理的测试方案认真执行，大部分的问题都是可以及早得到发现和解决的。

五、完成与维护

产品交付与维护方案。

——————————

文章可能显得零散而不成体系，比较简略，点到即止。有时间可能会整理一份完整的设计心得。

转载请注明出处