UML和模式应用

1. 在OO开发中，至关重要的的能力是熟悉地为软件对象分配职责。
2. 职责分配是一项既难以掌握又至关重要的技能(涉及大量需要权衡和抉择的问题)。
3. 对象设计和职责分配的9项基本原则。
4. 分析强调的是对问题和需求的分析，而不是解决方案，“分析”一词含义广泛，最好加以限制，如需求分析或面向对象的分析。
5. 设计强调的是满足需求的概念上的解决方案，而不是其实现。例如对数据库方案和软件对象的描述。设计思想通常排斥底层或“显而易见”的细节。最终设计可以实现，“设计”一词含义广泛最好加以限制，如面向对象设计或数据库设计。
6. 有益的分析和设计可以概括为：做正确的事和正确的做事。
7. 统一建模语言(UML)是描述、构造和文档化系统制品的可视化语言。
8. 迭代开发中既没有匆忙地编码，也没有进行长期的设计以试图在编码前完善所有设计细节。每次迭代前都产生可执行的但不完整的系统，他不是已经准备好可以交付的产品。直到多次迭代之后系统才可能合格地用于产品部署(这个和实际情况不一样现在每次迭代都都要求能上线)。
9. 迭代开发拥抱，但是并不说提倡不收控制。
10. 22风险驱动开发更为明确地包含了以架构为中心，以为着早期迭代要致力于核心架构的构造、测试和稳定。
11. 敏捷开发方法通常应用时间定量的迭代和进化式开发、使用自适应计划、提倡增量交付并包含其他提倡敏捷性的价值和实践。由于特定实践多种多样，因此不可能精确地定义敏捷方法。
12. 建模的目的主要是为了理解，而非文档。
13. 建模的目的是发现、理解和共享大家的理解。所以不要单独建模。
14. 敏捷方法通常应用时间定量的迭代和进化式开发。
15. 开发就像登一座以前从来没有登过的山一样只有登到一定的高度才能看到不接下来会遇到什么困难能不能解决，而不是在山底把所有的困难都预测到再开始登山，因为大部分预测跟实际情况都不一样不可能完整的预测出会遇到哪些问题(既浪费时间又不准确)。
16. 需求就是系统必须提供的能力和必须遵循的条件。
17. 需求分析的最大挑战是寻找、沟通和记住什么是真正需要的，并能够清楚的讲解给客户和开发团队。
18. 在UP和其他进化方法中，具有产品品质的编程和测试要远早已大多数需求的分析和规则化或许当时只是完成了10%到20%的需求规则说明，这些需求都具有重要的架构意义，存在风险以及具有高业务价值。
19. 瀑布式开发被证明是拙劣的，并且导致了大量的失败。这种过时信条的错误根源是：将软件项目与大规模制造业项目视为等同，而后者是可预测的，并且具有低变更率。但是软件属于具有高变更率的新产品开发领域，具有大量新奇事物，需要大量的发现和探索。
20. 需求的性能和种类:功能性，可用性，可靠性，性能，可支持性。简称FURPS+，该分类方案作为需求范围的检查列表是有效的，可以避免遗漏系统某些重要的方面。
21. 用例的另一个价值是强调用户的目标和观点。我们会提出这样的问题：“谁使用系统？他们使用的典型场景是什么？他们的目的是什么？”与查询系统特性清单相比，以上问题更强调以客户为中心。
22. A型行为，过于关心那些次要的问题。

转载于:https://juejin.im/post/5a84fc9f51882528b63fff50