临近年终，公司请来一位讲师来给我们作培训，题目记得是设计匠艺。说实话，我做不到像讲师那样，快讲完课时能将自己所讲的内容都有条理整理一遍。我就大致讲讲我所做笔记的一些内容吧。总的来说这位讲师的实践经验很丰富，讲得也很生动。
观点一：代码的可扩展性和可维护性是矛盾的。这是讲师在上课之初所提的一个观点。说实话我是不太同意这个观点的，一方面加强了代码的可维护性确实加大了代码的维护难度，比如使用了模式可能加大的系统复杂性，但很多时候加强了代码的可维护性同时也方便了代码的维护，比如扩展性增强了一旦出错你也更容易找到自己所要维护的代码了。这个我相信经常做代码重构的同学都有这个体会。
观点二：优秀代码的三个特性：沟通、简单和灵活。其实这三点都和代码的可维护性息息相通的，所以讲师的下一个观点是代码的维护成本远远大于开发成本。这个应该是符合实际的，问题是限于国内的IT环境，有多少企业重视对技术的积累呢？如果对技术积累重视起来，也就会真正重视代码的维护了。有志向的企业都应朝这个方向努力。
观点三：代码就是设计。这是一个说得都有点滥俗的观点，但却引不起我们重视的观点。以前我总是幻想维护文档总是越多越好。现在发现文档存在很多弊端的：首先是代码和文档的脱节问题，比如代码更新了，而文档却没有及时更新；其次是即使你的文档写得很好，可是维护人员会看你的文档吗？而代码是无论维护人员喜不喜欢看，都必须去看。现在我想除了一些涉及数学的复杂的算法需要文档说明之外（而且还必须使用工具和代码绑定在一起），应该做到代码就是设计，就是文档！
观点四：面向对象的三个要素是角色、职责和协作。所有的设计模式都是解决职责问题。。首先有职责，才有设计模式。这些观点非常精彩。我想重读四人帮的《设计模式》，一定会从这个角度思考问题。
观点五：设计模式是一种封装技巧，但封装并不仅仅是信息隐藏。
观点六：设计手法：抽离（抽象隔离），间接和一致。
观点七：对于大多的软件项目或移动开发领域，需要做到快速迭代。快速交付一个可用的产品比什么都重要。不要祈求需求不发生变化（有一个笑话：任何需求都发生三次以上，需求发生两次变化的需求分析人员死在用户更改需求的路上）。正因为变化必然要到来，就要争取变化早点到来，而快速的交付就能带来更多的用户反馈，从而更好应对变化。
观点八：持续构建必须和一系列的测试结合起来，比如单元测试、压力测试等等。
观点九：UML主要是一种交流工具。讲师推崇一种简单UML加测试驱动开发的开发模式。可测试实际上为软件开发活动树立一条红线。
观点十：讲师认为单元测试非常好。他认为单元测试能及时提供反馈；单元测试让你的代码更加健壮；单元测试是有用的设计工具；单元测试是让你自信的后台；单元测试是解决问题的探测器；单元测试是可信的文档；单元测试是学习的工具。（搞得现在我对单元测试非常感兴趣。）
我的一些疑问：如果提倡快速迭代小版本交付，功能开发的优先级由谁决定，怎么决定？软件的设计比如界面设计是否都由开发人员完成？
临近年终，公司请来一位讲师来给我们作培训，题目记得是设计匠艺。说实话，我做不到像讲师那样，快讲完课时能将自己所讲的内容都有条理整理一遍。我就大致讲讲我所做笔记的一些内容吧。总的来说这位讲师的实践经验很丰富，讲得也很生动。
观点一：代码的可扩展性和可维护性是矛盾的。这是讲师在上课之初所提的一个观点。说实话我是不太同意这个观点的，一方面加强了代码的可维护性确实加大了代码的维护难度，比如使用了模式可能加大的系统复杂性，但很多时候加强了代码的可维护性同时也方便了代码的维护，比如扩展性增强了一旦出错你也更容易找到自己所要维护的代码了。这个我相信经常做代码重构的同学都有这个体会。
观点二：优秀代码的三个特性：沟通、简单和灵活。其实这三点都和代码的可维护性息息相通的，所以讲师的下一个观点是代码的维护成本远远大于开发成本。这个应该是符合实际的，问题是限于国内的IT环境，有多少企业重视对技术的积累呢？如果对技术积累重视起来，也就会真正重视代码的维护了。有志向的企业都应朝这个方向努力。
观点三：代码就是设计。这是一个说得都有点滥俗的观点，但却引不起我们重视的观点。以前我总是幻想维护文档总是越多越好。现在发现文档存在很多弊端的：首先是代码和文档的脱节问题，比如代码更新了，而文档却没有及时更新；其次是即使你的文档写得很好，可是维护人员会看你的文档吗？而代码是无论维护人员喜不喜欢看，都必须去看。现在我想除了一些涉及数学的复杂的算法需要文档说明之外（而且还必须使用工具和代码绑定在一起），应该做到代码就是设计，就是文档！
观点四：面向对象的三个要素是角色、职责和协作。所有的设计模式都是解决职责问题。。首先有职责，才有设计模式。这些观点非常精彩。我想重读四人帮的《设计模式》，一定会从这个角度思考问题。
观点五：设计模式是一种封装技巧，但封装并不仅仅是信息隐藏。
观点六：设计手法：抽离（抽象隔离），间接和一致。
观点七：对于大多的软件项目或移动开发领域，需要做到快速迭代。快速交付一个可用的产品比什么都重要。不要祈求需求不发生变化（有一个笑话：任何需求都发生三次以上，需求发生两次变化的需求分析人员死在用户更改需求的路上）。正因为变化必然要到来，就要争取变化早点到来，而快速的交付就能带来更多的用户反馈，从而更好应对变化。
观点八：持续构建必须和一系列的测试结合起来，比如单元测试、压力测试等等。
观点九：UML主要是一种交流工具。讲师推崇一种简单UML加测试驱动开发的开发模式。可测试实际上为软件开发活动树立一条红线。
观点十：讲师认为单元测试非常好。他认为单元测试能及时提供反馈；单元测试让你的代码更加健壮；单元测试是有用的设计工具；单元测试是让你自信的后台；单元测试是解决问题的探测器；单元测试是可信的文档；单元测试是学习的工具。（搞得现在我对单元测试非常感兴趣。）
我的一些疑问：如果提倡快速迭代小版本交付，功能开发的优先级由谁决定，怎么决定？软件的设计比如界面设计是否都由开发人员完成？