成为技术老大技术管理篇3一复杂问题简单化

发表于:2018-4-27 10:03

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:铁棍山药    来源:简书

  随着产品的迭代,系统会变得越来越复杂,这是一个必然的过程。如何不停的断舍离,让系统复杂度维持在可控的程度,是每个管理者始终要绷紧的一根弦。管理复杂度首先要在源头把关,每次系统的迭代都需要进行架构评审,从源头控制复杂度。
  怎么开一个技术架构评审,在项目管理篇曾经写过,这里就不再赘述了,大家可以去看一下,成为技术老大项目管理篇10一技术架构评审。这里只说一下怎么控制复杂度。
  不知道大家有没有听说过奥卡姆剃刀定律,它是由14世纪英格兰的逻辑学家、圣方济各会修士奥卡姆的威廉提出。这个原理称为“如无必要,勿增实体”,即“简单有效原理”。他在《箴言书注》中说“切勿浪费较多东西去做,用较少的东西,同样可以做好的事情。”。这个定律告诉我们一个道理,如果我们设计的架构理解困难,非常复杂,说明这个架构本身就是错的。
  技术架构本质上就是对业务问题的一种解构,就像牛顿的经典物理是用物理模型解构了这个世界,那技术架构其实就是用不同的模型来解构现实业务。我们来看一下整个解构过程是什么样的,首先,处在最底层的模型是冯诺依曼体系结构,他其实解构了计算本身,把计算映射到了硅物质之上,我们现在整个计算机体系都是搭建在他的基础之上。在他基础之上,是操作系统,操作系统把计算问题再次提升到更高的抽象结构,他定义了软件的工作模型。再之上,才是各种语言框架,计算机语言解构了我们跟计算机打交道的方式,让他更接近人类的思考习惯。我们平时所做的业务架构设计,其实就是在语言框架之上,再次对现实业务的抽象分析和解构。
  我们会发现,这一层层的解构,其实就是将复杂的事物进行拆解,不断封装复杂性,不断抽象,拆解成简单的、我们可以掌握的部件的过程。我们的架构设计也要遵循这个原则,本质就是不断更深入的了解业务本身,随着了解和认识的深入,架构设计才会更加合理,这是一个不断优化的过程。这个过程就是对业务的重新思考和认知,需要我们有逻辑洞察和思考的能力。
  怎么进行拆解,会有很多思考套路可以借鉴,我觉得分拆和复用思想是最基本的二个。下面分别来说一下。
  先说说分拆,我们可以看到计算机体系的不断演化也是不断分拆的结果。分拆简单说就是把系统分成不同的层次,每个层次都为上一个层次提供了简单的使用方式,封装了本层的复杂性。让我们可以一次只考虑一件事情,把复杂问题简单化。
  比如我们经常会把数据访问封装到DAO层,上层业务层只通过DAO来存储和查询数据,而不直接操作数据库、Cache等中间件。这样就让上层业务可以专注考虑业务逻辑本身,抽象层次更高,而不被其他无关细节打扰。
  再比如AOP模式,也是分拆的体现,我们把数据库事务放到AOP层来统一解决,就让DAO层可以专注数据存储查询本身。
  再来说说复用的思想,就是尽量不要重复造轮子,尽量把相同的功能封装到一个部件中,部件封装了各自的复杂性,不对外暴露。比如界面的组件化,我们把一类操作和展现封装到一个组件中,让整个系统界面变为组件的组合和协同,大大提升了研发的效率和质量。
  分拆和复用其实在我们现实生活中也有体现,这不就是人与人之间的分工和协作吗,分工就是分拆,让每个人做自己擅长的,充分发挥各自的优势;复用就是协作,尽量使用别人成熟的经验和成果。分工和协作使人类完成了许多不可能完成的任务。
  总结一下,深入了解业务,把复杂问题简单化,就是管理复杂度的本质;分拆和复用是两个基本的思路。当然,我们的业务架构设计是建立在计算机语言和框架基础之上的,我们还得了解这些语言和框架的套路,比如函数式设计、面向对象设计、面向响应设计等等,了解这些更有助于我们做好业务的架构。下面给大家逐一聊一下。

相关文章
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号