代码二次开发，给别人擦屁股

进入外包公司的一个好处就是代码从来不需要从头写，对我这样出校园时间不长、对程序构建没什么把握能力（没经验）的人来说真的是一个比较好的锻炼机会（对那些刚出校园就敢从项目经理那里接项目做某某系统的人无限崇拜...）。

但是其弱点也同样明显，那就是：要给人擦屁股。经历了3、4个项目之后，真的是厌烦了这种工作：第一，项目负责人比较忙不能向你详细解说功能需求（可能他也不知道，并且极度缺少需求文档，就算有你也不敢相信那是否是符合客户要求的）；第二，代码缺少注释（就算有注释也不敢相信）；第三，负责人才不管你是新接手的，新需求来了他就当你是熟练掌握了系统需求的；第四，以前开发代码的要么是别的公司的，就算不是别的公司的要么离职，要么调离公司，就算联系上也会很不耐烦给你讲解。

下面介绍下我的心得体会：

第一，高屋建瓴详细了解需求。需求一定要搞懂，没搞懂就开工改代码是大忌（项目经理可以只要大略知道需求，但是程序员一定要搞清楚自己模块的需求，原因是写代码的人是你）。这里介绍搞懂需求的几个步骤：首先找文档，不管文档是否齐全，一定要找完该项目的所有文档，找出有关自己模块的资料（通常由于项目交接，资料不会完整的，我遇到过文档齐全但是里面没什么内容的情况）；其次，去烦项目负责人，这里有两个用意，让他知道你在搞清需求，让他知道你的难处（通常不要奢求能从他那里得到清晰的需求说明）； 再次对照需求跟踪代码，这是程序员搞懂需求的杀手锏，并且这个过程一定要有；最后把自己疑惑的地方拿出来，向负责人请教，如果他也搞不清楚，那就会去烦客户了。

第二，在有备份的情况下尝试稍微改动代码（改动功能）。备份是二次开发的一个重点，通常负责人那里会在每个节点上做备份，但是自己也要做好备份，不要一出问题就要从负责人那里重新拷贝代码，更不要随便改动配置库的代码（尤其是在项目刚启动的时候）。改动代码是为了更好的了解需求，了解代码结构。

第三，改动代码的时候怀疑一切。不要认为原来的代码是好的（即便客户信誓旦旦），不要相信功能运行正常是因为原来代码写的正确，不要相信代码注释的每一句话（即便他是特别明显），不要相信原来的功能实现是合理的。做到这几点出了问题就比较好查找了。

第四，不要随意改动原来的代码。即便你真的确认原来的代码有问题，也不要随意改动。正确的做法是，重写方法加注释（这里要合理运用复制粘贴）。

第五，代码重构可以私下里做，但是不要在客户版本里做（除非客户在需求里做了特殊说明，并且项目负责人对代码重构算了工作量）。二次开发的大项目（各个模块加起来的开发代码20W行以上）通常是一个悲剧，请不要在这个悲剧里加上你的名字。你可以复用以前的模块实现结构，不用管它合不合理，尽量不要实现自己认为合理的代码结构。原因是，你自己的代码风格会给后来的开发人员带来困惑（一个项目的代码风格的统一性很重要,并且没有大的付出很难改变）。

重点强调一下：程序员在二次开发中的重点是代码。神马文档啊、注释啊都是浮云！文档，注释是公司用来降低程序员薪水的。另外框架啊，模式啊，流程啊，测试啊，甚至包括Java都是用来降低程序员的薪水的！因此文档注释一类的东西在二次开发的代码中就随便写写吧（从这里你也知道了为什么要怀疑文档、怀疑注释、怀疑代码了吧）。

程序员是软件开发技术进步的第一阻碍力（要相信这句话）。