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

>我来写笔记

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

  • 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人喜欢

  • windy

    windy

    “用户素材”是否应该翻译为“用户需求”/“用户需求点”?

    2018-11-05 22:36

  • windy

    windy

    书中“过程”一词是否应该翻译成“流程”/“工作流程”?

    2018-11-05 21:40

  • sheshiji

    sheshiji

    当你能够度量你所说的,并且能够用数字去表达它,就表示你了解了它;若你不能度量它,不能用数字去表达它,那么说明你的知识就是匮乏的,不能令人满意的。

    2018-09-16 22:31

  • 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

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

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

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

敏捷软件开发

>敏捷软件开发