软件包中的调试代码

上周一的一次Deliverable出事故了，一个DEV因为同时负责几个项目导致慌乱将某个软件包中的debug信息忘记去掉，发到客户那里被客户发现，在一个主要功能点上打开界面居然弹出4个Message box（DEV常用的调试方法），导致那个美国客户花容失色（想象的）。

背景是这样的，那天这个DEV本人接到了很多任务，而且都是跨项目的，他一共负责两个项目。其中有一个项目便要当天打包发给客户，于是他急急忙忙fix了一个bug后，便打包发出去了，然后马不停蹄的做下一个项目的debug工作。因为我们的项目的特殊性，调试是要用message box的，这位仁兄调试完了之后忘了把messagebox()的代码删掉，也没有自己测试一遍就打包发过去了。Tech-lead基于对这个DEV（确实技术很牛）的信任，看完邮件后直接发给客户，于是第一段的情况出现了。

我们的项目从技术上看是这样的。
1. 面向过程。
2. 工程文件只有一个xml文件。
3. 一个比记事本稍微好点的IDE。
4. 调试无法IDE跟踪，只能弹Message box显示变量信息。

多次事实证明，一个人在慌乱的时候或者心理状态不佳的时候，代码质量也不佳 [详见此] 。智商不高的客户怎么也不能理解在一个主要功能点出现类似于“0”,"f1"诸如此类的信息是怎么回事，于是自然愤怒。还好最后在我们的SDM和Tech-Lead的公关下解决了客户的不满。

说到这里我们的经验是什么：
1. 做任何事情不能慌乱。
2. 如果头脑迷糊，可以暂停工作，用冷水洗脸，清醒后继续。
3. 如果同时有多个项目在身，要一个一个的做，项目项目之间不能随意切换，否则大脑容易迷糊。
4. 不要在主版本上面调试，任何调试要在自己的版本上面调，调好后再merge到主版本上。这样从源头上阻止了调试代码的嵌入。
5. 任何debug完成之后，DEV不要过于自信而不测试，因为大脑不像电脑永远可以保持活力和“全面的思考”。
6. 在最后的软件版本完成之后打包之前，QA要做个全面的测试，至少smoke testing（冒烟测试）要覆盖所有的主功能点。
7. 在重要的包发出去之前，如果有必要的话在Tech-lead这里做一个“随机点击测试”。

经过这几层过滤下来，在软件包中含有调试代码的几率将大大减少。