如果您需要帮助,请点击这里

软件摩尔定律背后的几个常识

dongqingyang

董庆阳

2018-12-12 445
感情男声
  • 感情男声
  • 感情女声
  • 标准男声
  • 标准女声
倍速1.0X
  • 倍速0.5X
  • 倍速1.0X
  • 倍速1.5X

免责声明:文章内容和观点仅代表作者本人观点,供读者思想碰撞与技术交流参考,不作为华为公司产品与技术的官方依据。如需了解华为公司产品与技术详情,请访问产品与技术介绍页面或咨询华为公司人员。

软件的“摩尔定律”,是不断提升软件生产效率,以降低软件的开发成本和上市时间。在软件“摩尔定律”的驱动下,诞生了各种软件开发的语言、架构、工程和模式。每年都有新的编程语言出现。设计模式,据说已经超过300种。各种眼花缭乱的概念和技术,有些还相互矛盾,真伪难辨。借用政治经济学的一个说法,符合软件生产规律的,就促进软件生产的发展,不符合软件生产规律的,就阻碍软件生产的发展。软件生产的规律是什么?总结了几点,不敢轻易说是规律,就是常识吧,供大家指正。

减少开发人员之间的等待和依赖

《人类简史》上说,一个猩猩自然群体中的个体数,一般不超过20-50个。人类,高等一点,增加了八卦等连接力,也不超过150个,再多就要靠文化、制度、意识形态等虚拟的东西来连接了。作为一个软件开发团体,也不是越大越好。团队规模越大,开发人员之间的沟通、配合、等待和依赖越多,效率就越低。但开发人员太少也不行,靠什么来解决这个软件生产上的矛盾呢?

先来回答一个问题,什么是架构?越熟悉的词,越不好找一个准确的定义,这里抛一个我觉得是最接近的。Architecture一词最早来自建筑,是在复杂场景下,解决人的分工、沟通和配合问题,以达到更高效率和更高目标。软件架构就是解决软件生产过程中人员的分工、沟通和配合问题,以及软件生命周期中的维护和扩展问题。显然,解决这个矛盾,架构很关键。

架构让生产人员在技能、工序、配合上充分解耦。盖一栋楼,先是打地基搭框架的人上,然后是砌墙的人上,最后是装修的人上。做软件也一样,如果每个人能够在不相互等待和依赖的情况下,把自己负责的部分做好,拼到一起就能Run,那就是最理想的情况。

从模块化,组件化到服务化,基本也是顺着这个思路在发展。一个团队,接到一个开发任务,先做需求分析,系统分解,每个人分一个模块,各人先聚焦自己的模块。在开发阶段,基本是可以做到解耦的。但在验证和运行阶段,麻烦就接踵而至。一个模块的验证要等待其它相关模块就绪后才能进行,一个模块的修改可能会依赖另一个模块的同步修改,一个模块的问题可能会导致另一个模块崩溃。随着时间的推移,血肉模糊,纠缠不清,无数软件开发人员的大好青春就耗在这里。

经过血泪教训,开发人员自然会想到,把一些公共的功能和框架提取出来,做成组件,提前开发并验证好,确保组件部分没有问题,然后再基于组件,增加适配代码去搭建系统。相比初始的模块化,组件化在效率上肯定有优势。但组件并不能端到端地独立验证和运行,并没有从根本上解决耦合和依赖问题,组件化本质还是一种模块化。由于组件共享程度高,依赖大,还容易成为瓶颈。

服务化架构是在此基础上的进一步发展,不但是在开发阶段解耦,而且是在验证和运行阶段解耦。为什么在验证和运行阶段解耦很重要?老开发人员都知道,一个全新系统的开发,耗时最长的往往不是开发阶段,而是联调阶段。联调特别耗时耗力,因为各部分都不能独立地验证和运行,需要集成在一起才能验证和运行,联调中耗时最多的就是等待。服务化,就是希望每部分尽量都是一个自治的系统,能够独立地开发、验证和运行。一个服务内部的修改不需要其它服务同步修改,一个服务内部的问题对其它服务的影响降到最低,把开发人员之间的配合、等待、依赖和影响降到最低。下面这张图,可以帮助理解从模块化到服务化开发模式的区别。

/

服务化架构(SOA)早就有了,为什么近来微服务很火?道理也很简单,当前微博比博客流行,微信比信流行。小了之后就能有更多的应用场景。深层次的原因,感兴趣的可以去探究。

模块化,组件化,服务化只是架构的一类模式。基于适合的场景,尽量减少开发人员之间相互的等待和依赖,就是好架构。

问题的早期暴露和快速修正

写完一篇作文后就检查,发现的错误立刻修正,效率最高。如果等几个星期甚至几个月后再去检查,灵感和思路全无,效果肯定不好。这是生活中的一个常识,同样适合于软件生产。软件生产很重视代码Review、UT/IT/ST,生产过程从瀑布模式到迭代模式,这些都是为了问题的早期暴露和修正。但光靠这些还不够,还是会有缺陷遗留到后端。让问题在开发过程中早期暴露,快速修正,看似一个常识,但可怕的是,有些开发人员在问题的泥潭中迷失了这个常识。

几个有利于问题早期暴露和快速修正的实践:

1、健康迭代

迭代模式相对瀑布模式的进步,就是问题的早期暴露和修正。如果每个迭代的DI值都很高,那就和瀑布没有区别,甚至更差(压缩了前期的Review和DT)。现在很多企业的产品都号称迭代,但不健康的迭代开发在基层团队还非常普遍,产品一般存在下面几种亚健康迭代:

• 在迭代快结束时集中解决问题,亚健康

• 在迭代快结束时试图解决问题,未达成,很不健康

• 每个迭代的DI值都很高,极不健康

能够做到主干持续健康,绿色主干,随时可发布的产品不多。在进度的压力下,新需求开发优于问题解决。少数团队为了让DI数据不难看,甚至让测试人员停止测试,掩耳盗铃。

2、开发人员做SDV

传统软件生产分工中,开发人员做Code/DT(UT/IT/ST),测试人员做SDV/SIT/SDV。出发点只有一个,就是开发人员完成功能验证后再把代码交给下个环节,本质也就是问题的早期暴露和快速修正。功能性问题往往阻塞测试,需要一群人来定位,确定是谁的问题,定位出来后,测试再提单,开发人员修改,重新出版本,升级版本,非常影响测试效率。开发人员自己做功能测试,问题小闭环,减少测试阻塞,提升效率。看起来很好的事情,推行过程中遇到很多阻力,开发人员觉得做了不该做的事情,测试人员觉得被人抢了饭碗。客观上也有一些困难,比如开发人员搭SDV验证环境的效率比较低。实现这个目标,除了开发人员和测试人员观念上的改变,软件工程能力的进步也是一个推动力。持续集成,持续验证的意识也逐渐深入人心。

回到出发点,敏捷、健康迭代、持续集成、开发人员做SDV,等等,如果能匹配应用场景,让问题能早期暴露,快速修正,那就是符合常识的好方法。

减少信息传递过程中的偏差和损耗

有段时间“高中生编码”的说法甚嚣尘上。单纯从写代码的要求看,高中生也未必是不行,但有两个前提:

1、前端的需求分析、架构设计和模块设计都是正确的,不需要返工,否则要等几个月甚至大半年,从后端发现问题再去修正,成本就高了;

2、从分析、设计到编码,每个环节的信息传递都没有偏差和损耗。

可以说,这两点都不符合软件的生产客观规律。前端的分析和设计一定会存在错误,不同环节人和人之间信息的传递,一定会有偏差和损耗。全功能团队,就是减少这个偏差和损耗。

全功能团队有两层含义:

1、可以做到独立交付,问题快速闭环,充分发挥团队的选择权(人、架构甚至编程语言等)和创造力;

2、原有的角色分工,SE负责设计,MDE/SWE负责编码,TE负责测试。分工细化有利于专业化运作,各领域深耕。但也不可避免地带来扯皮、交接损耗,前期埋下的问题也得不到及时的发现和纠正。全功能团队打破这个分工,SE 负责价值分析和架构设计,特性模块级设计、编码、功能级验证都由MDE/SWE完成,TE 负责面向商用场景和客户的系统级验证。特性端到端负责,减少不同环节之间信息传递的损耗和偏差,减少浪费。

全功能团队的前提是特性解耦,不但是开发态的解耦,而且是运行态的解耦,解耦减少开发团队之间的等待和依赖。角色分工优化是减少开发团队内部的等待和依赖,还减少开发人员之间信息传递的偏差和损耗。全功能团队E2E 地负责需求分析、设计、开发、测试、交付,在全功能团队之外,还可以有个集中的架构师团队(AM),负责核心架构、运维框架、安全框架、分布式仓库等公共设计的编码,看护好全系统。

/

如果说服务化开发模式是从横向减少了开发者之间的依赖,那么全功能团队就是从纵向减少SE、开发、测试之间相互传递的依赖。早期推行全功能团队,困难重重。因为在传统敏捷开发模式下,难以做到运行态解耦,每个开发团队都要集成整个版本后才能验证自己的特性,从某种程度上是降低了效率。服务化开发模式,让开发团队的验证范围聚焦在自己负责的特性,极大降低了集成和验证的工作量,释放了真正的全功能团队的生产力。

/

减少对开发人员的干扰,让开发人员聚焦在编码

分时多任务并行处理是软件技术发展史上的一个革命,但对于软件开发人员来说,多任务并行处理不是一件好事。微软曾针对“工作打断”做过调查,一个人平均每小时有4次被中断,就会产生厌恶情绪,当中断超过3-5分钟后,需要花费23分钟把注意力重新调整已经分配好的任务上来。

为什么有那么多被中断?主要是几个原因:

1、由于特性和架构的不解耦,开发人员在周边的协作、支撑和扯皮工作占比非常高。有统计说开发人员只有30%的时间在编码,70%的时间在忙于扯淡。电话、邮件、即时消息、线上会议等的便捷也让“中断”更

加随意和低成本,但结果却是高成本;

2、开发过程流的信息不自动,不透明,获取不方便,PL项目管理靠“肩挑手扛”,耗时耗力,在事务管理上的投入过多。PL 不编码,同时对员工的干扰也增加;

3、精兵滥用。精兵因为优秀,处理各种事务都比较擅长,经常被滥用。各种攻关、定位、扯皮的事情占据了大部分时间,而让精兵真正投入特性开发的时间反而很少。

为减少被中断,架构上解耦是根本,但在解耦的过程中,有些管理手段也可以使用。比如:

1、设置静默时间。静默时间内,UnPlug,不处理电话、邮件、即时消息、线上会议,不干扰开发人员,让开发人员每天3-5小时集中的核心编码时间;

2、建立项目团队精益看板,实现团队所有任务的可视化管理、流动性管理、并拉动式开发。这样在计划制定时,不必是传统的任务分配式计划制定,而是根据价值优先进行拉动式开发;在项目任务跟踪管理时,也不必是传统的“盯人盯任务”管理,只需要通过可视化的看板,了解整体的特性/需求的进展情况即可;

3、 成立微战队,通过架构松耦合,组织适配,协作分工,把技术讨论和问题在更小的循环闭环,更快速有效。

不管是多么先进、时髦的软件架构、工程或技术,都不要脱离软件生产的本质,或者是常识。这些常识是不依赖于需求,不依赖于场景。架构、工程或技术都是有场景的,在一定场景下,符合这些常识的架构、工程或技术,就促进软件生产的发展,不符合这些常识的架构、工程或技术,就阻碍软件生产的发展。

0/500

请输入评论内容
提交评论

最新评论0

    查看更多评论

      评分成功!

      提交成功!

      评分失败!

      提交失败!

      请先填写评论!