文章背景：
今年七月份正式入职，公司主营ERP软件，楼主所在的组主要负责二次开发，使用的语言是Java。
什么叫二次开发呢？ERP软件的客户都是企业。而这些企业之间的情况都有所不同，一套标准版本的企业资源管理系统必然难以百分之一百地满足每一家公司的所有要求。所以，在客户提出需求之后，程序员对系统进行增减修改，这就是二次开发。
另外，我们组还负责修复客户报上来的各种漏洞。
学会如何添加新模块新功能
为什么说从头到尾只看代码是不可行的？
基本上，财务系统跨越的年限都会有十几二十年，代码数千万级别，更迭的版本多达十几个，更重要的是，连一份设计说明文档或者技术说明文档都没有。光看代码，根本就不可能准确地知道每一个类都是做什么的用的，类里面的方法是如何被调用，数据时如何流转处理的。
光靠猜，根本不可能猜出来。
熟悉代码的一个好方法就是做一个简单的新模块
以一个最简单的系统登录界面为例子（见上图），现在就来做一个练习：要求建立一个新的页面，把“物流管理系统”六个字改为“人事管理系统”，把“账号”改为“用户名”，把“密码”标签和栏位去掉，用户名正确即可直接登录。
代码都是现成了，直接新建相应的文件并且复制粘贴就行，再根据需求做更改。完成若干个这样的练习之后，就可以了解每个标签和栏位的作用，这是最快捷的方法。另外，我建议在看代码的同时写注释，有助于巩固记忆和加深理解。
复杂的功能要用到断点
如果把需求改为添加一个并不简单的功能呢？有的时候，我们可能不需要一个现成模块的所有内容和功能，只是把其中一个功能移植到另外一个模块当中去，显然是不可以简单粗暴地把所有的代码都复制过去，可是我们又不知道这个功能设计到哪些代码块，要怎么办呢？
这个时候，我们要用到断点（Break Point）调试。
如何添加断点，我这里就不赘述了，网上的教程一大把。如果有需要的话，我过几天找几篇好的综合一下给大家贴出来。
在调试的过程中，可以很轻松知道哪些方法牵涉其中，一一标记即可。
谈谈如何debug
首先，你要确定这到底是不是一个bug
一天，网管小明被一个上网的客人叫过去，说自己的QQ被盗了，肯定是在网吧的电脑中病毒害的，要求他负责。小明面无表情地按了一下键盘上的Caps Lock（大写锁定），然后让客人再输一次密码。然后，登陆成功。
上面举的这个例子是常识性的问题，但是很多时候用户犯的错误恰好是对系统的陌生，或者对业务知识的不熟悉。例如下面这么一个例子。前几天接到这么一个bug:用户要做一个付款单据，在付款单据页面中却读取不到。
这时候，如果我对这一个业务知识点不熟悉，很可能会先去查数据库，看是不是数据丢失了，或者是代码的问题，某一个筛选条件设错了。可当时我的第一反应就是，会不会他已经对该张欠款单做过付款单了？（ps:可以这么理解，一张欠款单已经做过了对应的付款单，意味着你们公司已经给对方付过钱了，不可能再付一次）
结果到他们的系统一看，果然如此。
在基本确定是一个漏洞之后，你最好能够在本地系统中重视这个故障
因为用户的系统都在使用当中，其中的数据也非常重要（分分钟几十万上下，出了问题码农搬十辈子砖都担不起），所以没办法任意地在用户的系统中做测试和验证。所以，你做好能够在本地系统中重视这个故障。
另外，在本地重视故障的过程中，你也会对这个故障发生的条件有一个更为全面的了解。例子：假设一天用户过来跟你说，他有这么一个瞬间，看太阳是绿色的，你就向他询问具体情况，以便重现。他告诉你说他昨天下午五点的抬头以仰角四十五度看太阳是绿色的，而且之前还连续看了三个小时的岛国爱情动作教育片。这个时候你就可以用同样的条件一试。如果试成功了，说明条件基本完全，如果不成功，还可以继续询问客户还是不是有其他的情况。
判断可能的方向，利用BreakPoint逐步缩小范围
在确定了客户所报上来的故障基本情况之后其实基本就可以知道bug可能的方向。例如前几天我接到了一个bug，说用户一直在用一个功能，平时都没事，知道周二那天下午突然就不行了。
查了相关的更新记录，那天并没有其他的同事对这个客户的代码进行更新，所以问题很有可能出现在数据库。后来发现，果然是用户做的一张单据的数量超过了系统限制，印发某个存储过程发生错误。
如果是代码方面的问题，我们可以用前面所讲过的断点测试逐步缩小可疑的范围，找到问题所在。例如一个数据发生了错误，我们可以从跟数据库交互的方法开始查看，直到最后显示数据的方法为止。参数传递过程中，可能中间经历了几个十几个，甚至几十个的方法，使用半分法设置断点就能够快速地定位问题的所在。
做完整的测试，证明自己的修复方案是正确可行的
一般来说，如果被一个bug纠缠了好几天，一旦找到了问题所在一定会高兴得要死，恨不得从椅子上跳起来。可这个时候，程序员们在欣喜之余要保持足够的冷静，因为你并不一定找到全部的答案，甚至根本就没有找到答案。
不止一次，我觉得我已经可以修复这个漏洞了，可当我以书面的形式提交修复方案的时候，总觉得不够有说服力，老大看到之后肯定会有所质疑。所以又缓了缓，再想了想，发现自己离发现问题的根本原因还差得远，更别提能够给出一个合理的解决方法。
所以我建议大家必须要在修复bug之后做完整的测试，直到证明自己的修复方案的确是完完全全地解决了问题，并且没有引入新的问题为止。
最后说几句题外话
好久没有写技术博客了。
正式上班其实也不算很忙，港资企业（深圳分公司）本来就节奏不快，再加上又不是互联网行业，加班几乎也就是意思意思，基本六点左右就可以走人。不过再怎样也没有在学校里面这么闲，所以前阵子就光忙着应付公司的培训，顾不上来博客园。最近总算开始适应了工作的方方面面，抽出空来写这篇文章，给自己前三个月做一个工作总结。
我有一个公众账号“华工小y”，每天都会分享自己工作的点点滴滴，以及业余爱好的林林种种，感兴趣的朋友可以关注一下。下面这条链接，是我前两天写的一篇文章，可以看一看。
（如果觉得这篇文章对你有帮助，可以轻轻点击下方的“推荐”按钮，同时也期待你的评论与楼主进行交流）