提问回顾
问题回答
问题1：为什么在一个ZBB之后，bug数会以惊人的数目反弹？
在团队项目中，在一个阶段发现了一群bug，当大家把这些bug一一修复后再进行测试，会出现一些之前没有发现的问题，并且可能由于之前的更改导致新的bug。想要一次性地顺利修复完所有bug并不如想象中容易。
问题2：项目中，不可避免会出现多个人修改同一个部分的代码而造成的Merge问题。盲目修改容易产生bug，而叫齐所有代码相关者一起修改时间成本又很高。该何如处理这个问题？
在我们团队中，采用了分工的方式，一般情况下很少出现不同人修改同一个代码的情况，即使有交集，也很少是会产生难以解决的问题的冲突。实在有问题的话，在群里、在小会议上讨论解决可以。
问题3：一个充分掌握软工规范的程序员与一个精于算法性能但代码可读性可扩展性等差的程序员，假设只能选一个，企业会更倾向谁？
在团队项目中，特别是接手其他人负责的部分，或者由于需要要去查看或者更改其他成员部分的代码时，如果该部分代码结构糟糕，会大大增加困难程度，对于持续开发来说，是一个很致命的问题，后期需要投入大量时间维护，也不容易交接项目。我认为对于大型项目来说，规范更加重要。
问题4：关于bug、完美与足够好：如何才算是一个足够好的程序？实现了主功能？在出bug时不致影响到关键数据？出bug的可能小？
我现在认为，如果一个项目，1、在当下与一段预计的未来时间中，bug不会显露或者基本不会造成影响 2、该ug出现几率小，即使出现，也能通过很小的代价恢复，不会影响正常使用。，应该能算得上一个足够好的程序。
做中学
- 需求阶段
调查了解用户需求，定位用户群，使用NABCD模型分析，对项目的整体方向做出指导 - 设计阶段
根据需求，对项目整体进行设计，确定项目的基本功能和特色功能 - 实现阶段
根据规范进行代码编写，注意文档的及时更新 - 测试阶段
代码覆盖率、单元测试、网站的抗压能力 - 发布阶段
推广模式十分重要，直接关系到项目的生死 - 维护阶段
日志文件的使用。积极建立与用户之间的联系，取得意见与建议
