让你的软件永生的7个规则

标签: 业界观察 | 发表时间:2015-07-23 02:31 | 作者:techug
出处:http://www.vaikan.com

生命会逝去,但一个好的软件不会。

要想写出一个“永垂不朽”的软件,关键是你能否遵循以下规则:

1. 模块化

规则1:模块化。在一个模块中找 bug 总比在整个代码库里找简单得多。

人脑是极其复杂的生物,可以设计出能处理复杂问题的 CPU,但自我本身却处理不来这些问题。想要证明吗?那么告诉我,在不使用任何计算器,纯心算的条件下,你能算出 13*35 是多少么。我敢打赌,你不能。至少在短时间内你办不到。

但是,我们擅长将复杂的问题分解为更容易解决的问题。

13*10 是多少? 130。

13*5 呢?那就是 130/2=65。

130*3? 390。

390+65 是多少? 455。答案就是它了!

这就是如何分解问题的一个事例:将一个大型的复杂问题分解为一个个独立的小型的简单问题,从而快速得出正确的答案。

我们也可以按照同样的逻辑对待软件。模块化的代码不仅易于阅读,而且更容易调试。在大多数情况下,堆栈跟踪只会导致非常小的代码子集,而不是一下子出来个 1000 行代码的文件。甚至在更新某个特定模块时,也不需要捣腾整个系统——只要正在更新的那部分就可以了。

2. 测试

规则2:任何不经过测试的代码都是耍流氓。

很多人认为测试和写软件是两码事,即使是在学校中,教师会教你如何使用 C ++ 模板,却不会告诉你如何测试。在线教程能教你如何在 Brainfuck 制作 web 服务器,却不会说明如何测试。而这就是问题的所在。

有人说,我们应该在编写实际的应用程序逻辑之前就先写好测试。

但是在我看来,什么时候写测试其实并没有关系,只要写了就 ok。不要试图一步登天,不要想着刚开始就写得出完美的测试:从简单的起步。用蛮力方式测试(如 print(add(1,1)=2)),然后再测试对应语言的框架。

测试有助于我们了解软件的复杂性。你可以学到如何将软件模块化为可以独立的测试件。

3. 持续集成

规则3:使用持续集成。只要出现问题代码,就会通知你。

你写的测试,你必须确保可以应用于多种环境(例如 Python 的多个版本)。并且如果需要作出任何改动,也得测试。

当然你也可以手动操作命令行,但是使用持续集成的平台更方便,更快捷,成本更低。

4. 自动化

规则4:自动化。自动化可以减少步骤,节约时间。

我看到很多人会存储命令 txt 文件,以便需要的时候可以复制粘贴。我建议你不妨学习 bash 脚本(和/或 Python)。

以下是一些你必须自动化的 bash 脚本任务:

  • 将 README.md 转换为其他格式(取决于不同的分销渠道要求)
  • 自动化测试(包括创建模拟服务器和/或数据,删除临时文件等)。
  • 阶段化代码给开发服务器。
  • 部署到生产。
  • 自动化的更新依赖(特别是当更新有可能会破坏现有的 API 时,尤其要小心)。

5. 冗余

规则5:冗余版本控制:不要仅依赖于 Git,可以使用多个同步异地的远程遥控,增加冗余。

俗话说,鸡蛋不能放在同一个篮子里。如果你的代码只托管在 Github 上,那么一旦 Github 出现故障等,你的工作流程就会受影响。

给你个参考,我的代码是这么存储的:

  • 所有代码都放在 Dropbox 的“Codebase”文件夹中。自动同步变化。
  • 在 Github 也放上几乎所有的代码。
  • 最重要的代码,则同时放在两处比较秘密的地方。

你看,除非世界末日,不然我的代码怎么搞也不会丢失。

6. 提交

规则6:提交:做一点小小的改变,然后频繁提交,不要出现问题代码。

很多程序员将版本控制系统当作是备份方式,而非维护历史的一种手段。要知道,像这些历史信息是没用的,除非你想要做的只是检索文件。

在你提交改动信息一个星期后,因为发现引入了一个新的 bug,所以你需要恢复原先的内容。但是现在,因为你提交的信息已经覆盖了原先的信息,那么你就只能慢慢摸索原来是怎么写的了。

版本控制系统,正是为了防止出现这样的情况。

如果你觉得写出好的提交很难,那么可以按照下面这个模板走:

  • 每次提交都应该有一个目的。确定是修复 bug,添加新的功能,还是删除现有的功能?
  • 改动一次提交一次。
  • 提交信息包括发布排序号码。
  • 提交描述中应说明改动情况。这取决于项目的指导方针,通常包括是什么造成了 bug,如何修复,以及如何对改动进行测试。
  • 提交信息应写得明白易懂。

7. 计划

规则7:有计划:为最坏的情况作准备。如果确实出现了错误应怎么做?在文件中详细说明这些步骤。

即使照着上面的 6 条规则一丝不苟地执行,写出来软件也不可能尽善尽美。如果你曾这样想过,那就未免过于天真了。

不怕一万,就怕万一。

可以制定一个计划,为最坏的情况作准备。如果网站流量一下子太多了怎么办?出现未知 bug,导致系统瘫痪,可以到哪里去扒拉出备份?半夜三更服务器宕机,可以找谁?

好好考虑这些情况。但也不必过于杞人忧天。然后尽可能自动化可以自动化的步骤。

详细地记录到文档中。

结束

记住,你的软件是你的遗产。它能活得多久完全取决于你。So,软件是朝生暮死还是永垂不朽,就看你怎么做了。

相关 [软件 永生] 推荐:

让你的软件永生的7个规则

- - 博客园_新闻
英文原文: The 7 Rules for Writing Software That Won’t Die When You Do. 生命会逝去,但一个好的软件不会. 要想写出一个“永垂不朽”的软件,关键是你能否遵循以下规则:. 在一个模块中找 bug 总比在整个代码库里找简单得多. 人脑是极其复杂的生物,可以设计出能处理复杂问题的 CPU,但自我本身却处理不来这些问题.

Gmail不死,Gmail永生

- - SegmentFault 最新的文章
2013年7月,我们深爱着的Google Reader走了,一去不复返. 现在,我们形影不离的Gmail也要神秘失踪了吗. 不知不觉Mail客户端中Gmail邮箱已经快一个月没有收到邮件了,往日那些烦人的邮件此刻也都销声匿迹了,连CSDN的邮件都没有了,直觉告诉我有点不正常. 终于,在邮箱图标右边发现了一个小小的感叹号,原来连接有点问题,重连应该就可以了.

Web不会死,Internet倒是会永生

- cgeek - Beta Show
最近美国连线杂志主编Chris Anderson的《Web已死,Internet永生》这篇文章着实引发了很多大虾的思考,有很多人站在了对立面,并不支持Chris的“论调”. 我看完后倒是没有那么强烈的反应,毕竟,媒体习惯“标题党”,喜欢用极端的言论吸引眼球,我想在接下来的5到10年里,Chris Anderson也不会抛弃他认为已经死掉的Web(浏览器),100%拥抱Apps....

记忆传承,信息永生(一)

- Tong - 牛博国际
从五岁开始,把每天浓缩成两千字,一直写到一百零五岁. 那么,你一共写了七千三百万字,相当于一百部《红楼梦》. 这样,一万三千个你的一生,也只不过刚好能填满薄薄一片存储器,它只有指甲盖大小,只有半克重,一旦丢失,就可能再也找不到. 如果有人想要在一百年内读完这块小小存储器中的文字,他需要不眠不休,并且每秒钟扫过三百字才行.

信息不死,搜索永生

- - 钛媒体TMTpost—把脉科技资本论
最近看到好几篇文章说搜索引擎将死,理由是APP信息封闭、移动互联网上搜索式微、语音搜索大热等等. 其实,这些都是表象,把这些现象放到互联网发展的历史大潮中去看的话,搜索不但不会死亡,相反已经静悄悄渗入到多个领域,成为所有网站和应用不可缺少的部分. 在这些文章里,APP对搜索封闭信息、百度等搜索引擎无法抓取基于APP的数据,成为大家唱衰搜索的重要原因.

传统 Ajax 已死,Fetch 永生

- - SegmentFault 最新的文章
原谅我做一次标题党,Ajax 不会死,传统 Ajax 指的是 XMLHttpRequest(XHR),未来现在已被 Fetch 替代. 最近把阿里一个千万级 PV 的数据产品全部由 jQuery 的. $.ajax 迁移到 Fetch,上线一个多月以来运行非常稳定. 结果证明,对于 IE8+ 以上浏览器,在生产环境使用 Fetch 是可行的.

软件架构

- - 研发管理 - ITeye博客
    对于外包业务类型的项目,软件架构设计的目的与产品类型的项目有所不同,在这里主要讨论外包类型项目的软件架构设计目的.     1、为大规模开发提供基础和规范,并提供可重用的资产,软件系统的大规模开发,必须要有一定的基础和遵循一定的规范,这既是软件工程本身的要求,也是客户的要求. 架构设计的过程中可以将一些公共部分抽象提取出来,形成公共类和工具类,以达到重用的目的.

软件吞噬软件开发

- - PingWest中文网
软件蚕食世界,自互联网特别是移动互联网连接线上线下服务后,已成为不可逆的趋势. 每一项实用的服务可以由小团队来完成. 以WhatsApp为例,这款被高调收购的IM应用,拥有4.5亿月活跃用户,70%的日活跃率,至今还保持每天新增用户1000万的速度. 但这些服务居然由32名工程师支撑下来了,所以有了业界八卦“每位员工价值20亿”的说法.

《三体》系列:高潮遍体,BUG永生

- Carl.King - 宇宙的心弦
今天看书评看到了一篇三体III的评论《《三体3》:高潮遍体,BUG永生》,写的确实有道理,当时太激动太欣喜读得太快了,没有注意到那么多BUG. 现在把三体系列的有BUG的地方都放到这里来讨论一下吧:. 黑暗森林理论是整个《三体》系列的核心,有关黑暗森林理论的对错,似乎很多人仍然在争论吧,我个人是属于认为它是正确的那一派的.