《代码大全》笔记 03 - 三思而后行:前期准备

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/engrossment/article/details/88899305

豆瓣读书:https://book.douban.com/subject/1477390/

《Code Complete》2d ed,CC2

3.1 前期准备的重要性

  • 降低风险
    • 避免“解决了一个错误的问题”
    • 避免采用的开发方法不符合软件特点
  • 程序员是软件食物链的最后一环。产品经理挖出需求,架构师吃掉需求,设计师吃掉架构,而程序员则消化设计。

3.2 辨明你所从事的软件的类型

  • 三种典型的软件项目类别
    • 商业系统
    • 使命有关的系统
    • 性命攸关的嵌入式系统
  • 适合序列式开发方法的特点
    • 需求相当稳定
    • 设计直截了当,而且理解透彻
    • 开发团队对于这一应用领域非常熟悉
    • 项目的风险很小
    • “长期可预测性”很重要
    • 后期改变需求,设计和编码的代价可能比较昂贵
  • 适合迭代式开发方法的特点
    • 需求并没有被理解透彻,或是不稳定
    • 设计很复杂、有挑战性
    • 开发团队不熟悉这一应用领域
    • 项目包含许多风险
    • “长期可预测性”不重要
    • 后期改变需求、设计和编码的代价较低

3.3 问题定义的先决条件

  • 问题定义应该用客户的语言来书写,而且应该从客户的角度来描述问题,不应该使用计算机专业术语。
  • 如果没有明确的问题定义,那么你可能会在构建期间解决错误的问题。

3.4 需求的先决条件

  • 明确需求,无需再猜测用户想要什么。
  • 需求变更在很多情况下无法完全避免,因为开发过程帮助客户更深入地了理解了自己的需求。
  • 应对需求变更的方法
    • 确保每一个人都知道需求变更的代价
    • 建立一套变更控制流程
    • 采用能适应变更的开发方法
    • 放弃这个项目
  • 对照需求核对表进行检查,确保需求已做好。

3.5 架构的先决条件

  • 架构的典型组成部分
    • 程序组织,系统结构
    • 主要的类
    • 数据设计
    • 业务规则
    • 用户界面设计
    • 资源管理
    • 安全性
    • 性能
    • 可伸缩性
    • 互用性(与其他系统交互)
    • 国际化、本地化
    • 输入输出
    • 错误处理
    • 容错性
    • 架构的可行性
    • 过度工程(多做比必要的工作)
    • 关于“买”还是“造”的决策
    • 关于复用的决策
    • 变更策略
    • 架构的总体质量
  • 对照架构核对表进行检查,确保架构已做好。

3.6 花费在前期准备上的时间长度

  • 一般来说,一个运作良好的项目会在需求、架构以及其他前期计划方面投入 10% - 20% 的工作量和 20% - 30% 的时间。

对照前期准备核对表进行检查,确保前期准备工作已做好:

2019-08-24

 

展开阅读全文

没有更多推荐了,返回首页