概述

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

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

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.眼界决定成败

 这个了解过吗?