游戏开发团队并非蚂蚁协作（3）：开发过程中的“尾气”

“尾气”指的什么？

就像汽车虽然行驶到达目的，但是却会在路途中留下尾气污染环境。开发过程中有时虽然完成了需求，但是也留下了“尾气”，或者说“技术债”、“遗留问题”。

“尾气”并不是看不到或者难以被解决，而是因为开发者做事存在倾向，相比“处理尾气”，开发者肯定更倾向于“完成下一个需求”。

“尾气”所涵盖的面实际非常广。如果用最高的标准去要求，甚至任何开发都有尾气，只是有多有少。下面就举一些具体的例子。

举例

代码结构不好：毕竟实现一个需求的代码写法不是固定的。如果不考虑长远的情况只考虑眼前的目标，那么代码会更快写出来，但是这样的结构在未来进行扩展时却会遇到麻烦。

占用公共资源：举个例子，你们团队所有人将使用一个 编辑器 来进行日常的开发工作。而你为了完成一个目标，需要在编辑器的启动阶段做些事情，也就是让所有人每次打开编辑器时都要多等待一段时间。这样“多占用了大家的时间”就是一种“尾气”。当然，如果多等待的时间只有0.01秒，那完全没问题，但是若多等待几分钟，那可算是个“令人窒息的尾气”了。

遗留资源：有时因为“测试”或其他目的会创建一些资源，但是用过之后，就没必要保留，应该删掉的。但经常有没有删掉的情况，这就成了“尾气”。这些遗留资源可能不会造成严重的问题，但是却会让别人迷惑，也可能影响某些功能（比如某些功能需要遍历所有资源做些处理，那么就会遇到这个应该删除的资源，从而可能产生预期之外的情况）。

展现的信息不准确：例如，程序员对于一种错误的情况会显示一个报错：“XXX丢失”。这本是好事，能让别人发现问题进而处理。但是情况可能更复杂，比如XXX丢失可能在某些情况下是正常的，不需要处理的。这样就会让别人误解，从而白白浪费时间关注这件事。这种“不准确的信息显示”也是一种尾气。

功能使用难度较高：例如，你开发好了一个功能。但这个功能对于使用者而言，有一定的使用难度。这就会导致，他们自己使用会有更大的可能性出错，或者你会被更频繁求助。

引入更高复杂性：这里的“复杂性”包括很多，如“工程结构”上的复杂性或者“流程”上的复杂性，只要你让一件事“变得更复杂”了，那都算尾气。因为当事情变得更复杂后，就更可能出现问题。

缺乏文档说明：显然，只要你做的功能并非只与你自己有关，那它就一定需要文档说明。否则之后将会消耗你更多的时间向别人解释重复的问题，或者处理相关的问题。

积累&交叉

少量的尾气一般不会有什么危害，但当他们累积起来的时候却会造成明显的问题。例如：

• 一项功能必须让编辑器启动时多消耗2秒，这没什么。但是假如这样的功能越做越多，之后做了50个，那这样的话总共就要消耗近两分钟。试想，团队里的开发者每次打开编辑器都要白白等待两分钟，这将非常影响工作效率。
• 由于一种功能让某种资源的结构变复杂了，举个具体的例子，比如这个资源原来是一个列表，其中有若干图片。而现在变成了，这个资源中的元素变成了数字，数字索引到了另一个列表的图片。一般这样还能够理解。但是再往后继续变复杂，比如这个列表又进行了更多的嵌套与转换。那这个资源的理解成本就会越来越高，导致能看懂的人越来越少。

另外，不同方面的尾气也可能交叉造成更让人困扰的问题。例如：

• 一点遗留资源通常没问题。一些功能当碰到这些遗留资源时，通常也可以处理好。但假如出现了展现的信息不准确的情况，有一些不需要的报错，那可能就会让人误解。
• 如果一项功能使用难度高，且缺乏文档，且牵扯到流程很多，那么使用者就不可能通过自身去使用这个功能。

如何处理？

开发过程中的尾气是没法避免的：

• 所有的代码实现其实都只考虑了一定程度的情况，若把视野拉长到足够远，任何代码结构都有“不够好”而需要重构的情况。
• 所有功能都会在一定程度上占用某些方面的“公共资源”。
• 所有功能都会在某一方面引入一定程度的“复杂性”。

所以在开发时就完全避免掉尾气，是几乎不可能的。

在我看来，只能在观察到尾气已经造成了一定程度的破坏后，再下手（比如进行代码重构，或者针对某个问题进行优化）。

但是，当你发起对尾气进行处理的请求时，PM或者管理者有时并不能很好地理解。比如“优化编辑器一半的启动时间”这个是完全可以理解的，但是“优化某个功能的代码结构”，就不好理解。因为代码结构属于是只有相关程序员才能切身体会到的问题，而且他也没法用数据表现出来。

因此，只有那些能被人理解，并且有数据支持的“尾气处理”，才容易得到PM和管理者的支持。

也不能过度关注

不过，我们的目标并非“消灭尾气”，因为没必要，而且也不可能处理干净。

如果过度关注尾气（比如让代码考虑过于长远的情况，比如花费太多精力去优化一个小小的问题），那么就会陷入“过度开发”的问题。

所以，到底需要处理尾气到何种程度？似乎只能通过经验去权衡，而这恐怕是最困难的问题。

总结

开发过程中有时虽然完成了需求，但是也留下了“尾气”，或者说“技术债”、“遗留问题”。少量的尾气一般不会有什么危害，但他们会“积累”和“交叉”。

想要开发时就完全避免掉尾气是几乎不可能的。只能在观察到尾气已经造成了一定程度的破坏后，再下手。但是只有那些能被人理解，并且有数据支持的“尾气处理”，才容易得到PM和管理者的支持。

另一方面，也不能过度关注尾气，否则就会陷入“过度开发”的问题。这只能通过经验去权衡。