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

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

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

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

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

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

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

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

年月一步一步毫不知疲倦的走在身前。有人因此激动的期待着充满未知的明天，也有人因此为逝去的昨天而惋惜不已。可无论如何，欢喜也好，忧伤也罢，我们总是被带着往前走的。既然无法阻挡，何不与年月来场赛跑，架上幸福的飞毯，远远的把它抛在身后。我的飞毯，她和我一起织就，从十七岁那年，很庆幸一路上有她，很感激一路上还会有她，我的妻。

我是一个程序员，富丽堂皇的说，叫软件工程师，通俗易懂的讲，是编程的。至于编什么程，在正常发工资的情况下，老板说了算。

老板是卖金融软件的。这个软件有点大，能做不少事。其中有一个，是让电脑屏幕上能实时的显示，金融市场上的数据，比如美元对欧元的汇率，股票的价格等等。如何把这些数据搬到屏幕上，并且让他们一闪一闪的实时刷新，就是我所在的小分队的主要任务。

经过前辈们的努力，这个功能是实现了，但随着时代的发展，客户的要求越来越高，他们嫌数据更新的有点慢。所以现在又有新的任务了，要把数据运的再快点。这个时候，刚刚毕业的我，被招进来了。

要想富，少生孩子多种树。这句话告诉我们，只生孩子不种树，是会阻碍经济快速发展的。软件数据运的太慢，与孩子和树是没关系的，找到它的瓶颈所在，便是我平常工作中所面临的问题。怎么听起来，有点像搞计划生育的？

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

为了克服这个缺陷，我们可以尝试着，把不同的枚举元素放到不同的文件中，单独成型，并对接口进行实现。如此以来，新加的元素，就写在新的文件里，小而清晰，各自独立。

可这样的作法，有得必有失，那就是失去了，枚举类型中能获取所有类型那个静态函数，values()。

其实补救的方法还是有的，那就是创建一个新类，在里面手动添加新加入的元素，然后通过它进行索引。开闭原则遵守的再好，还是一定要找个切入口的，但口越小越好。

示例在此。看你能不能发现那个小口。