一个BUG引发的...

        昨日，在使用Hadoop平台进行开发的时候，出现了一个令我百思不得其解的问题：

        解析字符串的时候，在context.write(key,value)之后，字符串居然会神奇的消失，写入文件的只有key的前一部分，而后面的包括value的值都神奇的消失了。理应说，就算是我key的字符串问题，那么value值也应该会写入的，但居然消失了！于是，开始如下假设：

        1、我第一反应是，会不会因为字符串太长，导致key把后面的内容都遗弃了，就像是溢出一样。但没有理由value的值也消失的。测了许久，排除了这个可能性。

        2、Hadoop平台处理中文不给力？那么，便是编码的问题了，但是，直接写入中文进行处理，是没有问题的，但应用在在整个流程中，却出现了问题。那么，应该会源头进行查找问题所在。

        3、是因为从mysql中提取数据后，写入hdfs中时，由于编码问题，而导致字符的混乱？于是，将写入hdfs文件的内容存入了另一个文件中，进行处理，没有问题！那么，问题一定出在将数据写入文件中这个阶段。

        4、是由于mysql来源的数据格式的问题，而导致字符编码的错误？于是，直接在程序中模拟相应的数据写入，执行后，依旧错误！

        5、那么，看来错误是在读完数据到写入数据的过程了。为了避免写入乱码，使用的是Text类来处理字符串，换了String.getBytes(“utf-8”)的方法，搞定！

        原来，当初为了偷懒，在网上看到了往hdfs中写入中文的方式：使用Text类来进行封装，然后调用getBytes()方法，便能够成功显示中文而不会出现乱码。兴高采烈的就继续下一步了，但Text是用于处理Mapreduce中的值的，为了能够处理数据，他会进行一些自己的字符串处理，如添加一些标示性的字符，而就是添加进的分隔符，导致了进行键值处理的时候，产生了错误。

        由这个问题，看出，偷懒、不求甚解，很容易导致后面的一系列的问题。程序员的许多工作，就是为了“懒”，为了达到“懒”的目的，而开发出了大量的用机器替代人力的程序，节省了劳动力。但“偷懒”则不同，“偷”这个词，本身含有贬义的一味，偷懒，则意味着在本不该懒的时候，却懒了，实则不该。一个是因懒而行动，另一个是行动时却懒。二者是有很大的差别的。

        为了调试一个程序，有时候会搞的我们焦头烂额，却徒劳无功，感觉这种行为纯粹是浪费时间，却又无法推脱，毕竟，程序是自己写的！我们要为自己的行为买单！但是，在我们在为疯狂的调BUG的时候，看看周围那些大牛，却噼里啪啦的敲着代码，似乎他们的程序不会出现BUG，或者至少不会出现这种莫名其妙的BUG。效率的差别，就在此处了。探其所以，一是技术原因。由于经常敲代码，使用某种语言，那么熟悉程度一定很高，效率自然提升。但这种方式对效率的影响仅限于前期，之后，就是另一个重要因素了：二是编程习惯。知识有限、能力无穷，一个好的编程习惯能够提高我们的效率。

        第一点就不多说了，原则是多练！

        关于第二点，有以下几点：

        1、先思考，再编码。程序员与代码似乎有一种怨恨又爱着的情节，一旦有一个新的任务，就迫切的想第一时间入手将它搞定。我现在渐渐形成了这种方式，每次在自己很兴奋地想要开始敲代码的时候，总是强迫自己淡定，先去构思整个流程，乃至细节算法，之后，再按部就班的用代码的方式将其实现。当我们在还未构思清楚就实现的时候，往往对于整体缺乏考虑，而仅仅考虑到某一局部的实现方式，甚至局部也是还没构思就开始动手。这就像是没有做好设计的建筑师，在匆忙的完成一堵墙之后，发现歪歪曲曲；甚至在完成了一间房屋之后，才发现与整体不协调，于是——拆！虽然对于程序来说，代价会小很多，但就在这种一拆一建的行为中，这种沉没成本便彰显了。效率之差，也就体现出来了。

        2、善于重构。这里所说的重构，并非将项目进行大规模重构，这是需要征求上头的意见的，而上头往往不会给你时间做这种事。我所说的重构，是对自己的项目进行重构，而重构的目的就是让程序的逻辑清晰。即便一开始我们有大局观，构思好如何实现，但越往后走，这个构思会随着实际实现中的偏差而有较大的改动，加之在实现中进行的妥协，那么，一开始清晰的设计会变得模糊，如果在这个时候，不悬崖勒马，暂缓自己前进的不法，项目会变得越来越乱，最后，你都无法清晰地看清楚整体的逻辑。而一旦逻辑开始混乱，随之而来的便是BUG的出现，各种莫名其妙的BUG，“每一个BUG都暗示你要重新审视自己的程序逻辑”，一个清晰的程序应该是很容易看出其中问题的程序。因此，每次出现BUG，我都会先回顾代码逻辑，看看有哪些地方设计的不好或者不对，多数情况下，问题都能够迎刃而解。

        3、写上必要的测试用例。在没有外界压迫的情况下，很难自觉地为每个类写上测试用例，因为这会耗费很多时间来换取未来可能节省的时间，人都的目光不会总那么长远。因此，对那些用的较多的，较为复杂的核心类尽可能写上测试用例，以便在今后修改的时候，无需再重新模拟数据，重新测试，或者因为测试不足而导致BUG。尽可能进行单元快的测试而非整体的测试，以减少测试时候等待的时间。甚至可以写上一些脚手架程序，来进行自动化测试。关于测试与重构，在这篇文章有提及：测试与重构，让我们活的更轻松

        4、善于使用工具调试。IDE中，可以进行断点调试、通过输出语句等方式进行调试，在此之前，我一直以为hadoop这种分布式框架是无法调试的，直到他们跟我说…

这些点，算是这个BUG风波引发的思考，也算是给自己提个醒，不仅仅是为了减少BUG，而是为了养成好的编程习惯、让程序逻辑清晰，而减少BUG，只是他带来的一个赠品罢了。