智能化软件开发沙龙之“软件设计与代码质量”

Posted 2021-05-02 CodeWisdom

 CodeWisdom

智能化软件开发沙龙是复旦大学CodeWisdom团队参与组织的专注于代码大数据与智能化软件开发的学术和技术沙龙，面向相关领域的学术界研究者和工业界实践者，通过各种线上和线下交流活动促进学术研究与实践技术的发展。微访谈是智能化软件开发沙龙依托沙龙微信群开展的线上交流活动，其形式是围绕某一具体话题邀请嘉宾进行在线访谈并与微信群成员互动。

智能化软件开发沙龙之

软件设计与代码质量

活动简介

2018年7月25日，智能化软件开发沙龙在复旦大学举行了一次主题为“软件设计与代码质量”的线下沙龙活动。

嘉宾

彭鑫（兼主持人）

复旦大学 教授

蔡元芳

美国Drexel University

终身教授

张刚

资深架构专家

初创企业技术合伙人

刘志伟

百度工程效率工程师

聂黎明

浙江理工大学讲师

访谈主题

1.工业界的软件设计与架构实践是什么样的？

2.工业界是怎么做设计的?

3.工业界在软件设计和架构实践中有哪些痛点？其中有哪些可以转化为明确的技术诉求，可以让学术界研究者找到合适的研究切入点？

4.学术界和工业界能否有更好的合作，解决软件设计与代码质量所面临的各种问题？

Question 1

能否简要谈一下您对MSR的理解以及您所了解的MSR研究的发展历史？

张刚

既然今天的主题是“软件设计”，那么软件设计应该有一个清晰的定义。但是，我发现在实际工作中，很多人对软件设计的理解是不一样的。希望在座的各位老师和专家谈一下：软件工程教科书以及软件工程课上讲授的软件设计到底是什么样的？

蔡元芳

软件设计是一个抽象和映射的过程，把现实世界当中一些概念映射到计算机的概念中来。设计的本质是一种决策，软件设计既包含了过程维度，也包含了制品维度。

彭鑫

软件设计是需求与实现之间的一个桥梁，介于需求和实现之间，一方面相对于需求来讲它给出了一个解决方面的轮廓，对于实现来讲是一个初步的宏观的思考，所以如果可以对它进行早期的质量评估，一旦有什么问题，对它进行调整的成本比较低。

蔡元芳

软件设计应该有两个含义，第一个是过程，从设计师把现实的概念变成程序的过程，第二是过程中产生的人工制品。

彭鑫

就是一个是设计过程，一个是设计结果。软件设计要兼顾各个方面的需要，比如说一方面协调大家的工作，设计实际上是大家相互之间协作的规划，由谁负责某个模块，与其他人的工作是怎么衔接的，这些跟设计方面有关。从性能来看，软件怎么始终保证非功能性的质量，跟设计方案有关，包括可维护性和可扩展性。

彭鑫

既然软件设计是一种规划、决策，那么软件设计是不是就是一种概念化的存在，而没有所谓的软件设计制品？

蔡元芳

软件设计的最终制品是代码。当然，代码最终能否忠实的反映决策者的初衷，需要更仔细的考虑。

Question 2

工业界是怎么做设计的?

彭鑫

工业界怎么做设计的，比如说拿到需求之后怎么做设计，包括设计后形成什么样的结果，比如画什么图，这种东西怎么交给底下程序员，包括用什么手段保证设计得到贯彻。

刘志伟

每个团队的软件设计实践都不太一样。我个人经历过的，比较常见的情况是，软件设计一般由senior的开发者先总体设计好，或者相关人集体讨论出一个大致的方案，进行多次从需求到实现的评审，然后分别开发。很多时候软件开发都不是从头开始，而是基于企业已有的基础设施（例如运行了多年的系统以及可复用的代码的基础上）进行开发的。

彭鑫

一般的软件实践是怎么开始的？设计怎么做的？比如说一个senior开发者是怎么设计的，设计产生的东西是什么，设计方案怎么传达给大家？

刘志伟

软件设计者通过调研后产生一份ppt或设计文档，召集会议进行评审，在此过程中阐述自己的理念，经过讨论后，会进入到实现阶段，分模块去开发，明确模块间的交互。设计比较轻量级。整体架构图的呈现方式，会经常用框图来描述，包括模块职责以及如何交互，UML图会比较少见一些。

蔡元芳

模块间的交互会使用单独的规范文档进行描述吗？

刘志伟

据我所工作过的系统来说，系统产品内部的通信通常不会在架构文档（如刚才说的ppt）之外描述。当然如果当前要进行的系统升级是交互方式的升级，那么肯定会有专门的文档来说明。

彭鑫

这部分说明企业内部通信协议等技术基础设施需要比较稳定，但是其中的交互参数和返回值等与业务相关的接口和交互协议是需要定义的

刘志伟

需要定义，但是由于这些都是可变的，通常不会需要独立一份架构文档，而且这个跟需求紧密相关，所以通常是开发人员之间根据PM提出要完成什么样的需求进行交流。代码的提交，也会经过多人的评审

张刚

我职业生涯中有很长一段时间工作于阿尔卡特朗讯（ALU），也有一段时间在创业公司做研发管理工作。这两种组织的特点是不太一样的。在ALU这样有着很深厚的研发传统的企业里，软件设计还是挺靠谱的。架构设计有一套成型的方法学。当然架构也不是从零开始，它的基础架构是有一个传承的。面对新的功能，往往面临很多决策，例如需不需要新的模块，如何定义职责，如何实现可靠性、安全性、性能这些非功能性需求，都有专门的架构分析流程和专门的架构师去做分析。

架构的评审也很正式，我们采用的是ATAM方法。当然，在实践中并不是没有问题。最大的问题是认知水平的对齐，不同人的认识水平是不一样的，对于理解的不好的团队，这些方法也很有可能会沦为一种形式。另外一个潜在的缺点是慢，在快速变化的软件环境中，大家现在已经很难这么按部就班的开展架构设计和评估。

当然不是所有的大公司都有非常好的架构方法学和工作流程。即使在一些大的企业，据我了解，很多架构也并不是经过深入考量的，而是根据市面上的流行架构来仿制一个自己的架构——这个我称为“推定架构”。推定架构未必不好，但是由于往往“不知其所以然”，在情况发生变化的时候往往缺乏足够的警惕。

有些组织中，实际代码的耦合很严重，乱成一团麻。这往往是一些演进导致的问题。高层设计做得很早，很多细节没考虑，而这些“架构师”又不能深入细节，高高在上，缺乏架构守护，开发人员为了实现功能随意增加不该有的耦合得不到及时发现和制止，系统就会越来越乱。

张刚

接着说我在创业公司的一些经验。很多小公司也有所谓的“架构师”，但是其实很多名字是“架构师”的人是没有架构意识的。很多公司也有所谓的架构，往往就是一些技术栈的堆积，而并没有从实际的架构约束和商业上下文进行深入的考量。当然，对于处于起步阶段的公司而言，生存是第一位的，软件设计往往得不到特别的重视，这不一定是坏事。软件设计是跟着业务演进的，船小好掉头，小公司能够快速转变，所以软件设计频繁变化，最初做的不好问题都不大。规模小，后悔成本没那么高。所以创业公司对软件设计不太在意。公司的生存与业务模式才是决定公司生存的，而软件设计不是。

刚才我们谈到有很多团队不使用UML，根据我的理解，很多企业不用UML不是因为UML不好，而是因为用不好。建模和画图是两个概念。UML有严格的规范，它表示的是模型，可以进行模型之间的一致性检查，非常有利于沟通和设计构思。当然不要简单的UML的类就理解成代码中的类，它是一个“概念”。我从来不在UML中做详细的类设计，那些直接在代码中实现，但会用UML描述高层设计，例如模块关系、系统分解、模块交互等。常用的UML图包括use case、sequence diagram、class diagram、communication diagram 等等。

蔡元芳

我觉得4+1视图很重要，怎么都无法离开这些。

张刚

同意。我觉得4+1视图和RUP的视图都很好用。用UML不要用的很重载，用它的子集就好。

彭鑫

use case的场景是跟架构设计密切相关，架构适不适合是由use case驱动的。

Question 3

工业界在软件设计和架构实践中有哪些痛点？其中有哪些可以转化为明确的技术诉求，可以让学术界研究者找到合适的研究切入点？

张刚

首先我觉得，很多人不在意软件设计，这是一个意识层面的问题，比较宏观。另外，很多人只会follow别人做的事情，并不知道背后的决策是怎么样的。

蔡元芳

同意，很多学术界的人也不怎么在意设计： 只看到决策的结果，看不到决策的过程。

张刚

恩，因为软件在演进，演进的时候，一些工作没做好，所以就很难知道设计的具体过程。

蔡元芳

软件设计应该有两个含义，第一个是过程，从设计师把现实的概念变成程序的过程，第二是过程中产生的人工制品。

彭鑫

这个其实说的是软件设计的rationale问题，叫做rationale的表示，但这个又回到传统的软件建模的角度。

蔡元芳

问题的关键在于rationale也在变，一旦这个模式在一个阶段固定下来的话，它的价值就越来越小。

张刚

它一直在变，而且不能够在一个阶段固定下来，写成文档或者其他形式记录下来。

蔡元芳

等你把它记录下来的时候，它已经变了。

张刚

这是一个很重要的问题，很多开发者，对于什么是好的设计，没有概念。例如不知道什么叫内聚、耦合，或者不知道如何解耦等。能看出软件设计的内聚、耦合等本质问题的开发者可能不超过10%。

刘志伟

同意，很多人没有意识到采用好的软件设计之后，可以带来的好处。

彭鑫

企业很看重量化，领导层只有看到量化的东西才能感觉到改进的效益。

蔡元芳

所以我们的工具就是需要量化。我们没办法从哲学的层面说服，那我们就用数字来说明问题。

张刚

这个很重要，一定要量化为可主观看到的，比如说钱。很多年前，我做重构研究，发现软件重构得不到高层的认同。就是因为花了很多的钱和时间，但价值很难体现。但现在讲这块要好多了，因为大家开始意识到这个问题了。

蔡元芳

我们的工具可以检查模块化代码，检查数据质量，并对重构的投资回报率进行量化，具体可以看我们发的论文：

Ran Mo, Will Snipes, Yuanfang Cai, Srini Ramaswamy, Rick Kazman, Martin Naedele, “Experiences Applying Automated Architecture Analysis Tool Suites”, ASE 2018，以及Rick Kazman, Yuanfang Cai, Ran Mo, Qiong Feng, Lu Xiao, Serge Haziyev, Volodymyr Fedak, Andriy Shapochka, “A Case Study in Locating the Architectural Roots of Technical Debt,” ICSE (2) 2015: 179-188 (pdf)

彭鑫

接下来我们还是回到主题，暂时不谈意识上的问题，谈点具体的技术痛点，例如架构看护问题等等。

蔡元芳

简单的架构看护实际上是人工定义好一些规则，例如A模块不能调用B模块，然后通过静态扫描自动检查是否违反规则，这种相对而言比较简单和初级。

张刚

对于我来说，最大的痛点是持续演进。如何让软件架构在演化过程中能持续保持好的状态而不腐化？一个系统一开始架构定的很好，但只要有段时间不关注，就会添一堆乱七八糟的东西。

彭鑫

这是不是说看护没做好？

张刚

举个例子，我现在定义一个数据结构，里面有一个类，代表用户信息。这时例如添加一个中奖功能，有人就会向一个用户类里加一个是否中奖的属性，这个属性明显属于另一个不相关的关注点。这种是不是很难看护？

蔡元芳

对，很多程序员看不出来这个问题存在不同的关注点。那么如果用我们的工具来看护的话，加这个新的feature违反了开闭原则，应该通过增加新代码实现，而不应该改原来的代码实现。尤其是如果原来的代码，比如用户类，影响很大的话，更不应该改。

张刚

这种情况如果真的要去检测，除非有高级的架构师盯着，否则很难。当然，如果工具能够做到，那就另说。这个倒是非常切合咱们今天的主题，通过智能化的大数据分析，应该还是很有希望的。

蔡元芳

我觉的最终需要度量的就是特性的解耦度，每次改动都能对应到特定的类别，就可以利用统计分析做到。在工业界，规范一点的公司，都可以实现这样的分类，由此保证实现这样的分析。

刘志伟

我这边看到的一些痛点，是涉及到复用的一些问题，企业已经有很多可用的平台、服务和基础lib库，如果要新设计服务或新写模块，一般会复用现有的平台资源，但如何准确找到可复用的资源，这块是比较难的。在代码级，我们也开发了代码搜索引擎，能够帮助开发者更好的理解现有代码和找到可复用的代码。

蔡元芳

就是说在平台找到可复用的部件？

刘志伟

嗯，因为有可能不同部门自身的需求的需要，会做很多平台、服务。但站在更高的角度看，可能会存在类似的平台，这就造成了重复。另外，即便是功能不同的平台，其他部门做开发的时候，也会参考或借鉴别人的做法，那么最大的问题就是，如果想要一个平台以及进行复用借鉴，怎么才能方便的找到以及避免这种重复？

蔡元芳

那是想用一个平台，还是想做一个平台？

刘志伟

站在开发者的角度来说，想用一个平台或者复用、借鉴部分代码。

彭鑫

就是这个轮子已经有了，其实就是有点像code search。

刘志伟

包括 code search，但也包括更高一层次，包括服务、平台。

蔡元芳

是不是像反向工程？比如看系统有哪些特性，提供了哪些功能。

刘志伟

反向工程这个是否能做到我还不确定。但是涉及到平台级，怎么能判断在这两个平台是不是做同一个功能？

彭鑫

需要为企业已经具备的商业和技术能力进行梳理并提供全局视图，明确企业已经积累了哪些能力，包括把能力分层，知道哪些东西是已经具备的，就不用重复去做。

蔡元芳

蔡元芳：能不能举几个例子，什么是具体的能力？

刘志伟

比如从大的层次上来说，像用户画像类的系统，往细的说，比如可复用的常见的函数。这些平台、代码库上都有，但对于没用过的人或者没听说过的人，怎么快速找到并使用呢，这块比较难。这块我们也正在做。

蔡元芳

现在是怎么做的？

志伟

平台级以及服务级有同事已经进行了研究并且经过实施取得了非常好的效果，代码级我们上线了 code search 系统以及正在研究代码知识图谱、代码 clone 等技术，希望也能在源码级解决一些问题。

蔡元芳

如果有一个能力的全局视图，比如说底层、服务层等等，能不能直接追踪到代码呢？是需要直接追踪到代码吗？

彭鑫

这个不是主要问题，主要问题是怎么让一个新开发者知道已经有这些东西而不用重新做。

刘志伟

是的，源码级复用，比如 Lib 库，是直接寻找代码，相应的 code search 系统可以解决。而平台级和服务级别，一般是要知道相应的功能，以及寻找相应的接口。现在可以想象公司接口调用量级是非常大的，如何找到特定的功能加以复用，我个人觉得这块还需要再进行研究。

张刚

恩，我也觉得这是个非常大的问题。因为小公司还好一点，比如说把很多东西分成服务、模块。但是像大公司，众多的产品线，事业部，那这个问题就变得复杂了。同时如何区分平台的相似度，这个也是非常困难的。

彭鑫

我觉得真的要解决这些问题，可能需要代码有精确的语义标注，并辅助有知识图谱提供的背景知识，解决代码的理解的问题。同时在一些领域内，存在一些通用的Pattern描述需求，将高层的需求、功能与底层的代码实现映射，实现代码功能的理解。

排版｜CodeWisdom

文案｜CodeWisdom