软件长寿法则，记住这7条

英文原文：The 7 Rules for Writing Software That Won’t Die When You Do

软件设计构造师 Karan Goel 在看到“joe”疯狂的成功之后，为我们总结了 7 个可以使软件寿命更长的规则，这其中包括：模块化、测试、持续集成、自动化等等。他表示遵循的规则越多，你软件的寿命就越长。下面一起来看看这些规则背后的细节。

以下为译文：

在“joe”疯狂的成功之后，我列出了一个我认为评判好坏软件的清单。尽管这使我对事物看得很清楚，然而对于任何给定的项目，很少有可以遵循这些规则的，包括我自己在内。但是你遵循的规则越多，你软件的寿命就越长。

什么让你远离编写好的代码？“快速打破事物”不是一件好事吗？

不！学习创建软件是一种技巧，任何人都能做到。而学习创建好的软件则是一种艺术，它需要时间、努力和奉献精神。

你希望世界上有更多的 SEGFAULTs（段错误）吗？你希望系统管理员因为你的糟糕代码而不断的被电话骚扰吗？你希望你的 PM 是因为你的软件惹毛了用户而记住你吗？……

我并不反对任何形式的快速发展，因为我相信 MVP 和第一时间推出的力量。但是在某些时候，当时间充裕的时，你必须要意识到低质量代码是走不远的。

当你走进医生办公室时，医生会询问你一系列问题来确定你的病因，他们不会在没诊断的情况下给你开药。

同样，知道在什么时间“写坏了”软件对你很重要。这里有些问题可以很好的帮助诊断我们是否正在编写糟糕的软件：

• 更新软件花费很多时间和精力吗？
• 当你做一个很小的改变时，整个系统还会运行 OK 吗？
• 你的产品中是否存在碎片代码，并直到用户抱怨的时候才意识到它们的存在？
• 当你的系统崩溃时你知道要如何做吗——如何深入备份并部署它们？
• 你在某些事情上花费很多时间吗？比如在不同环境之间转移，或者重复运行着相同的命令……

因此，让我们来看看本文所说的规则有哪些？

1. 模块化

处理有 Bug 模块的工作要比处理整个代码轻松的多

虽然相比较有史以来最复杂的 CPU 来说，人类要更加的复杂，但是你不得不承认人类有时也会有无法解决的复杂问题，简单的来说，如果不使用任何计算器，你能告诉我 13x35 等于多少吗？我打赌你做不到，至少在一个合理的时间内你做不到。

但是我们擅长将复杂的问题逐步的分解为较小的我们能够解决的问题。

13x10 是多少？130，13x5 呢？即为 130/2=65。那么 130x3 是多少？是 390，390+65 呢？455。搞定！（PS：或许你会有更简单的方法。当问题越复杂的时候，分解的优势就越显而易见。）

将同样的逻辑运用到软件当中，通过多个文件、文件夹甚至是项目来划分你的软件，将所有相关性的事物遵循 MVC 或其他变化规律置于一个位置。

这不仅会提高代码的可阅读性，也会让你的调试变得更加容易。在大多数情况下，堆栈跟踪会领你前往非常小的代码集，而不是成千上万行的代码文件。当更新个别模块时，你就不需要考虑整个系统。

2. 测试

我因不经常为我的代码编写测试而愧疚，所有的产品代码都需要测试

我们习惯性的去把测试当作是一种不同于做软件的活动，即便是在学校，你被传授的是 C++ 模块如何工作的，却没人教你它们是如何被测试的。在线教程会教你如何使用 Brainfuck 制作一个 Web 服务，然而它们不会告诉你如何去测试它，这就是问题所在。

有些人会告诉你，在开始写实际的应用逻辑之前，首先要做的是编写测试。

何时编写测试各有喜好，只要写了就 OK。当你第一次开始的时候，不要试图成为一个测试高手，从简单粗暴开始，如 print (add (1, 1) == 2)，然后在逐步到测试整个框架。

当你开始测试你的代码时，你将会明白你软件的复杂性。你将开始学习如何将你的软件模块化，以便可能独立测试。所以当你遵循了这一规则的时候，你同时也在遵循第一个规则——模块化。

3. 持续集成

持续集成是伟大的，它们会在你添加 broken code（碎片代码）的时候通知你

当你编写测试之后，你需要确保它们是合格的，同时也要确保它们在多种环境下是合格的（例如多版本的 Python）。在代码作出任何改变时，你也需要测试。

当你能够手动的做这些时，你可以选择更方便、更快以及更便宜的持续集成平台。

Thoughtworks 在 CI 上有显著的贡献，关于 CI，你需要知道：

Continuous Integration（CI，持续集成）是一个开发实践，需要开发者每天数次的频率将代码集成到一个共享的库中，每一次入驻都会被自动构建归档，以便团队提早发现问题。这里推荐两个：TravisCI 和 Drone.io

4. 自动化

有多个脚步需要运行测试和部署？将它们添加在单一的 bash 脚步中，减少步骤，节约时间

大的项目通常会有一些像引导代码或以不同的方式测试代码等任务，又或者部署到不同的服务器，备份部分的代码等等。

有些人会使用 txt 文本来存储这些命令，并在需要的时候复制粘贴。如果你是这样的，或许你应该抽个时间来学习一下 bash 脚本（或 Python）。这里有些常见的任务，你应该用到简单的 bash 脚本来自动化处理它们：

• 将 README.md 转换为其他格式（取决于不同的分配路径需求）
• 自动化测试（包括创建模拟服务器或数据、删除临时文件等等）
• 开发服务器的阶段代码
• 部署到产品
• 自动从属更新（注意，这一点不是总能使用，尤其是当更新会打破现有 API 时）

5. 信息冗余

冗余版本控制，不要仅依赖于 Github，使用多个同步的站外远程，增加信息冗余

当你访问 git-scm.com 时你会看到这么一段话：

Git 是一个免费和开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

在这段话里，分布式是关键。

如果你把代码仅仅托管于 Github 的话，或许你应该需要反思了。试想一下，但凡 Github 有一点故障，你的工作流程将会停止。你无法预料到意外何时会出现，所以保持代码的离线备份永远都不会是一个坏注意。这种情况下信息冗余对你而言是一件好的事情。

这里提供一些代码存储的参考：

• 将代码存储与 Dropbox 的 Codebase 文件夹中，自动同步变化；
• 同时将代码存储于 Github；
• 将最重要的代码存于另外两个地方。

6. 提交

对于经常做出改变、提交和推动的人来说使用合理的提交信息是很有必要的。

看看你提交的历史，你会发现类似这样的信息：

“fixed issue with module”

“fixed”指什么？“issue”又是什么问题？模块化有时哪个？

很多程序员多会把版本控制系统当作是一种备份，而不是维护历史的一种手段，充满这种信息的历史版本是没有用处的，除非你想去做检索文件。

如果你觉得很难去写好一个提交信息，或许可以参考以下几点：

• 每个提交都应该有一个目的：修复一个缺陷、添加一个新特性或删除一个现有的特性等等；
• 每次仅提交一个改变；
• 在提交的信息中应包含问题编号；
• 提交说明中应对改变作出描述；
• 编写合理的提交信息，如：“fixed cache being reset on every insert caused by missed access after write. fixes #341”或“added a new form in header to make it easier to collect leads. close #3”。但是千万不要是这样：“remove stuff because why not.xoxo”

7. 计划

制定一个计划为最坏的情况做准备，一旦真的出现问题，你该怎么做？所以在文档中详细的写下步骤。

即便遵循以上六个规则，也并不是意味着你的软件是不可战胜的。说不定由于什么或者是谁的过失，灾难就会降临。所以有一个计划是明智的，一个计划会让你看上去“很聪明”，事实也是如此。

最后

如果您并不相信这几个规则，回答以下两个问题：

• 你希望一个新人加入你的团队，并能够很轻易的理解现有的代码吗？
• 重构代码是简单快速的吗？

如果你的回答是“No”，或许你应该再重新看一遍本文，与你的团队分享一下。

最后 Happy programming！！！

来自：http://news.cnblogs.com/n/514891/