从开发到架构学习(一)

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

先看下现状,存在的问题:

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

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

3、  可用性的问题。

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

 

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

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

1、  什么是架构

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

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

 

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

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

 

进行架构设计时,要关注如下方面:

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

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

3、  技术选型。

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

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

 

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

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

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

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

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

 

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值