公司培训心得体会如何写？( 五 )

公司培训心得体会如何写？

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