2周修改了1000多个Bug后软件项目扭转了局面，未交付银行的现金管理系统健壮起来了

一方面是项目的工期紧急、另一方面也难做到公司招聘的程序员个个都是精英程序员，其次客户的需求变化、商业逻辑经常性的变更也导致系统的不稳定性、数据库模型的变化变化等等多多少少影响了程序的稳定性，再加上整体程序架构也相对复杂一些严格要求分层部署多台电脑。

毕竟一个软件公司的预算也是有限的、项目的利润空间也是有限的，否则可以来个招聘开发精英计划，找来几个技术真正过硬的月薪在20K以上的.NET程序员3-5个，绝对不会有产生1000多个Bug的这个事情，若还有这个事情那就不是精英开发人员了，他们应该编写出来的程序都是相对思路严谨、经验丰富、设计也会合理、经得起折腾、经得起客户的折磨了，否则也不会有那个身价了对吧。

1000多个Bug的由来（其实能测试出1000个多Bug也是需要一些水平的）：

1：在Bug管理系统里有200来个测试出来的Bug再修正中（广州、北京的业务测试人员录入）。

2：通过快速的地毯式的测试（3个人测试），Word整理的Bug文件40多个（按功能页面划分），总计数量500多个错误。

3：开会、软件功能投影、大家一起交流讲解功能，整理出来错误100个左右，简单的错误现场就修改好。

4：代码质量地毯式检查，检查出200个左右的编码规范方面的错误，有的当场修正好，有的写好备注限期整改。

管理好这些1000多个Bug也不太容易：

1：参与项目的人多了，就需要有良好的工具来管理、例如Bug管理系统，我们用了TFS来管理这些内容。

2：我们有一部分人在广州做测试，这些人主要是业务人员、实施人员，他们懂业务逻辑，但是不参与编码开发，他们把错误都输入到TFS里，通过WEB端。

3：北京也有一部分人在做测试，这些人也是业务人员，他们也是通过WEB端，把测试出来的错误输入到TFS里。

4：我在杭州家里直接参与开发工作，做编码质量检查工作，几乎每天检查一遍，每行代码都检查。

5：由于我们开发人员是多个，由项目经理统一指派分配错误给指定的开发人员，做到责任明确，分工合理一些。

6：有些快速测试的，页面性的错误，不涉及到业务功能，为了快速见效，直接输入到Word文件里。

7：这些错误的状态跟踪管理、错误修正情况的确认等等，需要有一定的管理指挥能力。

8：若这些错误我们自己不测试好，直接拿到客户那里，那一方面是丢人另一方面客户也会觉得我们国内的软件开发水平很差劲。

一个软件开发团队就像一个球队，指挥管理好非常需要水平，而且让球队能踢好球不是一般人能做得到的。

1：球队里未必是人人都是国际大球星，更注重的是整体的协调配合，全是国际球星也未必能赢得比赛。

2：踢球看起来很简单，但是里面的门道很多，特别是球队的比赛水平想提高一个层次，看看简单，真的亲自上场去踢球是要命的事情，不信你上去踢踢看。

3：球队需要有良好的分工、布局，才容易形成一个有杀伤力的球队。

4：球队需要有队长，有精神领袖、有教练、有一些统一的价值观、大家需要心齐。

5：很多人都觉得自己踢球不错，但是真正踢球好的人的不多，很多人连上场的资格也没有。

经过整个团队2周的拼命工作，本着为客户提供高质量的软件产品，提高我们国产软件的名誉，不制造垃圾软件项目的原则，我们20个人不到的团队，10个人不到的开发队伍，就把这1000多个错误都修正好了，大家心里也舒坦了很多，接下来可以有精力更关注业务功能的测试、开发、完善，大家时间没必要花在一些基础性的错误上了，测试人员接着也会更顺利一些。

其实有人可能会问，有1000多个Bug，是不是太多了？是不是有严重的问题？其实没有用统一的开发架构、没有用成熟的组件、没有用统一的高质量的代码生成器、没有采用统一的开发例子程序，就不只是1000多个Bug，我可以敢说可以测试出10000多个Bug来，我么还是有效的阻止了9000个没啥大用的基础性的Bug的出现。

还有可能，反正有1000多个Bug了，无可救药了干脆啥也别改了，那就等着赔偿合同，等着倒闭，等着倾家荡产就可以了，你要前进还是后退？你可以自己选择。

若一个软件，有一些明显的表面性的Bug，那这个软件绝对是有些低水平了。

为什么团队开发管理需要用良好的Bug管理系统？因为人多了，很容易乱套，更需要有节奏、有步骤、有计划，有目的的开展开发工作。

写博客说白了，就是为宣传自己，为了打广告，为了给需要找软件开发的客户方便找到我，让客户相信我有大规模软件开发管理能力，有按时交付能力，有丰富的开发管理经验，好在未来的几年里接上千万的软件开发项目，需要给兄弟们提供良好的未来，有源源不断的全国各地的软件项目合作。若不是为了这个才懒得写博客了，其实写博客都是有很明确的目，才能经得起别人的打击、辱骂、耻笑，才能坚持好几年坚持写博客。