python编写高质量代码_用 Python 编写干净、可测试、高质量的代码

用 Python 编写干净、可测试、高质量的代码

Noah Gift

2010 年 12 月 20 日发布

简介

编写软件是人所承担的最复杂的任务之一。AWK 编程语言和 "K and R C" 的作者之一 Brian Kernigan 在 Software Tools 一书中总结了软件开发的真实性质，他说，“控制复杂性是软件开发的根本。” 真实软件开发的残酷现实是，软件常常具有有意或无意造成的复杂性，而且开发人员常常漠视可维护性、可测试性和质量。这种不幸局面的最终结果是软件的维护变得越来越困难且昂贵，软件偶尔会出故障，甚至是重大故障。

编写高质量代码的第一步是，重新考量个人或团队开发软件的整个过程。在失败或陷入麻烦的软件开发项目中，常常按违反原则的方式开发软件，开发人员关注的重点是解决问题，无论采用什么方式。在成功的软件项目中，开发人员不但要考虑如何解决手中的问题，还要考虑解决问题涉及到的过程。

成功的软件开发人员会按照便于自动化的方式运行测试，这样就可以不断地证明软件工作正常。他们明白不必要的复杂性的危害。他们严格地遵守自己的方法，在每个阶段都进行认真的复查，寻找重构的机会。他们经常思考如何确保其软件是可测试、可读且可维护的。尽管 Python 语言的设计者和 Python 社区都非常重视编写干净、可维护的代码，但是仍然很容易出现相反的局面。在本文中，我们要探讨这个问题，讨论如何用 Python 编写干净、可测试、高质量的代码。

干净代码假想问题

演示这种开发风格的最好方法是解决一个假想的问题。假设您是某公司的后端 web 开发人员，公司允许用户发表评论，您需要设法显示和突出显示这些评论的小片段。解决此问题的一种方法是编写一个大函数，它接受文本片段和查询参数，返回字符数量有限的片段并突出显示查询参数。解决此问题所需的所有逻辑都放在一个巨大的函数中，您只需反复运行脚本，直到得到想要的结果。代码结构很可能像下面的代码示例这样，常常包含打印语句或日志记录语句和交互式 shell。

杂乱的代码def my_mega_function(snippet, query)

"""This takes a snippet of text, and a query parameter and returns """

#Logic goes here, and often runs on for several hundred lines

#There are often deeply nested conditional statements and loops

#Function could reach several hundred, if not thousands of lines

return result

对于 Python、Perl 或 Ruby 等动态语言，软件开发人员很容易一味专注于问题本身，常常采用交互方式进行探索，直到出现看似正确的结果，然后就宣告任务完成了。不幸的是，尽管这种方式很方便、很有吸引力，但是这常常会造成大功告成的错觉，这是很危险的。危险主要在于没有设计可测试的解决方案，而且没有对软件的复杂性进行适当的控制。

您如何确认这个函数工作正常呢？在开发期间最后一次运行它时它是正常的，您就此相信它是有效的，但是您能确定它的逻辑或语法中没有细微的错误吗？如果需要修改代码，会怎么样？它仍然有效吗？您如何确认它仍然有效？如果需要由另一位开发人员维护并修改代码，会怎么样？他如何确认他的修改不会造成问题？对于他来说，理解代码的作用有多难？

简单地说，如果没有测试，就不知道软件是否有效。如果在开发过程中总是假设而不是证明有效性，最终可能会开发出看似有效的代码，但是没人能够肯定代码会正确地运行。这种局面太糟糕了，我编写过这样的软件，也曾经帮助调试以这种方式编写的软件。幸运的是，很容易避免这种局面。应该先编写测试(比如测试驱动的开发)，否则在编写逻辑的过程中编写代码的方向会偏离目标。先编写测试会产生模块化的可扩展的代码，这种代码很容易测试、理解和维护。对于有经验的开发人员来说，很容易看出软件是否是在一直牢记着测试的情况下编写的。软件本身在高手看来差别非常大。

您不必听信我的观点，也不必直接研究代码，可以通过其他方法明显地看出这两种风格之间的差异。第一种方法是实际度量得到测试的代码行数。Nose 是一种流行的 Python 单元测试框架扩展，它可以方便地自动运行一批测试和插件，比如度量代码覆盖率。通过在开发期间度量代码覆盖率，会很快看出对于由大函数组成、包含深度嵌套的逻辑、以非一般化方式构建的代码来说，测试覆盖率几乎不可能达到 100%。

度量差异的第二种方法是使用静态分析工具。有几种流行的 Python 工具可以为 Python 开发人员提供多种指标，从一般性代码质量指标到重复代码或复杂度等特殊指标。可以用 pygenie 或 pymetrics 度量代码的圈(cyclomatic)复杂度(见 参考资料)。

下面是对相当简单的 “干净” 代码运行 pygenie 的结果示例：

pygenie 的圈复杂度输出% python pygenie.py complexity --verbose highlight spy

File: /Users/ngift/Documents/src/highlight.py

Type Name Complexity

----------------------------------------------------------------------------------------

M HighlightDocumentOperations._create_snippit 3

M HighlightDocumentOperations._reconstruct_document_string 3

M HighlightDocumentOperations._doc_to_sentences 2

M HighlightDocumentOperations._querystring_to_dict 2

M HighlightDocumentOperations._word_frequency_sort 2

M HighlightDocumentOperations.highlight_doc 2

X /Users/ngift/Documents/src/highlight.py 1

C HighlightDocumentOperations 1

M HighlightDocumentOperations.__init__ 1

M HighlightDocumentOperations._custom_highlight_tag 1

M HighlightDocumentOperations._score_sentences 1

M HighlightDocumentOperations._multiple_string_replace 1

什么是圈复杂度？

圈复杂度是 Thomas J. McCabe 在 1976 年开创的软件指标，用来判断程序的复杂度。这个指标度量源代码中线性独立的路径或分支的数量。根据 McCabe 所说，一个方法的复杂度最好保持在 10 以下。这是因为对人类记忆力的研究表明，人的短期记忆只能存储 7 件事(偏差为正负 2)。

如果开发人员编写的代码有 50 个线性独立的路径，那么为了在头脑中描绘出方法中发生的情况，需要的记忆力大约超过短期记忆容量的 5 倍。简单的方法不会超过人的短期记忆力的极限，因此更容易应付，事实证明它们的错误更少。Enerjy 在 2008 年所做的研究表明，在圈复杂度与错误数量之间有很强的相关性。复杂度为 11 的类的出错概率为 0.28，而复杂度为 74 的类的出错概率会上升到 0.98。

正如在此示例中看到的，每个方法都极其简单，复杂度都低于 10，这符合 McCabe 提出的原则。在我的从业经历中，我见过在没有测试的情况下编写的巨大函数，它们的复杂度超过 140，长度超过 1200 行。毫无疑问，根本不可能测试这样的代码。实际上甚至无法确认它是有效的，也不可能重构它。如果代码的作者一直牢记测试，在保持 100% 测试覆盖率的情况下编写相同的逻辑，就不可能出现如此高的复杂度。

干净代码假想解决方案<