软件架构系列感想（三）

1、未来的架构师在哪里？

我们可能花了很长时间谈论编写代码、自动化测试、自动化部署、工具、各种技术，以及所有相关的流程，而可用的软件是关键。多想想这些问题：

（1）你上次写代码是什么时候

（2）你上次重构是什么时候

（3）你上次测试你的代码是什么时候

（4）你上次设计东西是什么时候

（5）你上次从零开始设计一个软件系统是什么时候

（6）你上次从零开始设计一个会由一个团队来实现的软件系统是什么时候

2、有些人过于渴望敏捷，以至于忽略软件开发流程的其他方面。单个点负责项目的技术层面，也跟他们对敏捷团队的想象相冲突，这种冲突使人认为敏捷和架构是对立的：你只能拥有其中一个。与敏捷对立的不是架构，而是大型预先设计。

3、对业务领域的了解必不可少。大部分业务领域都比他们应有的样子更复杂，越了解越可以帮助你更好的理解目标和建立成功的软件产品。

4、如果你负责一个软件系统的软件架构和技术交付，就必须有决策权。软件架构的角色意味着技术领导力，也就是你要让整个团队朝着同一方向前进。

5、架构驱动力。

不管你采用哪种流程（传统或计划驱动，轻量或可适配的），都有一套常见的东西真正驱动、影响和塑造了最终的软件架构。

（1）功能需求

需求驱动架构。特性或用户故事清单，即使粗糙短小，也是必不可少的。

（2）质量属性

非功能需求代表的质量属性反映了服务等级，如性能、可伸缩性、可用性、安全性等。实现非功能需求的技术解决方案通常是交叉的，因此需要合并到你所构建系统的基础中。

（3）约束

你任职的组织可能对技术选型、部署平台等有一系列细致的约束，能做什么，不能做什么。

（4）原则

原则是为了将一致性和清晰度引入最终代码库而想采用的原则（例如编码规范、自动化测试的使用等）或架构的原则（如分层策略，架构模式等）。

（5）理解影响（变化）

任何时候当你开始为一个新的软件系统工作或扩展已有的软件系统时，在高层次上理解需求、约束和原则都至关重要。软件架构谈论的是重要的设计决策，其重要性以变动的成本来衡量。早些理解他们，将有助于避免将来昂贵的返工。

6、质量属性（非功能需求）

性能（就是一个东西有多快，通常指响应时间或延迟）

可伸缩性（就是软件处理更多用户、请求、数据、消息等的能力，和并发机制密不可分）

可用性（就是软件对服务请求的可操作和可见程度）

安全性（涵盖了从认证和授权到数据在运输和储存中的机密性的所有事情）

灾难恢复（就是业务连续性过程）

可访问性（就是如何让视觉障碍之类的也能使用你的软件）

监测（有些组织对于应该如何监测软件系统才能确保他们正常运行和满足服务请求，有特定的需求）

管理（监测通常提供一个软件系统的只读视图，有时会有运行时管理需求）

审计（人们往往需要一个引起软件系统中数据或行为变化的事件的日志，即审计日志，特别是涉及钱的时候）

灵活性（就是软件执行多个任务，或以不同方式执行单个任务的灵活性）

可扩展性（就是扩展软件使其可以做一些现在还不能做的事情的能力，也许是通过使用插件和API）

可维护性（值得思考的是代码库以后将由谁来维护，可维护性很难量化，所以要多思考我们可遵循的架构和开发原则，因为这些是编写可维护的代码的驱动力）

法律法规（有些行业受到当地法律和监管机构的严格管理，导致了与数据保留或审计日志等相关的额外需求）

7、如何处理非功能需求

一旦你开始问那些有关非功能需求的问题，就需要提炼他们。你可以根据交流对象变换问题，而不是问需要多少可用性，比如：

你能忍受的系统停机时间是多少

如果系统核心在朝九晚六的正常工作时间内出现故障，会发生什么

你现在要做的探索需求，搞清楚驱动力是什么。比如：

系统平均应该支持多少并发用户，高峰时段呢

多长的响应时间是可以接受的，系统各个部分都是如此，还是只是针对特定的功能

为了保护系统安全，我们究竟该怎么做，需要对数据加密，还是受限访问就够了

如果你能联系到一定数量的非功能性需求（如用户数、数据量、最大响应时间等），就能写一些验收标准并客观地进行测试。