从软件的架构观谈起

概述

      这一年来读了读有关国外大牛和先辈相关的书,最近本身也在作项目架构.见一些同行的言论,有些感触

有赞同的地方也有不赞同的地方,这里谈谈本身的架构观.

1.架构不是为了玩技术

     不少人在玩技术技巧,但架构这东西非做秀,然而一些人在这么干,

架构的审核标准第一条:便捷、易维护、适合于需求不断调整业务场景.

     曾经在一个企业见过这样的场景:所谓的一个leader十多年的时间带领一帮人作一个简单的信息管理系统,

他们全部的一切都一团糟,却玩起了技术秀--学着别人作DDD.

邯郸学步的后果--彻底在模仿形式,系统随着需求调整和加增时当即变现出来牵一发动全身.

还有一个明显的表现:开发和维护起来的灵活性彻底丧失.

 　架构不是表演、而是为需求和开发人员服务的.　　

　用过async await的朋友,估计会发现微软设计中的问题:一致性问题,UI编程模式下(winform wpf等)和在

纯编程模式下的实现一致性问题.这不只让我想到一直让人唾弃的ASP.NET webform,微软这些年干了一些荒唐事情(直到VNEXT的出现).

　微软这些年不行了--这不是我说的,而是一位曾担任微软亚洲架构师说的.不要问我是谁,不会告诉你.

　由于这帮人在玩技术概念,而不是作好的架构.

2.架构的目的是将软件工程精简化

世界上最好的学者老是能够深刻浅出的把大道理讲给外行听，而不是故弄玄虚的把简单的问题复杂化。--数学之美.

就DDD而言,我赞同其中的层次理念,但人们的使用估计多数在邯郸学步,

我问:你这么用DDD,彻底在套形式呢?仍是让全部的业务都在等着你这么去使用??

有人赞同个人反问,有人 赞同对方.各类缘由不在评说.

只让你们去思考一件事情:软件开发中惟一不变的是:业务需求一直在变:调整、增减.

架构的目的在于为需求和开发人员服务.

3.检验架构终极考研--现行市场

这些年出了几个基于浏览器的PC操做系统,如谷歌,惠普等??还有相似的手机操做系统如Mozilla.

架构理念堪称完美,但最终都成了边缘、废弃的东西.

首先从架构上来说,他们的设计理念确实很完美:

利用Html5

1.解决了开发成本问题;

2.解决开发人员稀少问题;

3.解决操做系统自己维护问题;

以上是他们的如意算盘,但他们最终失败了,他们说之因此失败---性能和用户体验.

但仔细想一想,难道一开始他们没有想过这个问题?不会,绝对不会犯这么低级的错误,

不管怎样都考虑过这个问题,至少他们认为:性能到时候应该不是一个问题.

那么为何会失败呢?

他们脱离了现行市场的考验:当下市场中的产品,他们的优点本身是否具有,

毕竟其余的系统都已经成为市场巨无霸了,而本身的新东西是否具有颠覆现行需求的基本条件???

这是IT决策者和市场脱节的后果.

4.架构在代码中的衡量

代码重用性、耦合度、可维护性、可测试性

在谈及这四种特性以前,咱们谈谈业务功能,

全部的开发都是围绕着业务功能走的,每个业务功能(如充值)都由

其余更细的围绕着该业务的小功能组成.

责任越多,越不易被重用;

涉及得越多,越容易耦合;

便于构造和观察的输入输出,才能有更好的测试性.

 

5.谋定然后动

没有人告诉你何时该敏捷开发、何时应该瀑布型开发,

但不管何种开发开发模式,谋定然后动是其根本,

谋定然后动不是指一种开发模式,而是指一种作事的原则.

出来混的早晚都是要还的,明白人都懂得这个道理.

------------------------------------------

6.眼界决定成败

 这个了解过吗?