Leblanc : Later equals never. (勒布朗法则:稍后等于永不)
对代码的每次修改都影响到其他两三处代码。
如果你在方法中抛出可控异常,而catch语句在三个层级之上,你就得在catch语句和抛出异常之间的每个方法签名中声明该异常
特例模式(Special Case Pattern):创建一个类或配置一个对象,用来处理特例。
构造测试数据;操作测试数据;检验操作是否得到期望的结果
测试应该够快:测试运行缓慢你就不会想要频繁的运行它;测试应该相互独立;测试应当可在任何环境中重复通过;测试应该有布尔值输出,你不应该查看日志来确认是否通过,不应该手工对比两个不同文本来确认测试是否通过;测试应及时编写:单元测试应该恰好在使其通过的生产代码之前编写。
部件之间的解耦代表着系统中的元素相互隔离得很好。
依赖倒置原则(Dependency Inversion Principle, DIP):类应当依赖于抽象而不是依赖于具体细节。程序要依赖于抽象接口,不要依赖于具体实现。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。
复杂要人命。它消磨开发者的生命,让产品难以规划、构建和测试。
---------------------(Ray Ozzie, 微软公司首席技术官)
扩容:“一开始就做对系统”纯属神话。反之,我们应该只去实现今天的用户故事,然后重构,明天再扩展系统,实现新的用户故事。这就是迭代和增量敏捷的精髓所在。测试驱动开发、重构以及他们打造出的整洁代码,在代码层面保证了这个过程的实现。
软件系统与物理系统可以类比。它们的架构都可以递增式地增长,只要我们持续将关注面恰当地切分。
- 横贯式关注面:原则上,你可以从模块、封装的角度推理持久化策略。但在实践上,你却不得不将实现了持久化策略的代码铺展到许多对象中。
Java中的三个“方面”:
- Java代理:适用于简单的情况,例如在单独的对象或类中包装方法调用。
测试驱动系统架构:通过方面式手段切分关注面的威力不可低估,假使你能用POJO编写应用程序的领域逻辑,在代码层面与架构关注面分离开,就有可能真正地用测试来驱动架构。采用一些新技术,就能将架构按需从简单演化到精细。没必要先做大设计(Big Design Up Front, BDUF)。实际上,BDUF甚至是有害的,它阻碍改进,因为心理上会抵制丢弃既成之事,也因为架构上的方案选择影响到后续的设计思路。
最佳的系统架构由模块化的关注面领域组成,每个关注面均用纯Java(或其他语言)对象实现。不同的领域之间用最不具有侵害性的方面或类方面工具整合起来。这种架构能测试驱动,就像代码一样。
优化决策:模块化和关注面切分成就了分散化管理和决策。最好是授权给最有资格的人,延迟决策至最后一刻也是好手段,让我们能够基于最有可能的信息作出选择。提前决策是一种预备知识不足的决策。如果决策太早,就会缺少太多客户反馈、关于项目的思考和实施经验。
拥有模块化关注面的POJO系统提供的敏捷能力,允许我们基于最新的知识做出优化的、时机刚好的决策。决策的复杂性也降低了。
无论是设计系统或单独的模块,别忘了使用大概可工作的最简单方案。
对象是过程的抽象。线程是调度的抽象。