对工程快速迭代的思考

在小作坊式的软件公司从事软件开发的程序员经常有这样的想法：我年复一年做的工程大体都是一样的，很多时候仅仅是增加了一点功能，或者修改了一点功能或者换了一个平台而已。为什么总感觉没有做好或者感觉时间不够呢。

我在经历过无数次这样的感想后，总结出其实我们很多时候不是缺少计算机专业知识，而是缺少一种有效的工程快速迭代方法。下面我总结一下本人对工程快速迭代方法的思考：

深入理解现在所使用的架构。当然传统意义上软件架构我们大多采用MVC模式，但是对于程序员所接触的工程，很多时候是基于已有的架构做一些功能上的填充或者修改。假如此时采用只是熟悉自己需要修改的那部分功能架构，那么恭喜你，下次当你再对该工程进行迭代时，你依然会觉得它是一个陌生的东西。因此，与其每次花时间去熟悉，去查找，倒不如花点时间去彻底熟悉，包括架构，包括一些有用的算法等等。

归纳总结一些有用的插件比单纯去总结项目有用。在前期做一些必要的总结对后期的工程迭代是有好处的。懒人的做法是将之前的工程打包，需要用时去以前的工程中去摘取部分插件，部分文件或者部分函数，而实际上有效的方法是通过对之前工程的相关总结，提炼出好的算法模块，通用插件，组件模块，在后续的工程迭代中直接使用这些模块能够提高不少效率。

做好自己的工作，拒绝敷衍。小作坊式的开发模式最常发生的现象是程序员A给程序员B挖坑，然后程序员A又去给程序员C去填坑。由于不同项目所采用的架构或者总体功能大同小异，一般管理者会将程序员作为一个资源池，哪里需要就去哪里，这样导致程序员对自己所做的模块没有全身心投入，因为他知道，即使他做再好，后续也会也有人去接替他干活；即使他做再烂，后续也能找到人给他填坑。这种现象一般出现在项目都大同小异，并且都需要进行快速迭代的情形下。假如按照以上情景，导致的后果一般是，项目做的多，每一个项目都没有做好，从项目本身，没有达到预定效果；从程序员个人来说，没有达到进步的目的。

小作坊式的开发一般很少有代码review阶段，而且很多时候测试都是匆匆进行的，这就导致做出来的效果不理想，所谓的小步快跑，快速迭代一般只会导致项目迭代越来越糟糕，最后工程只有特定人能够进行维护。