BUG之虐之思考篇

   在上一篇博客中《BUG吐槽篇》小编是狠狠的吐槽了我们出现BUG的外部原因，为什么外部原因就叫做吐槽而内

内部原因就叫做思考呢？因为外部的事情我们程序员无法控制啊！只是有力吐槽，无力回天啊，而对于内部出现原因

就需要我们好好的思考，避免以后出现同样问题。

   妄加猜测

   当组长交代给我们一个任务的时候总是在最后说一句“平台组是个性化开发，但是有什么想法一定要说出

来”，这就是为了避免组长让你画一只猫，结果你觉得不好用了自己毕生的内功画了一只老虎，自己感觉成就满满

的，结果到了组长哪弄了个灰头土脸的回来了。

  其实这是程序员的一个通病，在知道了部分需求后在开发的过程中觉得需求这不好哪不合适，然后自己就根据自

己天马行空的想象修改需求，这本身没有错，错就错在我们修改需求后不和人家需求商量，导致的结果就是最后验收

的时候双方都非常的生气，但是我们胜利的时候比较少，只能乖乖的修改自己的代码，这就给自己无形中增加很多的

代码量，典型的受累不讨好啊。

   不谋全局

   因为现在都是团队开发，每个人都会负责相应的模块，这时候的开发人员都自己顾自己，不论是类的抽象还是

实体的封装，大家都是自己管自己，从来不从全局出发考虑代码的复用性，导致大量代码冗余，这时候一点小的改动我们需要修改很多的地方，既增加工作量又增加BUG数量，一旦你少修改一处就会导致BUG的出现。

   其实在这方面高级开发和初级开发是有很多的差别的，因为在我们项目中小编就是跟一个高级开发（文哥）一起合作开发模块，他对后台的逻辑和工作流是比较熟悉的，而小编对前端的这套新框架是比较熟悉的，所以我们经常

在一起交流需求，明显会感觉到站的高度不一样，并且有时候他会花费半天的时间来重构我们写的代码，给我们指出

这样写带来的弊端是什么？怎样能让我们在以后需求改动的时候能很快的做出变动。

  不够抽象

  很多时候复制、粘贴是屌丝开发的乐趣，因为我们不考虑后边的维护，觉得能复制粘贴的开发是非常有快乐的，

因为我们不用思考，只要做出一个来其余的就都会做了，就拿小编来说吧，项目中一个查看项目基本信息的需求，这

个东西需要我们跳转到另外一个解决项目中查看，这个需求在四个指引中都用到了，当时小编就传承了屌丝的气质，

也可能小编对这个新框架不是很熟悉，不知道怎样抽象成公共的。最后被文哥看到了，要求让我写成一个公共的

service，无奈小编花了一上午的时间改造，当时那个不愿意啊。到后来我们的传递的参数从两个变道三个了，这时

候小编就动了一个地方就完成改变，这时候才体会到抽象的好处啊。

  其实文哥他们同样的方法出现两个就开始考虑抽象成公共的方法，并且他们的扩展方法用的很是到位啊，写的代

码非常的简洁，有时候小编维护后台的时候有点吃力啊。可能看过《大话重构》这本书的童鞋们有共鸣。

   小编在思考程序出现这么多BUG时候总结以上三点，如果我们在一个项目中每个程序员都能做到这几点的话，基

本上项目没有什么特别变态的需求改变，我们后台的程序不会出现大的改动。这也是最近小编在项目中修改BUG的一

些体会，我们怎样从一个屌丝初级开发比较快的成为高级开发呢？技术当然是非常重要的，但是这些思想上的改变至

关重要，有时候我们的一些想法在高级人员来看就非常的幼稚和无语。我们在项目中完成需求是前提，更重要的是我

们需要和一些大牛们交流思想，这样我们会进步的更快。。。。