构建-note1

1.构建不是写代码

构建不是写代码

将构建等价与代码施工会产生不可接受的成本消耗，比如在实现的初期忽略掉巨大的可行性风险引发施工后发现解决方案不可用，在与需求拉扯的中期，会产出糟糕的不良代码，在后期会缺少自测手段和自测稳定性保证，导致不是产生巨量的产品风险就是巨量的测试和修bug工作量。

正确的构建流程

值得关注的几步

• 构建计划的第一件事情就是安排好测试计划，包括单元测试，集成测试，系统测试和安插在功能里的GM调试工具，日志，然后才是后续步骤的工作安排

---

一个Feature基于迭代开发的构建计划

构建计划

这是经过实际生产情况考量后产生的Feature构建计划。首先是通过Feature Task Job这三层结构，明确了构建一个合格的Feature在各个阶段需要做好哪些确切的工作，接着在Task和Feature层面都插入了可行的测试工作或任务，保证这个Feature在开发的各个时期都是高质量的。

如果我们总是急不可耐，想下一秒就事成，而拒绝繁多平凡的工作，最终什么事情都不会发生

确定Task需求案

只一步看起来开发的工作量是轻松的，可是一个优秀的开发将在这个工作上花费他60%用于构建这个task的时间，因为这个工作既至关重要又工作量巨大，我将这些工作罗列在一下几点中，完整的条例可以查有关书籍¹

零. 针对需求案的挑战

• 用户是这么认为这个功能吗？
• 每条需求会相互冲突吗？
• 如果存在两条需求是竞争关系，怎么处理权重？
• 需求是否足够清晰
• 需求是是否可以测试，是否可以然别人测试
• 未来六个月对于这个需求的可能变动

一. 针对于业务功能的正确性，我们要重点关注的内容。

• 我们是否考虑并知晓了所有的用户交互。
  1. 所有的用户输入接口
  2. 所有的对用户输出接口
  3. 所有的用户行为
• 我们是否考虑并知晓了所有的程序交互
  1. 对本地环境程序其他模块的交互，设计和管理需要确定好。
  2. 对网络远端的程序进行交互。

二. 针对程序功能的质量 运行效率 结构合理

• 操作是否必要，如果必要，从用户的响应角度，合理区间在哪里？
• 为了满足上述点，时间上做不做的到。
• 安全级别，比如失灵了怎么办？
• 考虑这个任务成功是什么样的？失败是什么样的

Cursor对于这个构建计划的助力

---

1. 《代码大全2》42页 ↩︎