检查你的代码的质量，通过这些外部库使其更易维护。

可读性很重要。
— Python 之禅 The Zen of Python ，Tim Peters

随着软件项目进入“维护模式”，对可读性和编码标准的要求很容易落空（甚至从一开始就没有建立过那些标准）。然而，在代码库中保持一致的代码风格和测试标准能够显著减轻维护的压力，也能确保新的开发者能够快速了解项目的情况，同时能更好地全程保持应用程序的质量。

使用外部库来检查代码的质量不失为保护项目未来可维护性的一个好方法。以下会推荐一些我们最喜爱的检查代码)（包括检查 PEP 8 和其它代码风格错误）的库，用它们来强制保持代码风格一致，并确保在项目成熟时有一个可接受的测试覆盖率。

检查你的代码风格

PEP 8 是 Python 代码风格规范，它规定了类似行长度、缩进、多行表达式、变量命名约定等内容。尽管你的团队自身可能也会有稍微不同于 PEP 8 的代码风格规范，但任何代码风格规范的目标都是在代码库中强制实施一致的标准，使代码的可读性更强、更易于维护。下面三个库就可以用来帮助你美化代码。

1、 Pylint

Pylint 是一个检查违反 PEP 8 规范和常见错误的库。它在一些流行的编辑器和 IDE 中都有集成，也可以单独从命令行运行。

执行 pip install pylint 安装 Pylint 。然后运行 pylint [options] path/to/dir 或者 pylint [options] path/to/module.py 就可以在命令行中使用 Pylint，它会向控制台输出代码中违反规范和出现错误的地方。

你还可以使用 pylintrc 配置文件来自定义 Pylint 对哪些代码错误进行检查。

2、 Flake8

Flake8 是“将 PEP 8、Pyflakes（类似 Pylint）、McCabe（代码复杂性检查器）和第三方插件整合到一起，以检查 Python 代码风格和质量的一个 Python 工具”。

执行 pip install flake8 安装 flake8 ，然后执行 flake8 [options] path/to/dir 或者 flake8 [options] path/to/module.py 可以查看报出的错误和警告。

和 Pylint 类似，Flake8 允许通过配置文件来自定义检查的内容。它有非常清晰的文档，包括一些有用的提交钩子，可以将自动检查代码纳入到开发工作流程之中。

Flake8 也可以集成到一些流行的编辑器和 IDE 当中，但在文档中并没有详细说明。要将 Flake8 集成到喜欢的编辑器或 IDE 中，可以搜索插件（例如 Sublime Text 的 Flake8 插件）。

3、 Isort

Isort 这个库能将你在项目中导入的库按字母顺序排序，并将其正确划分为不同部分（例如标准库、第三方库、自建的库等）。这样提高了代码的可读性，并且可以在导入的库较多的时候轻松找到各个库。

执行 pip install isort 安装 isort，然后执行 isort path/to/module.py 就可以运行了。文档中还提供了更多的配置项，例如通过配置 .isort.cfg 文件来决定 isort 如何处理一个库的多行导入。

和 Flake8、Pylint 一样，isort 也提供了将其与流行的编辑器和 IDE 集成的插件。

分享你的代码风格

每次文件发生变动之后都用命令行手动检查代码是一件痛苦的事，你可能也不太喜欢通过运行 IDE 中某个插件来实现这个功能。同样地，你的同事可能会用不同的代码检查方式，也许他们的编辑器中也没有那种插件，甚至你自己可能也不会严格检查代码和按照警告来更正代码。总之，你分享出来的代码库将会逐渐地变得混乱且难以阅读。

一个很好的解决方案是使用一个库，自动将代码按照 PEP 8 规范进行格式化。我们推荐的三个库都有不同的自定义级别来控制如何格式化代码。其中有一些设置较为特殊，例如 Pylint 和 Flake8 ，你需要先行测试，看看是否有你无法忍受但又不能修改的默认配置。

4、 Autopep8

Autopep8 可以自动格式化指定的模块中的代码，包括重新缩进行、修复缩进、删除多余的空格，并重构常见的比较错误（例如布尔值和 None 值）。你可以查看文档中完整的更正列表。

运行 pip install --upgrade autopep8 安装 Autopep8。然后执行 autopep8 --in-place --aggressive --aggressive <filename> 就可以重新格式化你的代码。aggressive 选项的数量表示 Auotopep8 在代码风格控制上有多少控制权。在这里可以详细了解 aggressive 选项。

5、 Yapf

Yapf 是另一种有自己的配置项列表的重新格式化代码的工具。它与 Autopep8 的不同之处在于它不仅会指出代码中违反 PEP 8 规范的地方，还会对没有违反 PEP 8 但代码风格不一致的地方重新格式化，旨在令代码的可读性更强。

执行 pip install yapf 安装 Yapf，然后执行 yapf [options] path/to/dir 或 yapf [options] path/to/module.py 可以对代码重新格式化。定制选项的完整列表在这里。

6、 Black

Black 在代码检查工具当中算是比较新的一个。它与 Autopep8 和 Yapf 类似，但限制较多，没有太多的自定义选项。这样的好处是你不需要去决定使用怎么样的代码风格，让 Black 来给你做决定就好。你可以在这里查阅 Black 有限的自定义选项以及如何在配置文件中对其进行设置。

Black 依赖于 Python 3.6+，但它可以格式化用 Python 2 编写的代码。执行 pip install black 安装 Black，然后执行 black path/to/dir 或 black path/to/module.py 就可以使用 Black 优化你的代码。

检查你的测试覆盖率

如果你正在进行编写测试，你需要确保提交到代码库的新代码都已经测试通过，并且不会降低测试覆盖率。虽然测试覆盖率不是衡量测试有效性和充分性的唯一指标，但它是确保项目遵循基本测试标准的一种方法。对于计算测试覆盖率，我们推荐使用 Coverage 这个库。

7、 Coverage

Coverage 有数种显示测试覆盖率的方式，包括将结果输出到控制台或 HTML 页面，并指出哪些具体哪些地方没有被覆盖到。你可以通过配置文件自定义 Coverage 检查的内容，让你更方便使用。

执行 pip install coverage 安装 Converage 。然后执行 coverage [path/to/module.py] [args] 可以运行程序并查看输出结果。如果要查看哪些代码行没有被覆盖，执行 coverage report -m 即可。

持续集成工具

持续集成 Continuous integration （CI）是在合并和部署代码之前自动检查代码风格错误和测试覆盖率最小值的过程。很多免费或付费的工具都可以用于执行这项工作，具体的过程不在本文中赘述，但 CI 过程是令代码更易读和更易维护的重要步骤，关于这一部分可以参考 Travis CI 和 Jenkins。

以上这些只是用于检查 Python 代码的各种工具中的其中几个。如果你有其它喜爱的工具，欢迎在评论中分享。

via: https://opensource.com/article/18/7/7-python-libraries-more-maintainable-code

作者：Jeff Triplett 选题：lujun9972 译者：HankChow 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Ohcount 是一个简单的命令行工具，可用于分析源代码并打印代码的总行数。它不仅仅是代码行计数器，还可以在含有大量代码的目录中检测流行的开源许可证，例如 GPL。此外，Ohcount 还可以检测针对特定编程 API（例如 KDE 或 Win32）的代码。在编写本指南时，Ohcount 目前支持 70 多种流行的编程语言。它用 C 语言编写，最初由 Ohloh 开发，用于在 www.openhub.net 中生成报告。

在这篇简短的教程中，我们将介绍如何安装和使用 Ohcount 来分析 Debian、Ubuntu 及其变体（如 Linux Mint）中的源代码文件。

Ohcount – 代码行计数器

安装

Ohcount 存在于 Debian 和 Ubuntu 及其派生版的默认仓库中，因此你可以使用 APT 软件包管理器来安装它，如下所示。

$ sudo apt-get install ohcount

用法

Ohcount 的使用非常简单。

你所要做的就是进入你想要分析代码的目录并执行程序。

举例来说，我将分析 coursera-dl 程序的源代码。

$ cd coursera-dl-master/
$ ohcount

以下是 Coursera-dl 的行数摘要：

如你所见，Coursera-dl 的源代码总共包含 141 个文件。第一列说明源码含有的编程语言的名称。第二列显示每种编程语言的文件数量。第三列显示每种编程语言的总行数。第四行和第五行显示代码中由多少行注释及其百分比。第六列显示空行的数量。最后一列和第七列显示每种语言的全部代码行数以及 coursera-dl 的总行数。

或者，直接使用下面的完整路径。

$ ohcount coursera-dl-master/

路径可以是任何数量的单个文件或目录。目录将被递归探测。如果没有给出路径，则使用当前目录。

如果你不想每次都输入完整目录路径，只需 cd 进入它，然后使用 ohcount 来分析该目录中的代码。

要计算每个文件的代码行数，请使用 -i 标志。

$ ohcount -i

示例输出：

当您使用 -a 标志时，ohcount 还可以显示带标注的源码。

$ ohcount -a

如你所见，显示了目录中所有源代码的内容。每行都以制表符分隔的语言名称和语义分类（代码、注释或空白）为前缀。

有时候，你只是想知道源码中使用的许可证。为此，请使用 -l 标志。

$ ohcount -l
lgpl3, coursera_dl.py
gpl coursera_dl.py

另一个可用选项是 -re，用于将原始实体信息打印到屏幕（主要用于调试）。

$ ohcount -re

要递归地查找给定路径内的所有源码文件，请使用 -d 标志。

$ ohcount -d

上述命令将显示当前工作目录中的所有源码文件，每个文件名将以制表符分隔的语言名称为前缀。

要了解更多详细信息和支持的选项，请运行：

$ ohcount --help

对于想要分析自己或其他开发人员开发的代码，并检查代码的行数，用于编写这些代码的语言以及代码的许可证详细信息等，ohcount 非常有用。

就是这些了。希望对你有用。会有更好的东西。敬请关注！

干杯!

via: https://www.ostechnix.com/ohcount-the-source-code-line-counter-and-analyzer/

作者：SK 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

搜索代码库是开发者每天都要做的事情。从修改 bug 到学习新代码，或者查看如何调用某个 API，能快速在代码库中导航的能力都是一大助力。幸运的是，我们有专门的工具来搜索代码。pss 就是其中一个工具，让我们来看看如何安装和使用它吧。

什么是 pss？

pss 是一个帮你在源代码文件中进行搜索的命令行工具。pss 递归地在目录树中进行搜索，它能自动根据文件名和后缀判断哪些文件需要搜索，哪些文件不需搜索，并且会自动跳过那些你不会想搜索的目录（比如 .svn 和 .git），还能用色彩渲染输出以方便人们阅读，以及其他很多功能。

安装 pss

使用下面命令在 Fedora 上安装 pss：

 $ dnf install pss

安装好后就能在终端调用 pss 了：

 $ pss

不带参数调用 pss 或者带上 -h 标志会输出详细的使用说明。

使用案例

现在你安装好 pss 了，下面来看一些例子吧。

 $ pss foo

该命令只是简单的搜索 foo。你也可以限制 pss 让它只在 python 文件中搜索 foo：

 $ pss foo --py

还能在非 python 文件中搜索 bar：

 $ pss bar --nopy

而且，pss 支持大多数常见的源代码文件类型，要获取完整的支持列表，执行：

$ pss --help-types

你还能指定忽略某些目录不进行搜索。默认情况下，pss 会忽略类似 .git，__pycache__，.metadata 等目录。

$ pss foo --py --ignore-dir=dist

此外，pss 还能显示搜索结果的上下文。

$ pss -A 5 foo

会显示匹配结果的后面 5 行内容。

$ pss -B 5 foo

会显示匹配结果的前面 5 行内容。

$ pss -C 5 foo

会显示匹配结果的前后各 5 行内容。

如果你想知道如何使用 pss 进行正则表达式搜索以及它的其他选项的话，可以在这里看到更多的例子。

via: https://fedoramagazine.org/improve-code-searching-skills-pss/

作者：Clément Verna 译者：lujun9972 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在每一个程序员、项目管理员、团队领导的一生中，这都会至少发生一次。原来的程序员早已离职去度假了，给你留下了一坨几百万行屎一样的、勉强支撑公司运行的代码和（如果有的话）跟代码驴头不对马嘴的文档。

你的任务：带领团队摆脱这个混乱的局面。

当你的第一反应（逃命）过去之后，你开始去熟悉这个项目。公司的管理层都在关注着你，所以项目只能成功；然而，看了一遍代码之后却发现失败几乎是不可避免。那么该怎么办呢？

幸运（不幸）的是我已经遇到好几次这种情况了，我和我的小伙伴发现将这坨热气腾腾的屎变成一个健康可维护的项目是一个有丰厚利润的业务。下面这些是我们的一些经验：

备份

在开始做任何事情之前备份与之可能相关的所有文件。这样可以确保不会丢失任何可能会在另外一些地方很重要的信息。一旦修改了其中一些文件，你可能花费一天或者更多天都解决不了这个愚蠢的问题。配置数据通常不受版本控制，所以特别容易受到这方面影响，如果定期备份数据时连带着它一起备份了，还是比较幸运的。所以谨慎总比后悔好，复制所有东西到一个绝对安全的地方并不要轻易碰它，除非这些文件是只读模式。

重要的先决条件：必须确保代码能够在生产环境下构建运行并产出

之前我假设环境已经存在，所以完全丢了这一步，但 Hacker News 的众多网友指出了这一点，并且事实证明他们是对的：第一步是确认你知道在生产环境下运行着什么东西，也意味着你需要在你的设备上构建一个跟生产环境上运行的版本每一个字节都一模一样的版本。如果你找不到实现它的办法，一旦你将它投入生产环境，你很可能会遭遇一些预料之外的糟糕事情。确保每一部分都尽力测试，之后在你足够确信它能够很好的运行的时候将它部署生产环境下。无论它运行的怎么样都要做好能够马上切换回旧版本的准备，确保日志记录下了所有情况，以便于接下来不可避免的 “验尸” 。

冻结数据库

直到你修改代码结束之前尽可能冻结你的数据库，在你已经非常熟悉代码库和遗留代码之后再去修改数据库。在这之前过早的修改数据库的话，你可能会碰到大问题，你会失去让新旧代码和数据库一起构建稳固的基础的能力。保持数据库完全不变，就能比较新的逻辑代码和旧的逻辑代码运行的结果，比较的结果应该跟预期的没有差别。

写测试

在你做任何改变之前，尽可能多的写一些端到端测试和集成测试。确保这些测试能够正确的输出，并测试你对旧的代码运行的各种假设（准备好应对一些意外状况）。这些测试有两个重要的作用：其一，它们能够在早期帮助你抛弃一些错误观念，其二，这些测试在你写新代码替换旧代码的时候也有一定防护作用。

要自动化测试，如果你有 CI 的使用经验可以用它，并确保在你提交代码之后 CI 能够快速的完成所有测试。

日志监控

如果旧设备依然可用，那么添加上监控功能。在一个全新的数据库，为每一个你能想到的事件都添加一个简单的计数器，并且根据这些事件的名字添加一个函数增加这些计数器。用一些额外的代码实现一个带有时间戳的事件日志，你就能大概知道发生多少事件会导致另外一些种类的事件。例如：用户打开 APP 、用户关闭 APP 。如果这两个事件导致后端调用的数量维持长时间的不同，这个数量差就是当前打开的 APP 的数量。如果你发现打开 APP 比关闭 APP 多的时候，你就必须要知道是什么原因导致 APP 关闭了（例如崩溃）。你会发现每一个事件都跟其它的一些事件有许多不同种类的联系，通常情况下你应该尽量维持这些固定的联系，除非在系统上有一个明显的错误。你的目标是减少那些错误的事件，尽可能多的在开始的时候通过使用计数器在调用链中降低到指定的级别。（例如：用户支付应该得到相同数量的支付回调）。

这个简单的技巧可以将每一个后端应用变成一个像真实的簿记系统一样，而像一个真正的簿记系统，所有数字必须匹配，如果它们在某个地方对不上就有问题。

随着时间的推移，这个系统在监控健康方面变得非常宝贵，而且它也是使用源码控制修改系统日志的一个好伙伴，你可以使用它确认 BUG 引入到生产环境的时间，以及对多种计数器造成的影响。

我通常保持每 5 分钟（一小时 12 次）记录一次计数器，但如果你的应用生成了更多或者更少的事件，你应该修改这个时间间隔。所有的计数器公用一个数据表，每一个记录都只是简单的一行。

一次只修改一处

不要陷入在提高代码或者平台可用性的同时添加新特性或者是修复 BUG 的陷阱。这会让你头大，因为你现在必须在每一步操作想好要出什么样的结果，而且会让你之前建立的一些测试失效。

修改平台

如果你决定转移你的应用到另外一个平台，最主要的是跟之前保持一模一样。如果你觉得需要，你可以添加更多的文档和测试，但是不要忘记这一点，所有的业务逻辑和相互依赖要跟从前一样保持不变。

修改架构

接下来处理的是改变应用的结构（如果需要）。这一点上，你可以自由的修改高层的代码，通常是降低模块间的横向联系，这样可以降低代码活动期间对终端用户造成的影响范围。如果旧代码很庞杂，那么现在正是让它模块化的时候，将大段代码分解成众多小的部分，不过不要改变量和数据结构的名字。

Hacker News 的 mannykannot 网友指出，修改高层代码并不总是可行，如果你特别不幸的话，你可能为了改变一些架构必须付出沉重的代价。我赞同这一点也应该在这里加上提示，因此这里有一些补充。我想额外补充的是如果你修改高层代码的时候修改了一点点底层代码，那么试着只修改一个文件或者最坏的情况是只修改一个子系统，尽可能限制修改的范围。否则你可能很难调试刚才所做的更改。

底层代码的重构

现在，你应该非常理解每一个模块的作用了，准备做一些真正的工作吧：重构代码以提高其可维护性并且使代码做好添加新功能的准备。这很可能是项目中最消耗时间的部分，记录你所做的任何操作，在你彻底的记录并且理解模块之前不要对它做任何修改。之后你可以自由的修改变量名、函数名以及数据结构以提高代码的清晰度和统一性，然后请做测试（情况允许的话，包括单元测试）。

修复 bug

现在准备做一些用户可见的修改，战斗的第一步是修复很多积累了几年的 bug。像往常一样，首先证实 bug 仍然存在，然后编写测试并修复这个 bug，你的 CI 和端对端测试应该能避免一些由于不太熟悉或者一些额外的事情而犯的错误。

升级数据库

如果你在一个坚实且可维护的代码库上完成所有工作，你就可以选择更改数据库模式的计划，或者使用不同的完全替换数据库。之前完成的步骤能够帮助你更可靠的修改数据库而不会碰到问题，你可以完全的测试新数据库和新代码，而之前写的所有测试可以确保你顺利的迁移。

按着路线图执行

祝贺你脱离的困境并且可以准备添加新功能了。

任何时候都不要尝试彻底重写

彻底重写是那种注定会失败的项目。一方面，你在一个未知的领域开始，所以你甚至不知道构建什么，另一方面，你会把所有的问题都推到新系统马上就要上线的前一天。非常不幸的是，这也是你失败的时候。假设业务逻辑被发现存在问题，你会得到异样的眼光，那时您会突然明白为什么旧系统会用某种奇怪的方式来工作，最终也会意识到能将旧系统放在一起工作的人也不都是白痴。在那之后。如果你真的想破坏公司（和你自己的声誉），那就重写吧，但如果你是聪明人，你会知道彻底重写系统根本不是一个可选的选择。

所以，替代方法：增量迭代工作

要解开这些线团最快方法是，使用你熟悉的代码中任何的元素（它可能是外部的，也可能是内核模块），试着使用旧的上下文去增量改进。如果旧的构建工具已经不能用了，你将必须使用一些技巧（看下面），但至少当你开始做修改的时候，试着尽力保留已知的工作。那样随着代码库的提升你也对代码的作用更加理解。一个典型的代码提交应该最多两三行。

发布！

每一次的修改都发布到生产环境，即使一些修改不是用户可见的。使用最少的步骤也是很重要的，因为当你缺乏对系统的了解时，有时候只有生产环境能够告诉你问题在哪里。如果你只做了一个很小的修改之后出了问题，会有一些好处：

• 很容易弄清楚出了什么问题
• 这是一个改进流程的好位置
• 你应该马上更新文档展示你的新见解

使用代理的好处

如果你做 web 开发那就谢天谢地吧，可以在旧系统和用户之间加一个代理。这样你能很容易的控制每一个网址哪些请求定向到旧系统，哪些请求定向到新系统，从而更轻松更精确的控制运行的内容以及谁能够看到运行系统。如果你的代理足够的聪明，你可以使用它针对个别 URL 把一定比例的流量发送到新系统，直到你满意为止。如果你的集成测试也能连接到这个接口那就更好了。

是的，但这会花费很多时间！

这就取决于你怎样看待它了。的确，在按照以上步骤优化代码时会有一些重复的工作步骤。但是它确实有效，而这里介绍的任何一个步骤都是假设你对系统的了解比现实要多。我需要保持声誉，也真的不喜欢在工作期间有负面的意外。如果运气好的话，公司系统已经出现问题，或者有可能会严重影响到客户。在这样的情况下，我比较喜欢完全控制整个流程得到好的结果，而不是节省两天或者一星期。如果你更多地是牛仔的做事方式，并且你的老板同意可以接受冒更大的风险，那可能试着冒险一下没有错，但是大多数公司宁愿采取稍微慢一点但更确定的胜利之路。

via: https://jacquesmattheij.com/improving-a-legacy-codebase

作者：Jacques Mattheij 译者：aiwhj 校对：JianqinWang, wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

本文作者 肯特·贝克 Kent Beck ，是最早研究软件开发的模式和重构的人之一，是敏捷开发的开创者之一，更是极限编程和测试驱动开发的创始人，同时还是 Smalltalk 和 JUnit 的作者，对当今世界的软件开发影响深远。现在 Facebook 工作。

本周我一直在整理 Facebook 代码，而且我喜欢这个工作。我的职业生涯中已经整理了数千小时的代码，我有一套使这种整理更加安全、有趣和高效的规则。

整理工作是通过一系列短小而安全的步骤进行的。事实上，规则一就是如果这很难，那就不要去做。我以前在晚上做填字游戏。如果我卡住那就去睡觉，第二天晚上那些没有发现的线索往往很容易发现。与其想要一心搞个大的，不如在遇到阻力的时候停下来。

整理会陷入这样一种感觉：你错失的要比你从一个个成功中获得的更多（稍后会细说）。第二条规则是当你充满活力时开始，当你累了时停下来。起来走走。如果还没有恢复精神，那这一天的工作就算做完了。

只有在仔细追踪其它变化的时候（我把它和最新的差异搞混了），整理工作才可以与开发同步进行。第三条规则是立即完成每个环节的工作。与功能开发所不同的是，功能开发只有在完成一大块工作时才有意义，而整理是基于时间一点点完成的。

整理在任何步骤中都只需要付出不多的努力，所以我会在任何步骤遇到麻烦的时候放弃。所以，规则四是两次失败后恢复。如果我整理代码，运行测试，并遇到测试失败，那么我会立即修复它。如果我修复失败，我会立即恢复到上次已知最好的状态。

即便没有闪亮的新设计的愿景，整理也是有用的。不过，有时候我想看看事情会如何发展，所以第五条就是实践。执行一系列的整理和还原。第二次将更快，你会更加熟悉避免哪些坑。

只有在附带损害的风险较低，审查整理变化的成本也较低的时候整理才有用。规则六是隔离整理。如果你错过了在编写代码中途整理的机会，那么接下来可能很困难。要么完成并接着整理，要么还原、整理并进行修改。

试试这些。将临时申明的变量移动到它第一次使用的位置，简化布尔表达式（return expression == True？），提取一个 helper，将逻辑或状态的范围缩小到实际使用的位置。

规则

• 规则一、 如果这很难，那就不要去做
• 规则二、 当你充满活力时开始，当你累了时停下来
• 规则三、 立即完成每个环节工作
• 规则四、 两次失败后恢复
• 规则五、 实践
• 规则六、 隔离整理

尾声

我通过严格地整理改变了架构、提取了框架。这种方式可以安全地做出重大改变。我认为这是因为，虽然每次整理的成本是不变的，但回报是指数级的，但我需要数据和模型来解释这个假说。

via: https://www.facebook.com/notes/kent-beck/the-life-changing-magic-of-tidying-up-code/1544047022294823/

作者：KENT BECK 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

系统可以持续运行 5 年、10 年甚至 20 年或者更多年。但是，特定的代码行的生命，即使是经过设计，通常要短得多：当你通过各种方式来迭代寻求解决方案时，它会有几个月、几天甚至几分钟的生命。

一些代码比其他代码重要

通过研究代码如何随时间变化，Michael Feathers 确定了一个代码库的冥曲线。每个系统都有代码，通常有很多是一次性写成，永远都不会改变。但是有少量的代码，包括最重要和最有用的代码，会一次又一次地改变、会有几次重构或者从头重写。

当你在一个系统、或者问题领域、体系结构方法中有更多经验时，会更容易了解并预测什么代码将一直改变，哪些代码将永远不会改变：什么代码重要，什么代码不重要。

我们应该尝试编写完美的代码么？

我们知道我们应该写干净的代码，代码应该一致、清晰也要尽可能简单。

有些人把这变成了极端，他们迫使自己写出美丽、优雅、接近完美的代码，痴迷于重构并且纠结每个细节。

但是，如果代码只写一次而从不改变，或者如果在另一个极端下，它一直在改变的话，就如同尝试去写完美的需求和尝试做完美的前期设计那样，写完美的代码难道不是既浪费又没有必要（也不可能实现）的么？

“你不能写出完美的软件。是不是收到了伤害？并不。把它作为生活的公理接受它、拥抱它、庆祝它。因为完美的软件不存在。在计算机的短暂历史中从没有人写过完美的软件。你不可能成为第一个。除非你接受这个事实，否则你最终会浪费时间和精力追逐不可能的梦想。”

Andrew Hunt，务实的程序员: 从熟练工到大师

一次性写的代码不需要美观优雅。但它必须是正确的、可以理解的 —— 因为绝不会改变的代码在系统的整个生命周期内可能仍然被阅读很多次。它不需要干净并紧凑 —— 只要干净就够了。代码中复制和粘贴和其他小的裁剪是允许的，至少在某种程度上是这样的。这些是永远不需要打磨的代码。即使周围的其他代码正在更改，这些也是不需要重构的代码（除非你需要更改它）。这是不值得花费额外时间的代码。

你一直在改变的代码怎么样了呢？纠结于代码风格以及提出最优雅的解决方案是浪费时间，因为这段代码可能会再次更改，甚至可能会在几天或几周内重写。因此，每当你进行更改时，都会痴迷重构代码，或者没有重构没有改变的代码，因为它可能会更好。代码总是可以更好。但这并不重要。

重要的是：代码是否做了应该做的 —— 是正确的、可用的和高效的吗？它可以处理错误和不良数据而不会崩溃 —— 或者至少可以安全地失败？调试容易吗？改变是否容易且安全？这些不是美的主观方面。这些是成功与失败实际措施之间的差异。

务实编码和重构

精益开发 Lean Development 的核心思想是：不要浪费时间在不重要的事情上。这应该提醒我们该如何编写代码，以及我们如何重构它、审查它、测试它。

为了让工作完成，只重构你需要的 —— Martin Fowler 称之为 机会主义重构 opportunistic refactoring （理解、清理、童子军规则 ）和 准备重构 preparatory refactoring 。足够使改变更加容易和安全，而不是更多。如果你不改变那些代码，那么它并不会如看起来的那么重要。

在代码审查中，只聚焦在重要的事上。代码是否正确？有防御机制吗？是否安全？你能理解么？改变是否安全？

忘记代码风格（除非代码风格变成无法理解）。让你的 IDE 处理代码格式化。不要争议代码是否应该是“更多的 OO”。只要它有意义，它是否适当地遵循这种或那种模式并不重要。无论你喜欢还是不喜欢都没关系。你是否有更好的方式做到这一点并不重要 —— 除非你在教新接触这个平台或者语言的人，而且需要在做代码审查时做一部分指导。

写测试很重要。测试涵盖主要流程和重要的意外情况。测试让你用最少的工作获得最多的信息和最大的信心。大面积覆盖测试，或小型针对性测试 —— 都没关系，只要一直在做这个工作，在编写代码之前或之后编写测试并不重要。

（不只是）代码无关

建筑和工程方面的隐喻对软件从未有效过。我们不是设计和建造几年或几代将保持基本不变的桥梁或摩天大楼。我们构建的是更加弹性和抽象、更加短暂的东西。代码写来是被修改的 —— 这就是为什么它被称为“软件”。

“经过五年的使用和修改，成功的软件程序的源码通常完全认不出它原来的样子，而一个成功建筑五年后几乎没有变化。”

Kevin Tate，可持续软件开发

我们需要将代码看作是我们工作的一个暂时的手工制品：

有时候面对更重要的事情时，我们会迷信代码。我们经常有一个错觉，让卖出的产品有价值的是代码，然而实际上可能是对该问题领域的了解、设计难题的进展甚至是客户反馈。

Dan Grover，Code and Creative Destruction

迭代开发教会我们来体验和检验我们工作的结果 —— 我们是否解决了这个问题，如果没有，我们学到了什么，我们如何改进？软件构建从没有止境。即使设计和代码是正确的，它们也可能只是一段时间内正确，直到环境要求再次更改或替换为更好的东西。

我们需要编写好的代码：代码可以理解、正确、安全和可靠。我们需要重构和审查它，并写出好的有用的测试，同时知道这其中一些或者所有的代码，可能会很快被抛弃，或者它可能永远不会被再被查看，或者它可能根本不会用到。我们需要认识到，我们的一些工作必然会被浪费，并为此而进行优化。做需要做的，没有别的了。不要浪费时间尝试编写完美的代码。

作者简介：

Jim Bird

我是一名经验丰富的软件开发经理、项目经理和 CTO，专注于软件开发和维护、软件质量和安全性方面的困难问题。在过去 15 年中，我一直在管理建立全球证券交易所和投资银行电子交易平台的团队。我特别感兴趣的是，小团队在构建真正的软件中如何有效率：在可靠性，性能和适应性极限限制下的高质量，安全系统。

via: https://dzone.com/articles/dont-waste-time-writing

作者：Jim Bird 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出