研发能力持续成长路线图-向华为学习研发管理，助推企业持续发展 96
4 - 产品中试管理
- 产品可靠测试与验证的基本概念和方法
- 在产品可靠性增长方面常见的设计补偿措施有
- 冗于设计
- 安全或保险装置
- 容错设计，降额设计等
- 工艺改进
- 补偿措施
- 预防措施
- 应急补救措施
- 在产品可靠性增长方面常见的设计补偿措施有
代码整洁之道 165
15 - JUnit 内幕
JUnit是最有名的Java框架之一，简单，精确，优雅。
16 - 重构 SerialDate
- 首先，让它能工作
- 让它做对
17 - 味道与启发
- 注释
- 不恰当的信息
- 废弃的注释
- 冗余注释
- 糟糕的注释
- 注释掉的代码
- 环境
- 需要多步才能实现的构建
- 需要多步才能做到的测试
- 函数
- 过多的参数
- 输出参数
- 标识参数
- 死函数
- 一般性问题
- 一个源文件中存在多种语言
- 明显的行为未被实现
- 不正确的边界行为
- 忽视安全
- 重复
- 在错误的抽象层级上的代码
- 基类依赖于派生类
- 信息过多
- 死代码
- 垂直风隔
- 前后不一致
- 混淆视听
- 人为耦合
- 特性依恋
- 选择算子参数
- 晦涩的意图
- 位置错误的权责
- 不恰当的静态方法
- 使用解释性变量
- 函数名称应该表达其行为
- 理解算法
- 把逻辑依赖改为无论依赖
- 用多态替代if/else 或switch/case
- 遵循标准约定
- 用命名产量替代魔术数
- 准确
- 结构基于约定
- 封装条件
- 避免否定性条件
- 函数只该做一件事
- 掩蔽时序耦合
- 别随意
- 封装边界条件
- 函数应该只在一个抽象层级上
- 在较高层级放置可配置数据
- 避免传递浏览
- java
- 通过使用通配符避免过长的导入清单
- 不要继承常量
- 常量Vs 枚举
- 名称
- 采用描述性名称
- 名称应与抽象层级相符
- 尽可能使用标准命名法
- 无歧义的名称
- 为较大作用范围选用较长名称
- 避免编码
- 名称应该说明副作用
- 测试
- 测试不足
- 使用覆盖率改进
- 别路过小测试
- 别忽略的测试就是对不确定事物的疑问
- 测试边界条件
- 全面测试相近的缺陷
- 测试失败的模式有启发性
- 测试覆盖率的模式有启发性
- 测试应该快递
从零开始学项目管理 158
9 - 风险管理，决战项目需要“步步为营”
- 项目风险的类别
- 按风险来源分类
- 按风险来源分类
- 按分析后果分类
- 按风险预警特性分类
- 项目风险管理的原则（前瞻性）
- 系统原则：识别，量化，评估（因素，风险）【人，流程，技术，组织，环境】
- 经济性原则
- 偏执性原则
- 满意原则
- 适当原则
- 社会性原则
- 连续原则
- 项目风险管理的几个概念
- 风险的本性：不确定性
- 风险管理的出发点：减少可能性，降低严重程度
- 风险管理的实质：角色与责任
- 风险管理的代价：额外的花费
- 项目风险管理的重要性
- 保证项目总体目标的实现
- 有助于理解项目建设意图
- 应付突发事件，明确责任
- 提高经济效益，减少损失
- 项目风险识别的方法
- 核对表分析法
- 图解技术分析法：事件树分析法
- SWOT分析法：优势Strengths，劣势Weaknesses，机会Opportunities，威胁Threats
- 德尔菲技术分析法：专家规定程序调查法
- 风险登记册
- 识别项目风险的注意事项
- 风险识别应该贯穿项目始终
- 风险识别应对允许形式多样化
- 风险识别应允许人人参与
- 分析识别应该变成一种”习惯“
- 风险识别应该关注”细节“
- 风险识别应注意”方法“
- 给项目风险评估一个指标
- 风险发生的可能性
- 风险后果的危害性
- 对风险的预测能力
- 风险发生的时间段
- 对风险的承受能力
- 风险可换取的收益
- 项目风险评估的方法
- 风险解析法
- 专家调查法
- 模糊数学法
- 蒙特卡洛模拟法
- 项目风险的应对措施
- 减轻风险
- 预防风险
- 转移风险
- 回避风险
- 自留风险
- 后备措施
- 项目风险的控制策略
- 首先处理高优先级风险
- 使用迭代，分阶段的方法
- 保证计划过程的质量
- 进行独立的质量保证审核
专业术语
- Actual Finish Date 实际完成时间
- Risk Event 突发事件
- Stakeholder 利益相关者
- Closing Process Group 收尾过程组
- Work Performance Reports 工作绩效报告
