feifeilb的博客

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第20章后半部分 包的耦合性原则 无环依赖原则（ADP - The Acyclic Dependencies Principle ） 在包的依赖关系图中不允许存在环。 解除依赖环的方法 使用依赖倒置原则。 创建一个新包，把共同依赖的类移动到新包里面。 稳定依赖原则（SDP - The Stable-Dependencies P...

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第20章前半部分 包的内聚性原则 重用发布等价原则（REP - The Reuse/Release Equivalence Principle） 重用的粒度就是发布的粒度 REP指出，一个包的重用粒度可以和发布粒度一样大。我们所重用的任何东西都必须同时被发布和跟踪。简单的编写一个类，然后声称它是可重用的做法是不现实的。只有在建立一...

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第12章。 接口隔离原则（ISP - The Interface Segregation Principle） 不应该强迫客户依赖于它们不用的方法。 这个原则用来处理“胖”接口所具有的缺点。如果类的接口不是内聚的，就表示该类具有“胖”的接口。换句话说，类的“胖”接口可以分解成多组方法。每一组方法都服务于一组不同的客户程序。这样，一...

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第11章。 依赖倒置原则（DIP - The Dependency-Inversion Principle） a. 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。 b. 抽象不应该依赖于细节。细节应该依赖于抽象。 请考虑一下当高层模块依赖于低层模块时以为着什么。高层模块包含了一个应用程序中的重要的策略选择和业务模型。正是这些...

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第9章。 里氏替换原则（LSP - The Liskov Substitution Principle） 子类型必须能够替换掉它们的基类型。 问题 对于LSP的违反常常会导致以明显违反OCP的方式使用运行时类型辨别。这种方式常常是使用一个显示的if语句或者if/else链去确定一个对象的类型，以便于可以选择针对该类型的正确行为。...

开放-封闭原则 （OCP - The Open/Closed Principle） 软件实体（类、模块、函数等等）应该是可以扩展的，但是不能修改的。 对于扩展是开放的。对于更改是封闭的。 关键是抽象 一般而言，无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。没有对于所有的情况都贴切的模型。既然不可能完全封闭，那么就必须有策略的对待这个问题。也就是说，设计人员必须对于他设计的模块应该对哪种...

单一责任原则 （SRP - Single-Responsibility Principle） 就一个类而言，应该仅有一个引起它变化的原因。 在SRP中，我们把职责定义为‘变化的原因’。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。 如果决定职责的粒度，要依赖于具体程序的变化方式。如果程序的变化会影响某一个细分职责，那就肯定要分开它们，否则会带来僵化性的臭味。但如果应用...

设计的臭味 僵化性 僵化性是指难以对软件进行改动，即使是最简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。必须要改动的模块越多，设计就越僵化。 脆弱性 脆弱性是指，在进行一个改动时，程序的许多地方就可能出现问题。常常是，出现新问题的地方与改动的地方并没有概念上的关联。 牢固性 牢固性是指，设计中包含了对其他系统有用的部分，但是要把这些部分从系统中分离出...

起源 《敏捷软件开发 - 原则、模式与实践》是我接触到的第一本系统介绍软件设计的书籍，深刻影响了个人的软件开发习惯。它并不难懂，我一直推荐给身边的各个层次的程序员学习。 可对于一本接近500页的图书，很多人还是望而却步。一直都想写个关于这本书的速读，使更多的人了解它。但是最近又重新学习了一遍发现它之所以有价值不仅仅在于书中总结的原则和模式，更在于它提供的如何运用这些原则、模式的实践例子。忽略了大量...

本文对应原书第3章 ~ 第6章。 计划 初始探索 在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户用例。但，他们不会试图去确定所有的用户用例。注意用例的大小，过大或过小都不利于工作量的评估。 发布计划 根据开发速度，客户选择下面2-4个月需要完成的用户用例，并排列这些用例的优先级。发布计划可以调整。 迭代计划 根据开发速度，客户选择下面2周需要完成的用户用例，并排列这些用例的...

本文对应原书第1章和第2章。 敏捷软件开发宣言 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循规则 敏捷开发原则 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月...