少就是多
今天偶尔听到两个同事的对话，感觉很有意思：
A: 删代码真是一件很爽的事情，一次删几百行。
B: 最重要的是，删完了还work。
有的时候代码多不见得是件好事，代码越多系统就越复杂，理解起来就越难，相对应的就越可能出错。如果能用较少的代码实现同样的功能，代码的可读性就会提高，会更易于理解，从而也减少了bug，提高了质量。
代码多的原因不外乎几个：
- 对平台不熟悉。这用情况往往是平台已经提供了相应的API，但是由于开发人员对平台的不了解，导致重复性工作，写了很多代码实现平台已经封装好的功能。要消除这一部分代码，可以找一个熟悉平台的人做code review，用平台提供的API代替，既能减少代码，又能提高可读性和质量。
- 技术水平不足。这种情况往往都是因为逻辑比较混乱，算法不够清晰。解决办法，无他，学习尔。
- 重复代码。这种是很严重的问题，通常是因为copy-paste过多，偶尔也有其他原因。可以通过提取方法等重构手段消除重复代码，同时注意在copy-paste的时候想一想如何避免重复代码。
- 对问题理解不足。有时在解决一个问题时，由于没有相关的经验，或者对问题不了解，导致思路不够清晰，代码量也随之增大。但是随着对问题的深入，应该可以找到清晰的思路，并对已经写好的代码做优化处理，理清结构，减少不必要的代码。
- 过度设计。很多开发人员（包括我在内）在开发时，往往喜欢走一步看两步，为以后的扩展做考虑，这本身没有什么问题。可是如果考虑的太多，为了灵活性做了太多设计上的工作，导致系统架构复杂，代码量也会大幅增大，这对日后的开发和理解带来了障碍。如果不幸你的预见都错了，期望的变化没有发生，那么这些为了灵活而作的设计反而会成为拖累。解决办法，保持适度的灵活性，保持设计的简洁。
- 设计模式崇拜。多见于新学模式的开发人员，感觉设计模式很好，所以在遇到问题的时候就把模式直接搬过来。设计模式是用来解决复杂的问题的，可是实际写代码的时候，复杂的问题其实没那么多，一个中大型的系统可能也不会用到超过5个以上的设计模式。而且设计模式也是有简化版本的，可以先用简化的版本，等到问题确实很复杂的时候再用完全版本。
- 故意多写代码，提高代码行数。这个...没办法。
另外很重要的一点，删代码的时候一定要保证功能的正确性（就是还work），如果有自动化测试就比较保险了。
暂时想到这么多，欢迎补充。
