为什么我们依然困于柏油坑？

《人月神话》发表了近30年了，柏油坑依然在那里。

如果软件零缺陷是个神话，为什么我们还始终将陷于Bug修复视为常态？为什么普遍认为软件是解Bug解出来的？ 虽然以前微软总被嘲笑补丁打不完，而我们也常常是在打补丁。 一个问题发生了，我们运用智慧的大脑先分析，再找方案！ 大部分情况想到的是以最小的代价修复Bug，从而新方案反而引入新Bug。如此往复，构成了程序员工作的主要内容。

为什么被外人视为创新前锋的软件开发者大部分都在解Bug！我想这个问题包含了至少三个原因：

  1. 专业技术的局限。开源对软件业的影响着实很大，核心技术的金字塔越来越低，越来越多的团队开始奉行拿来主义。拿来了，剩下自然是修修补补，解解Bug屈多了！

  2. 个人战术思考的局限，绕不开单纯在对"事"本身的思考，无法从技术背景及流程层面寻找对策。满足于对事的成功会阻碍更深入的思考。(这和经验对人的作用是一样的。)

  3. 公司制度（流程）层面的问题。很多人其实都能看到这个问题，毕竟自己大把的时光耗在解Bug上，有时还要加班加点，更严重地是拆东墙补西墙，太累！难道不能有其它的解决方法吗？当然，可是你的好方法很可能就会被否掉了，因为上面还有产品上线的压力！这就是制度上的问题了。

有了问题，再寻找对策！ 个人想到可以依循几个问题来思考：

  a. 如何提高基本功？如何运用工具提高生产力? (技术实力相当的比赛中，结果取决于谁的失误少!)

  b. 如何引导大家在动手前做一下技术分析？以前的行为和新的方案将如何运作？知道如何做到讲清楚，这中间的差距很可能就暗藏着风险。

  c. 是否可以筛选常常出现的问题，加以归类，分享经验，并使用工具辅助查找问题？

  d. 如何提高大家对产品技术的整体把握程度？ 交流、分享、讨论！

  e. 如何做到在工作中的训练? 及时发现问题，教育团队！

  f. 是否可以运用自动化测试提高产品质量？

  g. 是否要在动手前应评估一下风险？过于乐观会导致后期措手不及！