10年感触:架构是什么?——消灭架构!

架构是什么?昨天下午我坐飞机从西安到太原的路上,不禁在思考这个问题。我做C#开发已经11年了,做过很多项目,经历了很多项目开发过程中的折磨,在小企业兼职过不靠谱的“技术总监”,在大公司也当过码工,见识过很多牛人,分析过牛人的代码,并且也和团队设计了OSGi.NET框架和iOpenWorks插件仓库平台。回想这么多年的软件开发经验,我发现自己一直在追逐如何使软件开发做的更好,如何让一个团队开发出一个像样的软件产品,而不是像大多数的国人生产的丑陋不堪、经常出现各种古怪问题的企业软件。

目前除了做软件开发平台,我们还深入到热力、能耗监测等能源监控领域,进入这个领域之后,发现传统的几个大厂家,做的软件都极其的烂,那软件简直丑的不能再丑了,送给我我都不要。这些厂家那么有钱,他们做不出好软件?真是不可思议。因此,我跟我的合作伙伴放出豪言,我们要做这个行业最好的软件,要做到这个领域的第一。

哈哈,话说出来容易!当我在一个特定环境下,带领一个新的、刚刚成立的团队尝试来开发这么一个软件的时候,我却发现我们软件的第一个版本也是其丑无比。这才恍然大悟,或许那些厂家的软件开发也是这么的方式来生产的。这样生产出来的软件要满足用户的需求,那这些开发人员得遭多少罪,才能够在一个不靠谱的软件修修补补使其稍稍靠谱。

因此,我开始反思,怎么能使一个新团队开发一个好的软件产品?

答案和我的标题是一样的,我要依靠架构。那么架构是什么?

架构是一个约定,一个规则,一个大家都懂得遵守的共识。那这是什么样的约定、什么样的规则、什么样的共识呢?

我以包为例,我经常出差,双肩背包里装了不少东西。笔记本电脑、电源、2个上网卡、鼠标、USB线、一盒大的名片、一盒小的名片、口香糖、Mini-DisplayPort转VGA接口、U盘、几根笔、小螺丝刀、洗漱用品、干净衣服、袜子、香水、老婆给我带的抹脸膏(她嫌我最近累,脸有点黄)、钱包、Token卡、耳机、纸巾、USB线、U盘等。这个包有很多格子,最外面的格子我放常用的,比如笔、纸、一盒小的名片等;中间的格子一般放的是衣服、袜子、洗漱用品、香水等;靠背的那个大格子放了笔记本电脑,和笔记本电脑相近的小格子放的是两个上网卡、Mini-DisplayPort转VGA接口、大盒名片、记事本,和笔记本电脑相近的大格子放的是电源、鼠标、口香糖等。

我闭着眼睛都可以将我的东西从包里掏出来,闭着眼睛都可以将东西塞到包里!但是,非常不幸的是,一旦我老婆整理过我的包,那我就很惨了,老是因为找不到东西而变得抓狂!更不幸的,要是我那个不到两岁的“小可爱”翻过,就更不得了了。

这个包就是我放所有物品的“架构”,每一个东西放置的位置就是我的“约定、规则、共识”。倘若我老婆也知道我的“架构”、我的“约定、规则、共识”,那么不管她怎么动我的包,我都照样能够轻易的拿东西或者放东西。进一步,如果我的同事也知道我的“架构”,知道我的“约定、规则、共识”,那么他们什么时候动我的包,我也毫无所知!

恍然大悟!我前一个公司Sybase,所有的产品都是基于一个统一的插件开发平台,每一个产品都是一个插件,每一个插件都按照名字约定好了BO(Controller)、GO(View)、SO(Model/DataAccessor),定义好PropertyPage、PropertyDialog、Wizard。我记得当我确定工作角色后,我就拿到一个开发文档,里面描述了这些目录、名字的规则,有UI文字陈述规则、文字的大小规则等,一周内我就能够修Bug,一个月之后我就能做New

Feature,然而,我此时对我们的平台、框架依然一无所知。过了1年后,产品依然遵守约定不断进行改进,在维护过程中,我们竟然丝毫没有感觉到累。基于这样的框架做产品,我发现不管是什么人,开发的样式都完全一致。我以前竟然丝毫没有觉得惊讶!

在公司混了两年之后,有点成为老鸟了,还很得瑟的整了一个《Flex UI Composition
SDK》,就是基于Flex的界面组合组件,搞的老漂亮了,代码写的好看,文档搞的正式,而且这个小SDK功能强大且很灵活。老大很给面子,让我给美国的架构组Show一下。我很激情的在半夜里用电话会议和那帮很牛的架构师、专家级工程师展示我的SDK。完事后,印象很深刻,一个很资深的老外架构师提了一句,他觉得这个SDK有点复杂。

以前我不太理解为什么他会说复杂。原因很简单,以他的技术,使用这个SDK我觉得没有太大的问题,只要稍稍学习就好了。后来,我终于慢慢想通了。这个SDK不好的地方在于太灵活了,灵活到无法构建一个统一标准的、容易让人遵守的“约定、规则、共识”。在没有“共识”的支撑下,这样的系统经过若干人维护后,那绝对玩完了,成“万人坑”了,谁改代码就坑谁,以后什么事情都有可能发生的。

于是,我有一点点想明白了,架构就是这么的一个共识。当共识普遍传递的时候,架构就消失了,开发好的软件就成为了习惯。

这就是为什么有高人提出“消灭架构”!哦,天啊,这帮人太变态了,他们这么早就想通了!

谈到这,我也有必要继续分享一下,我在新的团队是如何消灭架构的。方法很简单,和Sybase的前同事学习!

第一步:使用插件架构

第二步:定制统一的界面框架

这个界面框架如下所示。

该框架约定了统一的界面样式,比如按钮、磁贴、标签页、导航条、进度条、Form等等。

第三步:定制插件的统一架构

每一个插件都创建5个目录:Controllers、DataAccessors、Models、ViewModels、Views,如下所示。每一个目录存放的代码通过名字都知道是什么了。

第四步:定制开发模板(升华,该步骤不是必须的,是为了更好提高易用性,让傻瓜也可以开发插件,仅供参考)

在主程序模板可以保护统一数据访问、统一安全管理等功能模块。

哈哈,这个方法终于能使新团队开发出具有较为统一风格、较高质量的软件产品了!这时候,你会发现,所有人都不需要关心架构了,我们只有共识。

这样,架构被成功消灭了,架构的目标就是消灭架构!但是,如果架构被消灭了,架构师不也被消灭了吗?这个搞笑的问题留给读者吧。

作者:陈贞宝

来源:51CTO

时间: 2024-09-17 03:38:02

10年感触:架构是什么?——消灭架构!的相关文章

亿级流量电商详情页系统实战:缓存架构+高可用服务架构+微服务架构

<缓存架构+高可用服务架构+微服务架构>深入讲解了亿级流量电商详情页系统的完整大型架构.同时最重要的是,在完全真实的大型电商详情页系统架构下,全流程实战了整套微服务架构,包含了基于领域驱动设计进行微服务建模.Spring Cloud.基于DevOps的持续交付流水线与自动化测试套件.基于Docker的自动化部署.此外,还包含了大型电商详情页系统架构中的多种复杂架构设计的详细介绍. <亿级流量电商详情页系统实战(第一版)>的内容,主要是基于简化以后的大型电商详情页系统的背景,重点包含

DotNET企业架构应用实践-系统架构与性能-缓存技术与ORM中的缓存查询技术

系列回顾       在前面的文章DotNET企业架构应用实践-系统架构与性能-理论依据及相关做法一文中我介绍了系统性能优化的理论做了一个概括的介绍,也简单的介绍了性能优化的过程及相关的技术关注点或者说是做法.       本文将基于系统架构与程序设计两方面入手,介绍系统架构与性能优化方向一种技术实践:缓存技术与ORM缓存查询. 缓存介绍       前面的文章DotNET企业架构应用实践-系统架构与性能-理论依据及相关做法我在系统优化的理论依据中简单的提到了CPU中的调整缓存操作系统中内存管理

DotNET企业架构应用实践-系统架构与性能-在业务中实例使用缓存与缓存查询-附上视频

回顾与说明      本文是DotNET企业架构应用实践系列中的一篇文章,同时也是一步一步教你使用AgileEAS.NET基础类库进行应用开发系统中的一篇文章,所以本文应该还有一个副标题"一步一步教你使用AgileEAS.NET基础类库进行应用开发-WinForm应用篇-在商口入库业务中使用缓存与缓存查询",为什么会是这样呢?这个原因主要是我希望我在讲企业架的时候有结合具体的实例进行讲解,而不是泛泛而谈,而在AgileEAS.NET平台的案例开发中也正好涉及这样的内容.     在前面

hibernate-技术架构的图片 技术架构的图片

问题描述 技术架构的图片 技术架构的图片 技术架构的图片 1.简单的struts+hibernate的开发框架 2.struts+spring+hibernate框架 3.springmvc+spring+mybatis的框架 解决方案 架构高性能海量图片服务器的技术要素架构高性能海量图片服务器的技术要素架构高性能海量图片服务器的技术要素 解决方案二: 可以参考插件化开源开发平台JXADF的架构图,详细参见:http://osgi.help

在首席架构师眼里,架构的本质是……

目前讨论架构实操(术)的文章较多,讨论架构理念(道)的较少,本文基于作者在大型电商系统架构方面的一些实践和思考,和大家聊聊架构理念性的东西,希望能够抛砖引玉,推进大家对架构的认识. 什么是道,什么是术?道是事物发展的本质规律,术是事物发展的具体途径.规律只有一个,途径很多,条条大路通罗马,罗马是道,大路是术.道为本,术为途,如果事先知道罗马在哪里,那么遍地是路,路路相通.架构也是如此,如果能领悟架构的本质,就不会拘泥于现有的实践和理论框框,而以最直接的方式解决问题,无招胜有招.本文的内容包括架构

《Spark大数据处理:技术、应用与性能优化》——1.4 Spark分布式架构与单机多核架构的异同

1.4 Spark分布式架构与单机多核架构的异同 我们通常所说的分布式系统主要指的是分布式软件系统,它是在通信网络互连的多处理机的架构上执行任务的软件系统,包括分布式操作系统.分布式程序设计语言.分布式文件系统和分布式数据库系统等.Spark是分布式软件系统中的分布式计算框架,基于Spark可以编写分布式计算程序和软件.为了整体宏观把握和理解分布式系统,可以将一个集群视为一台计算机.分布式计算框架的最终目的是方便用户编程,最后达到像原来编写单机程序一样编写分布式程序.但是分布式编程与编写单机程序

联想高级架构师分享:架构之道-规划、简化和演化

架构这个概念,和计算机科学(包括近几年才成为一级学科的软件工程)的其他术语类似,都是从传统学科借用来的.这是因为计算机科学太年轻.发展太快,来不及形成自己特有的术语和名词.因此,在学习和思考方法上,常常推荐类比法,尝试用一些耳熟能详的事物去理解和解释计算机科学领域的概念,以求"老妪能懂"的效果. 这里介绍的一些内容,大多是个人在学习和实践过程中的一些思考和体会,以及平时的一些学习笔记整理而成,还很不成体系,还有很多需要继续推敲的地方.我会在未来的工作实践中更加深入思考,广泛参考领域内的

架构师速成-有关架构的思考

架构是什么?架构的目标是什么?如果解决这2个问题,可能我能更好的梳理杂乱的架构理论.经过2天的思考,总算有了一点眉目.我们从一个产品的本质来说,追本朔源,自上而下: 大概就是这样的,当然架构不止需要解决这些问题,本产品只是其中一个部分,要支撑一个web产品还需要依赖很多的外部公共系统,对这些系统整合也算作架构的范畴. 架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计,这是官方的定义. 在"软件构架简介"中,David Garlan 和 Mary

C/S架构与B/S架构的概念和区别

C/S架构 C/S 架构也可以看做是胖客户端架构.因为客户端需要实现绝大多数的业务逻辑和界面展示.这种架构中,作为客户端的部分需要承受很大的压力,因为显示逻辑和事务处理都包含在其中,通过与数据库的交互(通常是SQL或存储过程的实现)来达到持久化数据,以此满足实际项目的需要. C/S架构的优缺点优点: 1.C/S架构的界面和操作可以很丰富. 2.安全性能可以很容易保证,实现多层认证也不难. 3.由于只有一层交互,因此响应速度较快. 缺点: 1.适用面窄,通常用于局域网中. 2.用户群固定.由于程序