标签：评价 而不是 分类 程序员 统计 用户 建立 集成测试 智慧
在项目开始之前：
需求需要挖掘，而不仅仅是收集。找出用户为何要做特定事情的原因，而不是他们目前做这件事情的方式。 建立需求文档：把形式化的模板做备忘录 好的需求文档会保持抽象 项目范围的增大需要被记录和可追溯，以及可评价(通过统计信息) 需求的收集和设计实现不是单向的线性关系，而是双向关系。它们是“交付高质量的系统”的不同方面。 解开谜题 解开谜题的关键在于确定施加的各种约束，并确定你确实拥有的自由度 确定真正的约束 对约束进行分类，并划定优先级 你所需要的知识真正的约束，令人误解的约束，还有区分它们的智慧。 编写程序规范 编写程序规范是一个交流活动，旨在解释并阐明系统的需求 不要追求捕捉系统或需求的每一处细节和细微差别，因为细节不一定可以被自然语言以可理解的方式定义。 不要陷入对规范的追求中，在合适的时候编码，反哺规范。 不要做方法的奴隶，适合的就是最好的，能解决问题就行。
注重实效的项目：
不符合用户期望的项目注定是失败的。即以用户为中心。 使项目级活动保持一致和可靠的一个最重要的因素是使你的各种工作流程自动化。 项目的各种活动，分析，设计，编码，测试不会孤立地发生，它们是看待同一问题的不同方式。 在开发一个项目时，我们再寻求内聚的，在很大程度上自足的团队。使用组织代码使用的技术，像合约，解耦，正交性，这样的技术来组织各种资源，有助于使团队作为整体与变化的各种效应隔离开来。 测试： 早测试，常测试，自动测试。 要通过全部的测试，编码才算完成。 集成测试说明组成项目的主要子系统能工作，并且能很好的协同。 测试状态覆盖，而不是代码覆盖。 大多数测试都应该自动完成。 注释：注释应该讨论为何要做某事，它的目的。代码已经说明了它是怎样完成的。
标签：评价 而不是 分类 程序员 统计 用户 建立 集成测试 智慧
原文地址：https://www.cnblogs.com/lijiawei1-2-3/p/11933806.html
