英文原文：The 7 Rules for Writing Software That Won’t Die When You Do
软件设计构造师 Karan Goel 在看到“joe”疯狂的成功之后，为我们总结了 7 个可以使软件寿命更长的规则，这其中包括：模块化、测试、持续集成、自动化等等。他表示遵循的规则越多，你软件的寿命就越长。下面一起来看看这些规则背后的细节。
以下为译文：
在“joe”疯狂的成功之后，我列出了一个我认为评判好坏软件的清单。尽管这使我对事物看得很清楚，然而对于任何给定的项目，很少有可以遵循这些规则的，包括我自己在内。但是你遵循的规则越多，你软件的寿命就越长。
什么让你远离编写好的代码？“快速打破事物”不是一件好事吗？
不！学习创建软件是一种技巧，任何人都能做到。而学习创建好的软件则是一种艺术，它需要时间、努力和奉献精神。
你希望世界上有更多的 SEGFAULTs（段错误）吗？你希望系统管理员因为你的糟糕代码而不断的被电话骚扰吗？你希望你的 PM 是因为你的软件惹毛了用户而记住你吗？……
我并不反对任何形式的快速发展，因为我相信 MVP 和第一时间推出的力量。但是在某些时候，当时间充裕的时，你必须要意识到低质量代码是走不远的。
当你走进医生办公室时，医生会询问你一系列问题来确定你的病因，他们不会在没诊断的情况下给你开药。
同样，知道在什么时间“写坏了”软件对你很重要。这里有些问题可以很好的帮助诊断我们是否正在编写糟糕的软件：
因此，让我们来看看本文所说的规则有哪些？
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 脚本来自动化处理它们：
5. 信息冗余
冗余版本控制，不要仅依赖于 Github，使用多个同步的站外远程，增加信息冗余
当你访问 git-scm.com 时你会看到这么一段话：
Git 是一个免费和开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
在这段话里，分布式是关键。
如果你把代码仅仅托管于 Github 的话，或许你应该需要反思了。试想一下，但凡 Github 有一点故障，你的工作流程将会停止。你无法预料到意外何时会出现，所以保持代码的离线备份永远都不会是一个坏注意。这种情况下信息冗余对你而言是一件好的事情。
这里提供一些代码存储的参考：
6. 提交
对于经常做出改变、提交和推动的人来说使用合理的提交信息是很有必要的。
看看你提交的历史，你会发现类似这样的信息：
“fixed issue with module”
“fixed”指什么？“issue”又是什么问题？模块化有时哪个？
很多程序员多会把版本控制系统当作是一种备份，而不是维护历史的一种手段，充满这种信息的历史版本是没有用处的，除非你想去做检索文件。
如果你觉得很难去写好一个提交信息，或许可以参考以下几点：
7. 计划
制定一个计划为最坏的情况做准备，一旦真的出现问题，你该怎么做？所以在文档中详细的写下步骤。
即便遵循以上六个规则，也并不是意味着你的软件是不可战胜的。说不定由于什么或者是谁的过失，灾难就会降临。所以有一个计划是明智的，一个计划会让你看上去“很聪明”，事实也是如此。
最后
如果您并不相信这几个规则，回答以下两个问题：
如果你的回答是“No”，或许你应该再重新看一遍本文，与你的团队分享一下。
最后 Happy programming！！！
相关文章
