最近项目发展给我最大的感觉是，大家对 bug 抱有偏见。
出于项目管理与前期代码经营不足等原因，在版本发布临近之时，bug 猛增。其实 bug 多起来不是什么大问题，而且修复起来也挺快的，问题是为什么不能及早发现？直觉认为是测试在后期进行。但，提前让测试人员参与进来就能够解决问题吗？
在 bug 管理当中，是有分类的，人们对于不同种类的 bug 反应也是不一样的。例如对于一些 regression (倒退)表现得很严重。看似很合理的反应。
在某种程度上，开发的情绪是被测试牵引波动的。就像训练老鼠跑迷宫一样，电击多了就记得什么(错)路不能再走。但我怀疑这会不会导致开发会 LOST （迷失），忽略了代码中隐藏的各种信号，而依赖于测试反馈的信号。而据我观察，这种担忧不是多余，从开发修 bug 所改动的代码就可以看出。真是头痛医头，脚痛医脚，不报 bug，不修改。这里假设开发都不是应付式工作。这种对 bug 抱有偏见的状态所造成的问题，只要眼球足够多，迟早会以代码质量问题显现出来。那就是前一个现象发生的原因。
bug 不可怕，代码混乱才是问题，开发应该保持客观。显示 bug 是测试要做到事情，也是重要指标，但对于开发的，它也有指示作用，但肯定不是领头羊级的指标。开发要做的是书写良好的代码，让 bug 及早显现。不过也有一些外部因素，比如项目换血频繁，代码交接断裂，人员良莠不齐，普遍缺乏信托意识等等，都会造成累积的仅仅，仅仅是代码。
有良好的土壤，才能培育出丰厚的果实。
