[Turn] Software longevity rules, remember these 7 rules

http://www.iteye.com/news/30217

 

[Editor's note] After seeing the crazy success of "joe", software design architect Karan Goel summed up 7 rules for us to make software live longer, including: modularization, testing, continuous integration, automation, etc. Wait. He says the more rules you follow, the longer your software will last. Let's take a look at the details behind these rules. 

 

Here's the translation: 

After the insane success of " joe ", I've put together a list of what I think is good and bad software. While this makes me see things clearly, very few, myself included, can follow these rules for any given project. But the more rules you follow, the longer your software will last.

What keeps you away from writing good code? Isn't "breaking things fast" a good thing? 

Do not! Learning to create software is a skill that anyone can do. Learning to create good software is an art that takes time, effort, and dedication. 

Do you wish there were more SEGFAULTs (segmentation faults) in the world? Do you want sysadmins to be constantly harassed by phone calls because of your bad code? Do you want your PM to remember you because your software pissed off users? ... 

I'm not against rapid development of any kind, because I believe in the power of MVP and first-time launch. But at some point, when time is plentiful, you have to realize that low-quality code doesn't go far. 

When you walk into a doctor's office, the doctor will ask you a series of questions to determine your cause, and they won't prescribe medication without a diagnosis. 

Again, it's important for you to know when software "breaks". Here are some good questions to help diagnose if we're writing bad software: 

• Does updating software take a lot of time and effort?
• When you make a small change, does the whole system still run OK?
• Do you have fragmented code in your product and don't realize it's there until users complain?
• Do you know what to do when your system crashes - how to drill down into backups and deploy them?
• Do you spend a lot of time on certain things? Like moving between environments, or running the same command over and over again...

So let's take a look at what are the rules that this article is talking about? 

1. Modular 

quote

Working with buggy modules is much easier than working with the entire code

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

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

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

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

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

2. 测试 
我因不经常为我的代码编写测试而愧疚，所有的产品代码都需要测试 
我们习惯性的去把测试当作是一种不同于做软件的活动，即便是在学校，你被传授的是C++模块如何工作的，却没人教你它们是如何被测试的。 

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

何时编写测试各有喜好，只要写了就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！！！ 

原文来自：Medium