项目里是给覆盖率定义了警戒线的，可我们却一直在覆盖率下面。

测试覆盖率为什么上不去？因为我们没有在那上面下功夫。为什么没有下功夫呢？因为我们没有预算。我们会有预算吗？不会，因为做测试应该是每天工作的一部分，是需要一直在后台执行的。

对与新写的代码，我很认同这一点，没有测试的代码，不能称之为代码。可是对于已经写过的老代码呢。我觉得我们需要预算，预算的目的是为了还过去欠下的技术负债。

虽然都是靠自己，但不同形式的尾部递归，在堆栈上的表现还是大有不同的。有的更容易造成堆栈溢出，而有的却相当友好。至于怎么优化，慢慢来看。

从最基本的概念说起，每个线程都有一个堆栈，这个堆栈的高低取决于它所调用的函数的情况。举例来说，此线程先调用了函数甲，函数甲一个人心有余而力不足，无法独自完成所有的任务，它又请求了函数乙的帮助。出来借的，总归是要还的。每次往外的调用，都会使堆栈增长，就像欠下的债一样。调用的太多了，就会负债累累，非崩盘不行。

基本套路看完后，就可以看看尾部递归的招数啦。如果一个函数在运行到最后一步的时候才力不足，那么它请人帮忙的行为就被叫做尾部调用。如果尾部调用的对象是它自己，它就成为了尾部递归。尾部递归，不像其他的尾部调用，它造成堆栈溢出的可能性更大，因为自己调用自己，简单快捷方便，不用见外。找别人的时候，首先得需要这个人存在。此外，即便有人了，也得好意思张开那个嘴才成。所以一般不是递归的时候，堆栈的增长都是很有限的。

最后就要说说优化了。其实可以这样想，假如老大找老二帮忙，老二又得找老三。如果老二对老三这样说，“你这件事做完，直接给老大就行了，不用来找我”，那么，这一系列的调用就优化了。反之，如果老二说，“你做完之后，先给我，我再做点补充，然后再给老大。”，这样一来，就不优化了。递归是同样的道理，不过把老大，老二和老三都看成同一个人就行了。

显而易见，优化的手段就是减少中间步骤，把任务传达的干干净净。

上大学的那会，老班长点名点腻了，想当小兵，不仅可以不点名，而且可以偶尔翘翘课。我不知其中的苦恼，愣是接了他的差事，干了一段班长，管了一会班委会。如今细细想来，这段经历还是相当珍贵的，单从现在从事的编程工作来讲。

一个好班长和一个平庸班长的最大区别，就是，好的班长，自己不累，可以把班委会的各个成员，如生活委员，学习委员，文艺委员的积极性都给调动起来，让他们各自发挥各自的特长，好刀都用到好刃儿上，进而又快又好的完成指导员交予的任务。而平庸的班长，则“独揽大权”，什么活都一个人干，自己累个半死，他人闲个半死。

把这个场景和编程做一下对比，会发现，它们之间有异曲同工之妙。把指导员和同学比作用户，把班委会比作为同学和指导员服务的接口。班委会的各成员就是实际实现这些服务的角儿。离接口最近的人，是班长，因为总是他第一时间收到用户的请求，其他的委员离接口相对远些，因为他又受班长的指派。这样一来，一个好的班长，作为服务的总实现者，从来不去做具体的事情，而是把任务指派下去，实现分布式工作，而平庸的班长，会使用集中性处理。

对应到编程上，前者，创建了很多小的单元，每个单元做自己擅长的是，实现了模块化，责任结构一目了然。后者，一团糟，都纠结在了一起。总结一下，在编程里，离接口越近的类，具体实现就应该越少，指派的越多，而离接口越远的类，就应该指派的越少，而具体实现的越多。各自做各自擅长的事情。

当人们谈及到国内和国外工作差异的时候，往往把天花板效应当做国外职场发展的一个弊端。如果这真是一个弊端，那么我想强调，这是一个对于头已经顶到天花板的人的弊端。

之所以这么说，是因为听到那些涉世未深，跳起来都够不到天花板的牛犊们，大谈效应问题。与其用这种论断来为自己在面对各种挑战前的不自信而开脱，倒不如把天花板当成一个修炼目标，早日顶的，早日成佛。到那时再以一个被碰过头的受害者身份，抱怨天花板的弊端。勇者越碰越勇，懦弱着知疼而退。

干一行爱一行，不仅有利于工作效率的提高，而且有助于提升个人的修养和人生境界。一份工作，不管它的地点，不管它的待遇，只要全身心的投入，精益求精，就会发现它的魅力，劳动的魅力。我觉得这一点对一个在国外谋生的人，特别是对那些常有置身异乡，有漂泊感的人，更为重要。

忘掉所有异样旳目光，所有冷漠的面孔，关注个人能力的提升才是赢得尊重，顶破天花板的关键，不仅是那个由于出身，文化而造成的对于外人天花板，更是心中那块无形的，阻挡视野的天花板。

程序员的主要任务是让自己成为一个不必要的人。这听起来相当愚蠢，仿佛工作的目的就是要把工作给慢慢作丢了。其实不然，一个不必要的程序员才是一个优秀的程序员。

这话越听越自相矛盾了，但如果理解了不必要的意思，便一切都明朗了。必要与不必要是从代码与代码的维护这一层面讲的。一个优秀的程序员写的代码应该是一目了然，具有自我解释能力的。别人读着赏心悦目的代码，就像聆听作者讲故事一样，只要代码在，作者的存在与否就无关紧要了。

可从人才的角度出发，这个不必要的人是多么的难能可贵。每写一段代码，他都在讲一段故事，这如何能让人不沉醉。

我也有洁癖，虽然我是一个不拘小节，有些大大咧咧的人。而不干净不整齐的代码常常让我郁郁寡欢。自己范的错误自我纠正即可，可他人如果没有这个追求，我该如何是好？

敢于做批评和自我批评固然是一种优秀品质，但这并不意味着要以融洽的同志关系当做牺牲品来换取。当敏锐的直觉告诉我，此处代码有污迹的时候，与其快刀斩乱麻似的急于重构，倒不如先安下心来仔细的分析一番，为何代码没有带来美的享受。

这样做有不少好处。一是有助于深刻的理解问题的根源所在。特别是读别人的代码的时候，即便找不到合适的方式与他人沟通，至少自己明白问题的症结之后，从别人的代码中吸取宝贵的教训，也能保证自己不犯类似的错误。其次，静心思考，也是给接下来的沟通和辩论收集论据。己所不欲，勿施于人，自己都没搞明白的东西何必强行的去要求别人呢。倘若是由于论据不足而导致说服不了别人，恐怕以后再发言的时候，听众便要不以为然了。

说到这，顺带着讲一下我遇到的不简洁代码。

一是关于对象继承的问题。众所周知，对象继承有利于代码的重用。但并非任何行为都可以通过继承来实现重用。继承应遵守的最重要的原则便是Liskov代换原则。在任何环境下，一个子类总可以代换它的父类。意思是说老子能用的地方，换成是儿子，儿子也能完成所有的任务。若此原则不能遵守，请用组合而非继承。

其次便是DRY(Dont repeat yourself)原则，史上最重要的编程原则，永远不要写重复代码。重复代码是一个梦魇，不仅不利于维护而且不利于代码重用。究其原因，是只看到了问题的表面，而不得其实质。解决方法便是提升抽象的层面。

代码洁癖并无好坏之说，觅得问题的实质，以容易让人接受的方式传达有效的信息才是关键。

Java中的枚举，不仅可以用来列举常量，而且可以实现接口。这第二点很重要，它使得枚举类型具备了多态的特性。但它又有一定的缺陷，特别是遇到枚不胜举的时候。

对于每一个新加入的枚举元素，他都必须实现接口中的所有方法。即便是在一个不大的接口的情形下，当元素数量增加到一定程度的时候，源文件就会变得相当巨大。虽然所有枚举元素，都是在实现同一类方法，但毕竟细节不同，所以把他们列在一起，影响阅读的欢乐性。除此之外，每次增加新的枚举元素，都要对此枚举文件进行修改，不符合开闭原则。