Daniel-Journey Weekly Dose – 2009/11/22
Java
Analyzing Java Heap problems Part 1: Basic actions and tools
Best Open Source Reporting Tools
Analyzing Java Heap problems Part 2: Using Eclipse MAT
测试驱动
下列原因之一可能是类似问题的根本原因:
- 团队在重构方面做得不够,因此你的类没有做到最小化。
- 团队在“尽量简单”方面的技能还不够,同样如此。
- 团队还没有采取具备侵略性和快速度的微测试(microtesting,也就是单元测试),所以改变常常会破坏测试
- 团队不知道如何处理跨团队、或是公司对公众之间的依赖,比如公布API的情况
- 团队既没有结对,也没有在开放空间中工作,这极大降低了团队层面的知识理解和传递
- 团队似乎没有具备快速构建的能力
- 团队可能还在使用老古董级别的工具
也许“告知,不要询问”是最重要的设计原则:不要分离功能和数据……恶劣的代码常常把功能实现放在一个地方,从其他地方得到需要的数据,这就造成了依赖性方面的问题,同时代码缺少局部性(locality)。其症状就是:“添加一个新功能,要修改多处代码。”代码异味“散弹枪式手术”、“依恋情结”、“参数列表过长”都是这样造成的。
重构要比重写更好,其优势在于:你总是有可工作的代码。如果你的手工和自动化测试都很好,那你就可以交付代码了,即使目前的状态处于“优秀设计”和“恶劣设计”之间。
面向对象设计
The Open/Closed Principle – A real world example
关于开发封闭原则,其核心的思想是:
软件实体应该是可扩展,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。
因此,开放封闭原则主要体现在两个方面:
对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。
对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对类进行任何修改。
