百度高效研发实战训练营-Step2

百度高效研发实战训练营Step2

---

2.1 代码的艺术

2.1.1《代码的艺术》目的解读

这门课程的目的主要有以下四点：
(1) 了解公司与学校写代码的不同
(2) 消除对于程序员这个职业的误解
(3) 建立对软件编程的正确认识
(4) 明确作为软件工程师的修炼方向

1、了解公司与学校写代码的不同

在公司写程序和在学校写程序有很大的不同，在学校写程序时，对代码的质量要求比较低，当进入公司之后，做的是工业级的产品，服务用户量可能会达到亿万级，所以与代码的质量要求比较高，一些伟大产品中的代码，甚至可能被称为是艺术品。

2、消除对于程序员这个职业的误解

很多人都对程序员这个职业有误解，认为程序员就是码农，认为程序员35岁之后会面临失业问题，还有人认为程序员未来的唯一出路是做管理，希望通过接下来的学习，可以对于程序员有一个新的认识，从而消除误解。

3、建立对软件编程的正确认识

在做一件事物时，我们常说要“知”“行”合一，即我们需要对这件事物有一个正确的认识，才会有正确的行动。同理，写出好代码的前提，是对软件编程有正确的认识。

4、明确作为软件工程师的修炼方向

明确作为软件工程师的修炼方向，艺术品是由艺术家创造的，艺术家的修炼是有方式方法的，同样软件工程师的修炼也是有方法的，希望通过接下里的内容，能够对软件工程师这个职业有一个全新的认识。

2.1.2 代码与艺术之间的关系

1、代码是可以被称为艺术的

我们知道，艺术是多种多样的、丰富多彩的。同时，艺术也是有多个层次的。
想象一下我们编写的代码，我们的脑海中也会有类似的感觉，艺术就是人类通过借助特殊的物质材料与工具，运用一定的审美能力和技巧，在精神与物质材料，心灵与审美对象的相互作用下进行的，充满激情与活力的创造性劳动，可以说它是一种精神文化的创造行为，是人的意识形态和生产形态的有机结合体。

同样，写代码也要经历这样的一个过程，在编写代码的过程中，我们借助的物质是计算机系统，借助的工具是设计、编写、编译、调试、测试等，同样编写代码需要激情，而且编写代码是一件非常具有创造性的工作，总之，代码是人类智慧的结晶，代码反映了一个团队或一个人的精神。

代码是可以被称为艺术的！

2、艺术可以从不同的角度进行解读、研究与创造

达芬奇有多幅著名的画作，那著名的《蒙娜丽莎》这幅画来举例，站在观众的角度，可能只是在欣赏画中的人物微笑，但是对于画家来说，可能就会考虑画画的手法、构图、光线明暗、色彩对比等等方面。

同样，在《达芬奇自画像》这幅画作中，光有这个人物还不够，我们还要通过这个人物的个性与背景等等因素来揣摩这幅画作。

综上所述，在艺术方面，我们可以站在很多不同的角度进行解读，但是如果要成为一名创作者，我们需要的不仅仅是欣赏的能力，更重要的是从多角度进行解读、研究与创造的能力。

3、写代码如同艺术创作

写代码就如同艺术创作一般，并不是一件容易的事，写代码的内涵是：

• ①写代码这个过程，是一个从无序到有序的过程。
• ②写代码需要把现实问题转化为数学问题。在写代码的过程中，我们需要有很好的模型能力。
• ③写代码实际上是一个认识的过程。很多时候，编码的过程也是我们认识未知问题的过程。
• ④在写代码的过程中，我们需要综合的全方位的能力。包括把握问题的能力、建立模型的能力、沟通协助的能力、编码执行的能力等等。
• ⑤在写好代码之前，首先需要建立编码品味。品味是指我们首先要知道什么是好的代码，什么是不好的代码。这样我们才能去不断地调整自己的行为，然后去学习，去提高我们的编码能力，写出具有艺术感的代码。

2.1.3 软件工程师不等于码农

软件工程师不能只会写代码，更需要具有综合的素质。这个综合的素质包括:
（1）技术
技术能力是基础。包括但不限于编码能力、数据结构和算法能力、系统结构知识、操作系统知识、计算机网络知识、分布式系统知识等等。
（2）产品
要对产品业务有深刻的理解，需要了解产品交互设计、产品数据统计、产品业务运营等。
（3）其他
要了解一些管理知识，需要知识项目是怎么管理的，如何去协调多个人一起去完成一个项目，如何去协调多个人一起去完成一个项目。有一些项目需要具有很强的研究和创新方面的能力。

以上这些能力素质，是一个软件工程师需要具有的综合素质，要成为一个全部掌握这些素质的系统工程师，至少需要8~10年的时间，所以软件工程师绝对不是一个只会简单编写代码就可以的职业。

软件工程师不等于码农。

2.1.4 正确认识代码实践方面的问题

代码实践方面的问题，重点包括以下三个方面：

1、什么是好的代码，好的代码有哪些标准

好代码的标准是：

• 高效(Fast)
• 鲁棒(Solid and Robust)
• 简洁(Maintainable and Simple)
• 简短(Small)
• 可共享(Re-usable)
• 可测试(Testable)
• 可移植(Portable)
• 可监控(Monitorable)
• 可运维(Operational)
• 可扩展(Scalable & Extensible)

将以上十条标准进行总结精简，可以归纳为

• 1.代码的正确和性能
• 2.代码的可读和可维护性
• 3.代码的可运维和可运营
• 4.代码的可共享和可重用

了解完好代码的标准，接下来看一下不好的代码主要表现在哪些方面：

• 不好的函数名
  比如在函数名中，加上my等单词，这属于很不专业的用法。

• 不好的变量名
  比如看不出任何含义的a b c j k temp等变量名

• 没有注释或注释不清晰
  没有注释的代码是非常难读懂的，注释不倾斜往往是因为文字功底或者描述能力欠缺，从而导致无法通过注释把代码的执行原理讲解清楚。

• 一个函数执行多个功能
  比如LoadFfomFileAndCalculate()函数，它既执行了文件中去加载数据，还执行了计算功能。一般像这样的函数，我们建议把它切分成两个单独的函数。

• 不好的代码样式排版
  代码样式排版在某种程度上体现了代码的一种逻辑，好的代码排版能增强代码的可读性和逻辑性，我们在写代码时，要规避不好的代码样式排版。

• 难以测试的代码
  代码没法测试，就难以编写测试用例。

以上这些都是一些不好的表现。

2、好的代码从哪里来

代码不只是“写”出来的，实际上，在整个项目中，真正的编码时间约占项目整体时间的10%，好的代码是多个环节工作共同作用的结果。

这些环节包括：

• 1.在编码前，要进行需求分析和系统设计。
• 2.在编码过程中，要注意单元测试。
• 3.在编码后，要做集成测试，要上线，要持续运营/迭代改进。

一个好的系统/产品是以上过程持续循环的结果。

下面着重介绍一下重点环节：

• 1.认识需求分析和系统设计的重要性
  需求分析和系统设计在软件开发中经常被忽略或轻视，但是这两点都是非常重要的环节，人们的直觉就是拿到一个项目就想尽快把它写出来并运行，感觉这样的路径是最快的，但是实际上在前期需求分析和系统设计投入更多的成本，会在后期节省更多的消耗。

  也即前期更多的投入，收益往往最大。
  原因是，如果我们开始的设计做错的话，那么后期开发、测试、上线、调试这些成本都会被浪费掉。

• 2.清楚需求分析和系统设计的差别

需求分析和系统设计是有泾渭分明的区别的，为了避免这两者相互混杂，我们需要清楚需求分析和系统设计各自的内涵。

需求分析，主要是定义系统或软件的黑盒行为，即外部行为，比如系统从外部来看能够执行什么功能。
系统设计，主要是设计系统或软件的白盒机制，即内部行为，比如系统从内部来看是怎么做出来的，为什么这么做？

• 3.需求分析的注意要点

需求分析，主要有两个要点：

• 要点一：清楚怎么用寥寥数语勾勒出一个系统的功能。
  每个系统都有自己的定位，我们可以从简洁的总体描述，展开到具体的需求描述。需求描述的内容，基本包括系统类型描述、系统规模描述、系统定位和系统差异描述、系统对外接口功能描述。

• 要点二：需求分析需要用精确的数字来描述，需求分析中会涉及到大量的数据分析，这些分析都需要精确的数字来进行支撑。

• 4.系统设计的注意要点

• 要点1：清楚什么是系统架构
  系统架构(System Architectrue)，在wiki上有一个英文定义，阐述了系统架构是一个概念的模型，它定义了系统的结构、行为、更多的视图，进一步解读系统架构。

它的几个要素是，系统要完成哪些功能，系统如何组成，在这些组成部分之间如何划分。

• 要点2：注意系统设计的约束

  注意系统设计的约束，重点是资源的限制。比如计算的资源限制、存储的资源限制、IO/网络的资源限制等。

• 要点3：清楚需求是系统设计决策的来源

  精确定义需求中的各个细节，以及量的定义，对系统设计的决策起着重要的作用。

• 要点4：系统设计的风格与哲学
  在同样的需求下，可能会出现不同的设计方式，其目的相同，设计不同。
  比如复杂指令集和精简指令集的设计差异。
  一个好的系统，是在合适假设下的精确平衡；一个通用的系统，在某些方面，不如专业系统的。

• 每个组件（子系统或模块）的功能都应该足够的专一和单一。(每个组件，是指子系统或模块等。)

• 功能的单一，是指复用和扩展的基础。
  倘若不单一，未来就有很可能很难进行复用和扩展。

• 子系统或模块之间的关系，应该是简单而清晰的。

• 软件中最复杂的是耦合。
  如果各系统之间的接口定义非常复杂，那么未来便很难控制系统的健康发展.
  值得注意的是，使用全局变量就是在增加系统的耦合，从而增加系统的复杂性。所以在系统中，需要减少使用全局变量。

• 要点5：清楚接口的重要性

接口，英文名Interface，系统对外的接口比系统实现本身还要更加重要。
接口的设计开发不容忽视，接口主要包括：
1.模块对外的函数接口

2.平台对外的API
这些API很多是基于RPC或者是基于Web API来实现的

3.系统间通信的协议

4.系统间存在依赖的数据
比如：给另一个系统提供的词表

以上，这些都是接口，都需要去重视和很好的定义。

接口重要的原因在于：

1 接口定义了功能
如果定义的功能不正确，那么系统的可用性与价值便会大打折扣。

2 接口决定了系统与系统外部之间的关系
相对于内部而言，外部关系确定后非常难以修改。因此接口的修改需要非常慎重且要考虑周全。

后期接口修改时，主要注意以下两点：

1 合理好用
新改的接口，应该是非常合理好用的，不能使调度方感觉我们做的接口非常难以使用。

2 修改时需要向前兼容
新改的接口，应该尽量实现前项的兼容，不能出现当新接口上线时，其他程序无法使用的情况。

3、如何写好代码

关于具体怎么写代码，下面主要从两个维度来进行介绍：

（1）代码也是一种表达方式

在一个项目中，软件的维护成本远远高于开发成本，而且超过50%的项目时间都是用于沟通。常规意义的沟通方式，主要有面对面交流、Email邮件、文档或网络电话会议等。

但其实代码也是一种沟通方式，在计算机早期，我们使用机器语言或汇编语言，更多考虑代码如何更高效率地执行，然而，随着技术的进步，代码编译器逐渐完善，我们写代码时，更多的是要考虑如何让其他人看得懂、看得清楚。
于是编程规范就应运而生了，编程规范主要包含：

• 如何规范的表达代码
• 语言使用的相关注意事项

基于编程规范，看代码的理想场景是：

• 看别人的代码，感觉和看自己的代码一样。
• 看代码时能够专注逻辑，而不是格式方面。
• 看代码时不用想太多

（2）代码书写过程中的细节问题
关于代码数学过程中的细节问题，我们将从模块、类和函数、面向对象、模块内部组成、函数、代码注释、代码块、命名、系统的运营等。

（1）关于模块

模块，是程序的基本组成单位。
在一个模块内，会涉及到它的数据，函数或类。
对于Python、Go、C语言这样的程序来说，一个后缀名为.py、.c、.go的文件就是一个模块。每一个模块需要有明确的功能，需要符合紧内聚、松耦合。

关于模块切分的是否合理，对于软件架构的稳定起着至关重要的作用。

切分模块的方法，先区分数据类的模块和过程类的模块。
数据类的模块，主要是要完成对数据的封装，封装往往是通过模块内部变量，或类的内部变量来实现的。
过程类的模块，本身不含数据，可以从文件中去读取一个数据，或执行一些相关的操作。过程类模块，可以调用其他数据类模块或过程类模块。

编写程序时，我们需要注意减少模块间的耦合，从而有利于降低软件复杂性，明确接口关系。

（2）关于类和函数

类和函数，是两种不同的类型，有它们各自适用的范围。
另外，遇见和类的成员变量无关的函数时，可以将该函数抽出来，作为一个独立的函数使用，这样便于未来的复用。

（3）关于面向对象

面向对象是一个优秀的编程方法和范式，但是真正理解的人并不多，面向对象的本质是数据封装，这就要求我们，在写程序的过程中应该从数据的角度开始想问题，而不是从执行过程的角度开始想问题。

同时，我们需要注意一个普遍的错误认知，即C语言是面向过程的，C++是面向对象的，实际上，C语言也是基于对象的，C和C++的区别，主要是没有多态和继承。

C++是一个经常被滥用的语言，因为C++有太强的功能，作为软件工程师，我们最重要的任务是去实现我们所需要的功能，语言只是一种解决问题的工具。

我们应该谨慎地使用多态和继承，如果一个系统中，类的继承超过三层，那么这个系统的复杂度便很难把握。

有这样一个悖论，很好的继承模型是基于对需求的准确把握，而我们的初始设计阶段往往对需求理解的透彻。

系统在初始阶段，可能只是一个很简单的原型，然后通过不断地迭代完善，才逐步发展起来变好的。

（4）关于模块内部的组成

一个模块，比如.py、.c、.go这样的模块，其内部组成主要是：

在文件头中，需要对模块的功能进行简要说明，需要把文件的修改历史写清楚，包括修改时间、修改人和修改内容。
在模块内，内容的顺序尽量保持一致，以方便未来对内容的搜索查询，

（5）关于函数

函数的切分同样十分重要。
对于一个函数来说，要有明确的单一功能。
函数描述三要素，包括功能、传入参数和返回值

功能描述，是指描述这个函数是做什么的，实现了哪些功能。
传入参数描述，是指描述这个函数中，传入参数的含义和限制条件。
返回值描述，是指描述这个函数中，返回值都有哪些可能性。

函数的规模要足够的短小，这是写好程序的秘诀之一。
bug往往出现在那些非常长的函数里。

在函数头中，需要对函数的语义做出清晰和准确的说明。
我们需要注意函数的返回值，在写函数时，要判断函数的语义，确定返回值的类型。
基于函数的语义，函数的返回值有三种类型：

• 1.“逻辑判断型”函数
  “逻辑判断型”函数，返回布尔类型的值，True或False，表示“真”或“假”。
• 2.“操作型”函数
  “操作型”函数，作为一个动作，返回成功或者失败的结果——SUCCESS或ERROR。
• 3.“获取数据型”函数
  在“获取数据型”函数中，返回一个“数据”或者返回“无数据/获取数据失败”。

在这里，推荐一种函数的书写方式：

以“单入口、单出口”的方式书写，这种方式能够比较清晰地反映出函数的逻辑。
尤其是在实现多线程的数据表中，推荐使用一个内部函数来实现，“单入口 单出口”的方式。

（6）关于代码注释

要重视注释。
书写注释，要做到清晰明确，在编写程序的过程中，先写注释后写代码。

（7）关于代码块

代码块的讨论范围，是在一个函数类的代码实现。
书写代码块内的思路，是先把代码中的段落分清楚，文章有段落，代码同样有段落，
代码的段落背后表达的是我们对于代码的逻辑理解，包括代码的层次、段落划分、逻辑等。

代码中的空行或空格，是帮助我们表达代码逻辑的符号，并非可有可无。
好的代码，可以使人在观看时，一眼明了。

（8）关于命名

命名，包括系统命名、子系统命名、模块命名、函数命名、变量命名、常量命名等。

我们要清楚命名的重要性，命名重要的主要原因为：
1.“望文生义”是人的自然反应。不准确的命名会使人产生误导，
2.概念是建立模型的出发点。(概念、逻辑推理=>模型体系)

好的命名是系统设计的基础。
命名中普遍存在的问题有：
1.名字中不携带任何信息
2.名字中携带的信息是错误的

命名不是一件容易的事情，关系着代码的可读性，需要仔细思考。
命名的基本要求是：准确、易懂。
提高代码命名可读性的方式之一：在名字的格式中加入下划线、驼峰等。

（9）关于系统的运营

在互联网时代，系统非常依赖运营，并不是我们把代码写完调试通了就可以，在系统运营过程中，代码的可监测性非常重要，很多程序都是通过线上的不断运行、不断监测、不断优化而迭代完善的。

所以，我们在编写代码的过程中，要注意尽可能多地暴露出可监控接口。

对于一个系统来说，数据和功能同等重要。
数据收集很重要，数据量够大才能知道这个项目或这个系统的具体收益。

关于系统的运营，我们在设计和编码阶段就需要考虑系统的运营，也就要求：

• 提供足够的状态记录
• 提供方便的对外接口

2.1.5 怎样修炼成为优秀的软件工程师

通常，人们在判断一名软件工程师的水平时，都会用工作时间、代码量、学历、曾就职的公司等等，这类外部因素作为评判标准。

但事实上，修炼成为优秀的软件工程师，重要的因素有三点：

（1）学习-思考-实践

1.多学习

• 软件编写的历史已经超过半个世纪，有太多的经验可以借鉴。
• 技术更新进步迅速，要不断的学习进步。

2.多思考

• 学而不思则罔，思而不学则殆。
• 对于做过的项目要去深入思考，复盘写心得。

3.多实践

• 知行合一谓之善，要做到知行合一，我们大部分的心得和成长，其实是来自于实践中的经历。
• 在学习和思考的基础之上，要多做项目，把学到的理论运用到真正的工作中去。

（2）知识-方法-精神

互联网的发展日新月异，对于软件开发来说，知识永远在增加。
所以在变化快速的知识世界中，最好的方式是找到方法。

方法就是用来分析问题和解决问题的，虽然说起来简单，但是适合每个人的方法都需要自己去寻找和总结。

在大多数人的成长过程中，并不单单只是鲜花和掌声，更多的是和困难荆棘做斗争，而真正能做出成就的人，都有着远大理想和宏伟志向。

所以光有知识和方法往往是不够的，还需要有精神作为支撑。

下面列出几个精神理念：
1 自由精神、独立思想
人一定要有自己的思考，不要人云亦云，不要随波逐流。

2 对完美的不懈追求
不要做到一定程度就满意了，而是要去不断的追求一个更好的结果。

（3）基础知识是根本

唐朝著名宰相魏征曾经对唐太宗说过，“求木之长者，必固其根；欲流之远者，必浚其泉源”，充分表达了基础乃治学之根本。

对于一个软件工程师来说，需要掌握的基础知识是非常繁杂的，包括以下种种：

• 数据结构、算法、操作系统、系统结构、计算机网络
• 软件工程、编程思想
• 逻辑思维能力、归纳总结能力、表达能力
• 研究能力、分析问题、解决问题的能力等

这些基础的建立，至少也要5~8年的时间。

欲速则不达，希望可以沉下心来，尤其是在自己职业生涯开始的几年，将基础打好。这样，才能在未来有更长远的发展。

2.1.6《代码的艺术》课程总结

通过这部分的学习，我们了解了公司与学校写代码有很大的不同，消除了对程序员这个职业的误解，建立了对软件编程的正确认识，明确了作为软件工程师的修炼方向。

在最后，还需要强调一下几个要点：

• 软件工程师不等于码农，软件工程师是一个很有深度的职业。

• 代码，我们可以把它携程艺术品。最终成品完全在于我们自身的修养。

• 不要忘记我们为什么出发。我们的目的是改变世界，而不是学习编程或炫耀技术。

• 好代码的来源不是写好代码，好代码是系列工作的结果。

• 代码是写给别人看的，别人看不懂的代码就是失败的。

• 写好代码是有方法的。系统工程师至少需要学习8~10年的积累。希望能够沉下心来，把基础打好，提升能力。

---

2.2 Mini-spider实践

本部分将从两个方面来讲解Mini-Spider框架在实际场景下的使用和注意事项等问题：

2.2.1 多线程编程

2.2.1.1 数据互斥访问

多线程中数据互斥访问的情况非常常见，在真实的生产环境中，经常会有开发人员会将对一张表的“添加”和“判断是否存在”分为两个接口，这是一种非常常见的错误。

以下图中的代码为例，左边的代码是正确的写法，将添加和判断写进一个函数中，右边的代码是典型的错误代码，编写了两个函数，分别是添加和判断函数。事实上，这种将添加和判断写进一个函数，并且运行的实现机制，是同8086的底层指令集支持密不可分的。

2.2.1.2 临界区的注意事项

在代码中，用锁来保护的区域被称为临界区。
以下图代码为例，临界区为self.lock.acquire和self.lock.release两句话之间的区域。在使用临界区的时候要注意，不要把耗费时间的操作放在临界区内执行。

很多开发人员在编写多线程的时候，会将耗费时间很多的逻辑放入临界区内，这样会导致无法发挥多线程对于硬件资源最大化利用的优势。

2.2.1.3 I/O操作的处理

在多线程编程中，还要注意对于IO操作的处理。
首先，在编写代码的时候，要注意不能出现无捕捉的exception，
以下图最左边的代码为例，如果不对异常进行捕捉，那么一旦出现问题，就不会执行self.lock.release()语句，进而导致死锁的发生。

其次，因为异常处理是非常消耗资源的，所以我们也不能像图中中间的代码一样，将异常放在临界区内，要像最右边的代码一样处理。

2.2.2 具体细节处理

下面来讲解一下Mini-Spider过程中的细节处理问题，

2.2.2.1 种子信息的读取

很多开发人员会将种子信息读取的逻辑，和其他逻辑耦合在一起，这样是错误的。

以图中代码为例，虽然通过_get_seeds函数直接读取文件中的信息，并灭有书写错误，但是如果后续的开发中文件的格式发生了变化，那就需要重新回来修改这部分的代码。

通过上述代码可以发现，模块划分和逻辑的复杂程度是没有关系的。
即使是逻辑简单的代码，如果没有做好模块划分，也会变得难以维护。

2.2.2.2 程序优雅退出

在真实的应用中，很多开发人员在实现程序退出功能的时候，使用了非常复杂的机制，导致后期维护难度较高。
在实际应用中，可以使用Python系统库中，关于队列的task_done()和join()的机制，以下图中的代码为例，左边的代码就是使用了task_done()，中间的代码是主程序中的一种常规逻辑使用，右边的是对中间主程序的一种优化，增加了spider.wait()，让整个逻辑可读性更强，更容易被理解。

2.2.2.3 爬虫的主逻辑编码

下面来讲一下爬虫主逻辑代码，编写需要注意的地方：
很多开发人员编写的主逻辑，非常的复杂且难懂，事实上图中的代码就是一个爬虫的主逻辑的所有代码，可以看到，里面包含了六个步骤：
第一步：从队列中拿到任务
第二步：读取内容，如果读取内容失败，则重新读取。如果读取成功，则执行第三步。
第三步：存储数据，
第四步：检查数据深度
第五步：如果数据深度不足，就进一步解析，并且放到队列中
第六步：结束任务

通过对六个步骤的编写和分析，可以看到好的代码是可以很快理解的，可读性是非常好的，这是开发人员在编写代码中需要注意的一个点。

---

2.3 代码检查规则背景及总体介绍

2.3.1 代码检测的意义

1 提高代码可读性

• 规范统一
• 方便他人维护
• 长远来看，符合公司内部开源战略

2 发现代码缺陷

• 帮助发现代码缺陷，弥补人工代码评审的疏漏
• 节省代码评审的时间与成本

3 提前发现问题

• 有助于提前发现问题，节约时间成本
• 降低缺陷修复成本

4 规范制定与准入检查

• 促进公司编码规范的落地
• 在规范制定后，借助工具进行准入检查

5 提升编码规范可运营

• 提升编码规范的可运营性
• 针对反馈较多的不合理规范进行调整更新

2.3.2 代码检查场景及工具

1 代码检查场景

首先是本地研发环节，借助客户端工具，在push发起评审之前进行检查。
若本地代码扫描没有出现问题，就进入第二个环节，代码准入环节，即为Code Review，这一环节进行增量检查，属于公司强制要求。第三个环节，持续集成环节Agile，当代码合入到代码库之后进行全量检查，业务线根据自身需求来配置。

2 代码检查工具与服务

代码检查的产品、客户端、SCM(icode)、CI(Agile)之间具有交互性，共同构成整个代码检查环节。

3 代码检查覆盖范围

在覆盖语言方面，代码检查目前已经覆盖了包括C++、Java/android、PHP、Python、Go、JS、OC、Kotlin等在内的几乎所有主流语言。

在检查维度方面，代码检查包括编码规范、代码缺陷、开源框架引用安全检查、可维护性(MI)。

4 代码检查速度

编码规范
只扫描变更文件，检查代码变更行是否复合规范，速度较快。

缺陷检查
需考虑文件依赖、函数调用关系、代码上下文等环节，因此相对耗时。

针对bugbye侧耗时的策略，默认超时时间10分钟，达到超时时间后，为了不影响代码合入，可选择“重新触发”或“跳过检查”。

2.3.3 代码检查规则分级

1 规则等级梳理

Code Review阶段，所有维度扫描出的问题，可以分为以下三个等级：
（1）Error

Error，属于需要强制解决的类型，影响代码的合入。
应视具体情况不同，采取修复、临时豁免、标记误报等措施及时处理。

（2）Warning

Warning，属于非强制性解决类型，不影响代码的合入。
但很可能存在风险，应尽量修复。

（3）Advice

非强制解决类型，级别相对较低，不影响代码合入。
可以选择性修复。

2 机检任务统一

在旧的模式下，旧的机器检查任务分类过多，缺乏重点，不契合用户需求，针对这一问题进行了调整，新模式下机器检查任务合并，评审页行间标注问题并分类显示。

3 评审页间行提示

评审业行间提示，指出具体的编码规范和缺陷检查。

4 针对豁免、误报、咨询的说明

豁免分为临时豁免与永久豁免。
临时豁免，本次检查临时豁免，下次遇到相同问题会再次报错，每人每月限额豁免10次，特殊需求可申请增加5次。

永久豁免，针对老代码迁移，机器生成文件等不适合按代码规范检查的情况，可申请永久豁免，由CMC审批。

标记误报
行间点击误报并填写理由，也可直接反馈服务号。

问题咨询
对扫出的bug有疑问，或者检查失败等，可通过服务号咨询。

---

2.4 代码检测规则：Python语言案例详解

这部分的主要内容分为两个部分，Python的代码检查规则与Python的编码惯例，内涵涵盖了共计34条代码检查规则与4个Python编码惯例。这些规则与惯例都将在未来的编码规则中被反复应用。

2.4.2 Python的代码检查规则

一套良好的代码检查规则，可以带来代码质量提高，降低缺陷修复和后期维护成本等一系列收益，这里为大家提供了一套完备的代码检查体系。

规定的Python代码检查规则中，主要分为四个大类，分别是：
1.代码风格规范
2.引用规范
3.定义规范
4.异常处理规范

（1）代码风格规范

这一大类的规范规则较为繁琐，具体有可细分为以下七个小类(共计17条规则)：

1.程序规范规模
(1)每行≤120个字符
每行不得超过120个字符
(2))函数长度≤120行
定义的函数长度不得超过120行，这意味着，在编写代码时，要时刻注意自己编写的程序规模，要避免冗余，确保简洁而高效。

2.语句规范
因为Python语言与其他语言不同，可以不需要明确的标识符标示语句的结尾，所以有以下规定：
(3)禁止以分号结束语句
(4)在任何情况下，一行只能写一条语句

3.括号使用规范
(5)除非用于明确算术表达式优先级、元组或者隐式行连接，否则尽量避免冗余的括号

4.缩进规范
(6)禁止使用Tab进行缩进，而统一使用4个空格进行缩进
在需要将单行内容拆成多行写时，我们规定
(7)与首行保持对齐，或者首行留空，从第二行起统一缩进四个空格

5.空行规范
(8)文件级定义(类或全局函数)之间，相隔两个空行；
类方法之间，相隔一个空行

6.空格规范
(9)括号之间均不添加空格
(10)参数列表、索引或切片的左括号前不应加空格
(11)逗号、分号、冒号前均不添加空格，而是在它们之后添加一个空格
(12)所有二元运算符前后各加一个空格
(13)关键字参数或参数默认值的等号前后不加空格

7.注释规范
(14)每个文件都必须有文件声明
声明必须包括以下三个方面的信息：

• (a) 版权声明
• (b) 功能和用途介绍
• (c) 修改人及联系方式

用文档字符串(docstring)进行注释时，规定
(15)使用docstring描述模块、函数、类和类方法接口时，docstring必须用三个双引号括起来。
(16)对外接口部分，必须使用docstring描述，内部接口视情况自行决定是否写docstring
(17)接口的docstring描述内容，至少包括以下三个方面的信息：

• 功能简介
• 参数
• 返回值

如果可能抛出异常，则特别注明会发生。

（2）引用规范

一个良好的代码风格，是程序员写出优美代码的基础，而当我们想要写出更为间接的代码，我们很难在不导入各种的模块、库与包的情况下完成它。

(1)禁止使用from ...import...句式直接导入类或函数
而应自导入库后再行调用，
(2)每行只导入一个库
(3)按标准库、第三方库、应用程序自有库的的顺序排列import
三个部分之间分别留一个空行。

（3）定义规范

下面我们将分别介绍各种定义的规范，具体可分为三个小类：
(1) 变量定义规范
(2) 函数定义规范
(3) 类定义规范

1.变量定义规范

在变量定义方面，我们有强制的规范规定：
①局部变量使用全小写字母，单词间使用下划线分割；
②定义的全局变量必须写在文件头部
③常量使用全大写字母，单词间使用下划线分隔

2.函数的定义规范
函数的定义规范，主要体现在函数的返回值，以及默认参数的定义上，为提高代码可读性，对于函数的返回值，规范要求为：
①函数返回值必须小于或者等于三个，若返回值大于三个，则必须通过各种具名的形式进行包装。

为了保障函数运行效率，以及降低后期维护和纠错成本，对于函数默认参数的定义有如下要求：
②仅可使用以下基本类型的常量或字面常量作为默认参数（整数、浮点数、bool、浮点数、字符串、None）

3.类定义的规范
类定义的规范，包括了四个方面的内容：
①类的命名，使用首字母大写的驼峰式命名法
②对于类定义的成员，protected成员使用单下划线前缀，private成员使用双下划线前缀。
③如果一个类没有基类，必须继承自ovject类。
④类构造函数应尽量简单，不能包含可能失败或过于复杂的操作

（4）异常处理规范

在代码编写中应该尽量避免代码异常状态的出现，然而错误有时也在所难免，对于这些异常状态的处理，有着明确的规范要求。
①禁止使用双参数形式或字符串形式的语法抛出异常
②如需自定义异常，应在模块内定义名为Error的异常基类，并且该基类必须继承自Exception，其他异常均由该基类派生而来。
③除非重新抛出异常，禁止使用except语句捕获所有异常，一般情况下，应使用except...语句捕获具体的异常
④捕捉异常时，应当使用as语法，禁止使用逗号语法。

2.4.3 Python的编码惯例

下面介绍几个常见的Python编码惯例，便于大家理解日后所见的代码：

它们分别是：

1.让模块即可被导入又可被执行

2.in运算符的使用

3.不适用临时变量交换两个值

4.用序列构建字符串

（1）让模块即可被导入又可被执行

Python不同于编译型语言，而属于脚本语言，是动态的逐行解释运行，没有统一的程序入口。

所以，为了方便模块之间的相互导入，我们通过自定义一个main函数，并使用一个if语句，if内置变量__name__=='__main__'，在这个if条件下，再去执行main函数，这样我们就能够实现，让模块即可被导入又可被执行。

（2） in运算符的使用

in是一种简洁而高效的运算符，很多时候，合理的使用in运算符，可以替代大量的重复判断过程，降低时间复杂度，提高代码的运行效率。

（3） 不适用临时变量交换两个值

Python有简洁而高效的语句，可以实现交换两个值的操作，并无必要引入临时变量来交换两个值。

（4） 用序列构建字符串

对于一个字符串列表、元组等，可以用序列来构建字符串，利用一个空字符串和join函数，可以避免重复，从而高效完成字符串的构建。