第五十五条 谨慎地进行优化

开篇就提出了三个名人的观点，概括下来，就是不要进行优化，不成熟的优化往往会惹出大问题。我们写程序，往往喜欢优化，但不正确的优化，
产生的结果可能既不快速，也不 正确，而且还不容易修正。不要为了性能去牺牲合理的结构，我们应该努力写好的程序而不是快的程序，但这并不意味着可以放弃性能，而是好的架构可以提升性能和扩展功能，如果一味追求性能，牺牲了框架，后期的扩展和性能提升往往会遇到瓶颈，并且牵一发而动全身。努力避免那些限制性能的设计决策，一旦设计了，后期改动牵涉的东西就特别多了。要考虑API设计决策的性能后果，设计一种模式时，就要考虑后期使用时可能（坑爹）的问题。比如java.awt.Component类中的getSize()方法，会返回一个新的对象，这个可以理解为保护性拷贝，尽管虚拟机分配小对象的开销并不大，但是假如分配数百万个不必要的对象会损耗不必要的性能

    public Dimension getSize() {
        return size();
    }
    @Deprecated
    public Dimension size() {
        return new Dimension(width, height);
    }

对于这种，我们可以换种思路，比如把成员变量用final来修饰，使之不可变，这样就可以节省对象空间了。

对于优化，我们应该用数据来说话，并非是一厢情愿的遐想，计算机的世界，都是用数据来决定结果，而不是“我觉得，我认为”。优化的前提一定是要结果是正确的，没有改出bug，其次才是性能，同时还要考虑时间产出等。有时候我们优化了代码，发现可能性能更差了，并且还出现了莫名其妙的bug。所以不要费力去编写快速的程序，应该努力编写好的程序，速度自然会随之而来。根据自身的经验，保持类功能单一是很有必要的，这样能解耦，并且能快速增删这一模块，并且快速提供给其他项目使用；代码结构要清晰，不要过度包装，造成不必要的浪费；代码写完后，用专业的检测工具去检查性能，多在不同的平台上测试。