敏捷软件开发：原则、模式与实践读书摘要

10．简单——使末完成的工作最大化的艺术——是根本的。
    敏捷团队不会试图文构建那些华而不实的系统，他们总是更愿意采用和目标—敛的最简单的方
法。他们并不看重对于明天会出现的问题的预测，也41会在今天就对那些问题进行防飞。相反，他
们4：今天以最高的质量完成最简单的[作，深信如果在明天发生了问题，也会很容易进行处理。

《未命名图书》 , 第7页

8．敏捷过程提倡可持续的开发达废。责任人、开发者和用户应该能够保持一个长期的、恒定的开
发速度。
    敏捷项日不是50米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那
个速度：相反，他们以快速但是可持续的速度行进。
    跑得过快会导致团队精力耗尽、出现短期行为以致于谰溃。敏捷团队会测量他们自己的速度。
他们不允许自己过于疲惫。他们不会借用明天的精力来齐今天多完成一点工作*他们工作／L一个可
以位齐整个项目开发期间保持最高质量标准的速度上。

《未命名图书》 , 第14页

极限编程者不能容忍重复的代码。无论在哪里发现重复NfC码，他们都会消除它们
    导致代码重复的因素有许多，最明显的是用鼠标选小一段代码后四处粘贴。七发现那些重复的
代码时，我们合通过定义一个函数或基类的方法来消除它们。有时两个或多个算法非常相似，但是
它们之间父存在着微妙的差别，我们会把它们变成函数，或者使用Template Method模式。无
论是哪一种代码重复之源，一旦发现，就必须被消除。

《未命名图书》 , 第15页

    这就是隐喻，它是将整个系统联系在  起的全局视图，它是系统的未来景保，是它使得所有尽
独模块的位置和外观(sh8p)变得明显寅现。如果模块的外观与整个系统的隐喻不符，那么你就知
道该模块是错误的。

《未命名图书》 , 第17页

过大或者过小的素材都是难以估算的。开发人员往往会低估那些大的素材而局估那些小的素