最近修bug的一点感悟
写在前面话
项目从13年1月份，现场开发，4月中旬，项目开发接近尾声，三个开发，留两个在现场，我被调回公司，5月份现场一同事离职，只有一个同事在开发，结果PM想让这一个同事承担余下的开发和bug工作，结果意外的这一同事离职，离职前一周，我又来现场，接手他的工作，还好bug比较简单，木有神马复杂的功能，从这修一周的bug来看，感想挺多的，随笔记录几点。
共用VS各自独立（复杂逻辑VS简单copy）
在4月调回之前，有一同事接手我的工作，后来这部功能需求有较大的变更，这一同事在回到公司经常给我说的一句话就是：“你写的那块代码，我全部重写了”，我听了之后第一感觉是需求肿么可能变化那么大，重写就重写吧，当然也有一点不爽，难道我写的代码就那么差劲，要重新写吗？
我的方式（共用）
那部分的场景，功能主页index.jsp，单个业务处理页面deal.html，批量处理界面batchDeal.html，我负责开发5个功能，每个功能都是这样的界面结构，单个业务处理和批量处理的界面有重复部分，我将重用的界面抽取出来，生成三个独立的界面，这么做的唯一目的就是提高界面的重用性，但是这样子也导致界面获取的逻辑变的复杂，需要认真的去看才能看明白，当时编写这块代码的时候，有方法及代码块这两个级别的注释，木有写这块的整体思路，这点是自己做的不够好，但是仔细看是能看懂的，需要时间。
同事的方式（copy、paste）
修改之后的，各个界面处独立，单个业务处理页面是单个的，批量处理的界面是批量处理的，所有关于这个大模块的功能都是这样子开发（共计16个功能，两个人完成），界面、js的代码功能逻辑相似，但各个界面都是自己，相同的名字，唯一不同的是这些界面、js放的路径不同，这种模式开发起来快、简单、复制、粘贴就OK，我个人觉得不足就是重用，重用性不好，记得以前一味大师说过，当写代码到复制、粘贴的时候，说明代码就需要重构了，也可能是时间来不急，同事只能这样子。
这样一来，如果界面或js（共用部分）木有bug最好，但是一旦有，那么那16个功能都会有，并且要去修改16个地方，在我修bug的时候，可是偏偏这一块的界面有问题，界面上的文字要修改、要加必填项提示和校验，这下可好了，要修改的地方可多了，一个一个去找吧，还好复制的有规律，比较容易，但是个人觉得通过抽象共用界面，只需要修改一个地方即可，但是代码逻辑可能相对copy、paste的方式复杂，但是也有它的好处。
自工作到现在，这个问题我也在想，那种方式更好呢？或者木有更好的，只有合适的吧。
JS文件拆分VS一个JS文件
我的方式
我喜欢的方式是按业务功能、JS功能拆分，达到松散耦合的目的，但是一定程度上可维护性不好，用同事的话说就是找一个方法还得找不同的文件中查找，很麻烦（这点在不规范的开发流程中确实存在，并且是相当的麻烦，有时候为了一个方法要翻好几个JS文件），但是，我觉得这个不是个神马问题了，因为规范的开发流程是可以避免的，现在会麻烦呢，是国为目前的开发流程或方式存在问题了（这个仅是个人看法）。个人觉得JS文件的拆分有一定的好处，一是重用的问题，按是职责单一，有人觉得js文件多了，但是可以部署的时候将js文件压缩成一个即可。
目前开发都是看需求，然后写代码，木有编写设计文档、也木有将脑中的想法落实到文档中去，JS文件、JSP分件的拆分随着自己心中的想法而写，时间久了，自己都可能搞不清楚，更不要说后续的开发者，目录划分、JS、JSP等文件的命名、及功能描述都需要落实到详细的设计文档都其它文档中去。当然后续的开发者不要一上来就是看代码，神马都不管，先搞代码，我觉得这个是开发人员最忌讳的，可是好多人往往这样子。
同事的方式
所有功能放到一个js文件中，个人觉得对于维护，只看代码，不关注文档的人，寻找某个方法简单、快速、容易，然而js文件内容量很大，达到上千行，滚动条长，翻着麻烦，且一个界面的功能放到一个JS中，导致一个JS文件承担的职责比较多，不太符合设计的一些原则。另外我也觉得一些用户可能只是经常使用一个功能点（可理解为一个操作，例如新增操作），只需要新增的JS，但是如果JS文件不拆分，导致你无论你需要那个功能都得引入所有JS代码，功能点或者功能（模块）之间耦合度比较高。
模糊查询不区分大小写
出现的bug列表中好几个是关于查询的问题，如果查询采用了like关键字，几乎所有的此类查询都区别了大小写，往往实际情况是不需要的，这些是吸取了教训，得记住我。
JSP、JS文件命名
小结
