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