从开发到架构学习(一)

公司OA产品到现在发展有3年多了，一直有人在说系统很烂，不稳定，性能差，可用性不好。这些结果的原因是什么呢？

先看下现状，存在的问题：

1、  系统不稳定，偶尔出现无规律的错误，中断类的。分析这些日志，属于底层、难定位的多。（没有引起足够的重视去分析？）

2、  速度慢，在部分子系统中操作时，包含的业务流程太多，要等待很长时间，而且等待过程中没有与用户的交互。

3、  可用性的问题。

做了三年，这三个问题一直存在，没有根本解决。在新系统中也出现这类问题，由此导致形成循环，并且维护成本一路攀升，需要的维护人员越来越多，而且越来越累。

 

个人分析，主要是架构环节的缺失，缺少对系统的整体约束、规划、前瞻。虽然有架构这个岗位，但没有起到架构的职责和作用。

找了些资料，了解下架构方面的知识。对于我来说，主要想弄清楚以下这些问题：

1、  什么是架构

2、  怎样来进行架构，架构工作包含哪些内容

3、  如何从开发到架构转变

 

在Simon Brown的文章中提到，架构是一个职责，不是头衔。软件架构师指导团队的架构和设计，通过一个全局的观点、宏观的视角来表达软件系统作为一个整体如何工作。

一个人拥有知识，但是却没有能力清晰的表达自己，这简单地和他没有任何知识一样，所以架构师必须要找到清晰地表达自己想法的方式。

 

进行架构设计时，要关注如下方面：

1、  管理非功能性需求。如性能、扩展性需求等。

2、  架构定义。将结构、方针、原则和领导力引入技术层面，个人理解为定义软件的主体结构及约束。

3、  技术选型。

4、  架构评估。组织对架构的评审，通过‘测试’保证架构方案的健壮性。

5、  协作。保证与所在环境的集成。

 

如何体现这些内容？主要是通过一系列的视图实现。如逻辑视图、开发视图、部署视图、场景视图、进程视图、数据视图、实现视图等。结合部门现状，觉得可以采用以下几个视图：

1、  逻辑视图：定义系统功能元素，以及他们的接口，职责，交互。可用于开发组织划分、成本/进度评估的依据。

2、  开发视图：描述系统的层，包等。系统通用服务、类及接口。用于描述系统如何开发实现。

3、  数据视图：系统核心实体及相应的存储方式，系统核心的数据流。

4、  用例视图：概括架构上的重要场景，阐明架构的广度和众多架构元素的运行方式，供设计和开发人员参考。

 

以前总觉得进行架构设计、写架构文档是件很高深的事情。仔细的分析这几类视图的作用和目的，从现存的问题出发分析，还是很清晰的。从开发到架构，是一个渐进的过程，从小处着手实施架构的工作，积累持续的，跨不同领域的技能、知识和经验，提升个人层次和视角。