David Thomas, Author of “the pragmatic programmer” (English and Chinese)
Title of speech: Pragmatic Agile (实用的敏捷)
怎样才是 "Pragmatic":
- Do what works. (if it doesn't work, stop doing it).
- Working at what to do (focus)
个人笔记:
1) 过时了?
这本书(程序员修炼之道) 已经出版10年了, 10 年间软件产业的变化，几乎可以和别的产业100 年相比。 那么这本书变老了么? 过时了么.
有一些细节的确过时了，软件工具变得更成熟，可以替代不少手工；更多的人在使用动态语言编程，等等. 但是，基本的想法还是没有过时。 例如：“破窗理论”, 很多人还在说： “我以后会处理那些小问题的”，但是“以后”什么时候来呢? 你总有更多重要的事情在等你。 也许没有“以后”，也许，已没有也许。
2) DRY 原则 - "Don't Repeat Yourself".
所有能够被表达的概念都应该有一个并只有一个地方来表达。
设计模式 - 设计模式很有用，David 认为这个概念已经被用得太多，太滥。 设计的目的之一是避免重复， 但是我们有很多重复的模式在代码中大量出现，这是好事么? 这违反了DRY 原则. 应该避免重复， 保持松耦合，让代码做好一件事。 这样才能方便地修改和演化代码。
3) 敏捷需要一个执行者
"敏捷/agile" 是一个形容词/副词， 不是一个东西， 它修饰的是我们做事情的方式，不是这事情本身。 所以“敏捷”需要一个动作，和一个动作的执行者。 光说“我们敏捷”是没有用的。 同样，敏捷/Agile 也不是一个 “拷贝/粘贴”的东西.
对于很多与会者称David 及其他讲师是 "敏捷大师/agile masters"。 他不以为然地说 “我们不是大师， 我们不过是把你们还没有犯的错误都经历过了，我们现在把这些经验分享出来，可能会帮助后来者少犯错误，节约时间".
4) 单元测试
单元测试也是一个好事，但是好多人也做得过头了，太注重单元测试，单元测试成为了目标 - 这是错误的。 写代码的目标是“满足用户的需求”， 而不是“满足所有单元测试”。 (我的理解) 如果单元测试能百分之百地表达用户的需求，这两者就可以统一，但是如果有人能写 “百分之百地表达用户的需求的单元测试”，这些人干脆直接写软件算了。
5) 敏捷方法的真正好处
问题: 我想敏捷，但是项目的期限不动；敏捷能帮我早日完成任务?
回答: 敏捷不是万能。 敏捷的方法能帮助你更早地知道你是否能如期完成任务。仅此而已。 敏捷的方法（迭代的方式）能帮你尽快让用户看到项目的（部分）价值。 当你尽早交付（部分）价值的时候， 也许用户对你目前交付的东西已经很满意了，这样你就不用再花时间来实现其他计划中的事情。 另一种可能是， 用户看到了（部分）系统，他们对整个需求有了新的认识，这样你就可以实现他们新的需求，而不用再浪费时间.
---------------------------------------------
注：这是参加 AgileChina 2009 大会的感想，大会的情况如下:
AgileChina 2009大会报道与评论集锦：
http://www.infoq.com/cn/agile
大会现场图片集锦：
http://www.flickr.com/groups/agilechina2009
演讲资料下载：
- 敏捷大会所有演讲PPT下载：http://bit.ly/agilechina2009
- Kent Beck名师讲堂PPT下载：http://bit.ly/KBtraining
---------------------------------------------
感想(1) (2) (3)