Reddit联合创始人教你避免软件开发中的错误(2)

　　实现过程中免不了会遇到一些实际问题，可能会需要多次修改设计，这时候还需要产品拥有者重新进行校订。

　　开发与测试

　　在开发中使用自动化测试是件好事，这样就能很容易地发现是否有错误发生。你觉得已经完成时也可以使用自动化测试来确保完全通过。当然，你需要确保自动化测试覆盖了所有控制和功能。

　　编程是一件很费心力的工作，所以程序员结对编程往往能更高效——一个输入，另一个观察并评论。(有时候 一个人写测试，另一个写代码来保证测试通过很有趣。)

　　当然你并不需要一直两个人一起编程，但你得保证有人来评估你的更改。你需要在提交代码之前审阅差异变化。

　　体系结构

　　如果你正在开发网络服务(比如Web应用)，你应该把它当做十二因子应用(Twelve-Factor Application)来设计。

　　十二因子应用的十二条原则如下：

　　1、整个应用的代码存储在一个版本的控制库里。如果你为软件的不同部分准备了多个版本库，你应该把他们当做是不同的应用，而他们之间互为服务。如果你将多个应用加入了同一个代码库，你需要找出它们共同的依赖库，并将它们分到两个代码库里。

　　2、明确声明依赖。在Ruby里你可以使用Gemfile，在Python里是requirements.txt，等等。本地你可以使用bundler和viirtualenv这样的工具来隔离环境来保证没有使用任何未声明的依赖。

　　3、所有配置值都应该当做环境变量存储。这里包括所有不适宜公开的东西：密码、密钥以及其它在部署间各不相同的东西包括数据库地址以及管理员账户等等。

　　4、所有支持服务(如数据库和内存里的缓存)都视为服务。对于本地和第三方服务没有任何区别：他们都通过网络访问。

　　5、代码分三个独立步骤部署：编译、释出和运行。

　　6、应用应该当做一系列无状态进程执行，所有进程都可以在任时候关闭。

　　7、应用应该是完全独立的，通过IP端口和外界通信，而不应该存在于某些大型进程里。

　　8、应用应该有很多进程类型组成，并且可以扩展更多进程类型。

　　9、进程应该是可任意使用的，你可以在任何时候启动或停止它，而不用担心任何破坏。

　　10、开发和产品间的隔阂应该尽可能地的小——相同的支持服务、依赖、团队应该在两处都被使用。

　　11、日志应该是无缓冲的和标准输出的事件流。

　　12、管理任务应该当做是一次性的进程。

　　部署要注意些什么

　　开发者应该在代码经过测试后提交到版本库中。如果代码会改变支持服务，这应该通过迁移来实现。迁移会描述如何制造或者回滚这样的改变。当新版本的软件部署后，所有没在运行的迁移开始运行，并同步这个版本的支持服务到它所依赖的代码里。回滚使得迁移也回滚，这保证支持服务和代码始终同步。

　　几乎所有的代码都提交到开发主线。这避免了不同分支痛苦的合并过程。因为所有大的变化都应该当做实验，如果变化未完成或者未准备好，可以通过禁止大部分用户来关闭它。当代码已经完善，更多的人就可以进入到这个实验群体里，开关也就因此可以永久地移除了。

　　确保每一块添加进产品里的代码都经过了产品拥有者的检查，他们需要控制产品发布。对实验的评估可以先从项目拥有者开始渐渐增加用户，直到所有的用户满意为止，此时才可以将实验中的控制器代码移除。

　　怎样发布更合适?

　　有人会建议你使用好莱坞式的试行，提前几个月公布发布日期并大肆炒作。这也许很适合好莱坞，但它并不适合软件发布，因为你的产品不会在剧院，而是在网上发布!你不用担心一周后剧院就不为你宣传了，只要在网上，你可以一直做推广，慢慢积累你的用户群。

　　除非你是个难得的天才，否则软件在推出当天肯定还是会遗留很多之前没有注意到的bug和概念错误，而现在数以百万计的用户会使用你的产品并遇到错误。

　　相反，你应该把发布当做是另一个实验，随着产品的进一步完善慢慢增加用户数量，GMail就是一个不错的案例。

原文转自：http://www.ltesting.net