敏捷软件开发的笔记(71)

>我来写笔记

按有用程度 按页码先后 最新笔记

  • QMX

    QMX

    2016-05-31 18:01   2人喜欢

  • Joker Lee

    Joker Lee (Es gilt viele mauern abzubauen)

    唯一能够加快进度的方法便是缩减范围。不要经受不住诱惑盲目冲刺。 在程序员所能表现的各种不专业行为中,最糟糕的是明知道还没有完成任务却宣称已经完成

    2012-10-11 23:00

  • Wuqifu

    Wuqifu (喜欢买书的软件工程师~)

    Command模式:将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可取消的操作。 命令模式就是把一些具体的命令封装成一些具体的类,这些类实现同一个接口或者是抽象类。把这些类组织到一起来统一执行,完成一个具体的业务流程。它的优点是:解耦了发送者与接收者之间的联系。发送者调用一个操作,接收者接受请求执行具体类相应的动作。因为使用Command模式解耦,发送者无...

    2011-12-23 21:34   2人喜欢

  • Link

    Link

    软件实体(类、模块、函数等等)应该是可以扩展的,但是不可修改的。

    2018-03-17 15:25

  • Link

    Link

    就一个类而言,应该仅有一个引起它变化的原因。 在 SRP 中,我们把职责定义为“变化的原因”(a reason for change)。如果你能够想到多于一个得动机去改变一个类,那么这个类就具有多于一个的职责。

    2017-08-07 00:42

  • Link

    Link

    敏捷开发人员知道要做什么,是因为: (1) 他们遵循敏捷实践去发现问题 (2) 他们应用设计原则去诊断问题;并且 (3) 他们应用适当的设计模式去解决问题。 软件开发的这三个方面间得相互作用就是设计。 这大概就是软件设计的几个重要步骤,要做到这几个步骤,首先要足够了解这些原则和设计模式。

    2017-08-07 00:27

  • Link

    Link

    如果我们的设计由于持续、大量的需求变化而失败,那就表明我们的设计和实践本身是有缺陷的。我们必须要设法找到一种方法,使得设计对于这种变化具有弹性,并且应用一些事件来防止设计腐化。 反思自己,也试过以“需求变化”作为理由来掩饰自己设计上的缺陷。幸运的是,也有过成功的经验:在某个项目意识到当前设计有缺陷时,及时修改了设计,这在后续需求的变化中发挥了巨大作用。

    2017-08-07 00:21

  • Link

    Link

    编写单元测试是一种验证行为,更是一种设计行为。同样,它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功能验证方面的反馈循环。 为了成为易于调用和可调式的,程序必须和它的周边环境解耦。这样,首先编写测试迫使我们接触软件中的耦合。

    2017-08-06 00:54

  • Link

    Link

    XP 团队通过经常性的代码重构来扭转这种退化。重构就是在不改变代码行为的前提下,对其进行一系列小的改造(transformation),旨在改进系统结构的实践活动。每个改造都是微不足道的,几乎不值得去做。但是所有的这些改造叠加在一起,就形成了对系统设计和架构显著的改进。 反之,如果不经常做这种改进,问题就会像滚雪球一样越来越多,到最后改动的成本就更大了。

    2017-08-06 00:51

  • Link

    Link

    极限编程者不能容忍重复的代码。无论在哪里发现重复的代码,他们都会消除它们。 问题在于,如果没有掌握快速消除重复代码的能力,就很容易因为进度问题将就过去了,好一点的情况是在注释加个 TODO

    2017-08-06 00:48

<前页 1 2 3 4 5 6 7 8 后页>

笔记是你写在书页留白边上的内容;是你阅读中的批注、摘抄及随感。

笔记必须是自己所写,不欢迎转载。摘抄原文的部分应该进行特殊标明。

敏捷软件开发

>敏捷软件开发