【读书笔记】代码大全28章：项目管理

• 鼓励良好的编码习惯
  • 制定编码规范
    • 使用灵活的编码规范
  • 鼓励良好编码规范
    • 项目的每个部分都分配两个人
    • 审查每一行代码
    • 做好代码验收工作
    • 将好的代码用来审查
    • 强调“代码属于大家”
    • 程序员写了良好的代码要给予奖励
      • 给程序员想要的东西
      • “良好”指的是特别好，大家都认可的“好”
    • 制定单个简单的标准
      • 比如：我必须能读懂项目中的一切代码
  • 本书的目标：提供良好的编码规范
• 配置管理
  • 什么是配置管理
    • 配置管理就是系统地控制项目中的各种变化
  • 需求和设计的变更
    • 采用科学的变更程序
    • 通过团队处理变更
    • 估算每个变更的成本
    • 小心太多变更
    • 小心官僚主义，但是不要害怕官僚主义
  • 源代码变更
    • 版本控制工具
      • 好处
        • 两个人可以同时修改一个文件
        • 可以通过一行命令轻松地更新整个项目
        • 可以查看任何历史版本
        • 可以查看任何一个版本做了哪些改动
        • 无需备份源代码，因为版本控制已经在这方面做的很好了
      • 工具版本
        • 有时候编译器、库都要放到版本控制中，这样构建历史版本的时候就不用额外配置了
    • 运行环境配置
      
      • 可以通过虚拟机来统一大家的开发环境
    • 备份计划
      • 程序看不见摸不着，很容易丢失，所以备份是必须的
      • 备份完之后记得测试
• 估算项目工时
  • 估算方法
    • 利用估算软件
    • 用估算算法，比如Cocomo II
    • 引入外面的估算专家
    • 开会讨论
    • 估算每个部件的工时，再相加
    • 根据之前项目的经验
    • 参考之前项目的估算结果，并根据之前项目的完成情况作出相应调整
    • 设立估算目标
    • 给定充足的时间
    • 细节考虑越多，估算结果越精确
    • 采用多种不同的估算方法
    • 没有一种通用的方法
    • 每隔一段时间重新估算
  • 估算编码用时
    • 项目越大，编码所占的时间比重越少
  • 项目工时的影响因素
    • 人员的分布情况（同一个地方工作还是不同地点工作）
    • 数据库大小
    • 项目可用的文档数量
    • 需求的灵活性
    • 项目风险
    • 语言和工具的熟悉程度
    • 人事变动
    • 平台的可变性
    • 业务流程的成熟度
    • 程序员的能力
    • 可靠性需求
    • 需求分析能力
    • 重用性需求
    • 是否注重美工
    • 磁盘储存限制
    • 团队团结程度
    • 团队在项目方面的经验
    • 团队在技术平台方面的经验
    • 时间限制
    • 工具的使用情况
  • 估算和控制
    • 估算和控制是两个相互对立的两个观念
  • 如果项目进度落后了怎么办？
    • 告诉自己可以跟上进度的，因为后面的工作可能可以很快做好
    • 增加团队成员。《人月神话》说这点不可取，但是在项目可以拆分的情况下是可以这样做的
    • 减少需求数量
    • 对不重要的功能重新估算工时
• 项目的度量
  • 原因
    • 度量总比没有度量要好
    • 数据分析一定要有数据
  • 可度量的变量
    • 软件大小
      • 代码行数
      • 注释行数
      • 类的数量，函数数量
      • 变量数量
      • 空白行数
    • 缺陷跟踪
      • 每个缺陷的严重性
      • 每个缺陷的位置
      • 每个缺陷的源头（需求、设计、构建、测试）
      • 每个缺陷是如何修复的
      • 每个缺陷的负责人
      • 修复缺陷修改的行数
      • 修复缺陷所用的时间
      • 找出缺陷的平均时间
      • 修复缺陷的平均时间
      • 修复缺陷尝试次数
      • 修复缺陷产生的新缺陷
    • 生产力
      • 项目花费的工时
      • 每个类或函数花费的工时
      • 每个类或函数修改的次数
      • 项目的支出费用
      • 每行代码的支出费用
      • 每个缺陷的支出费用
    • 全局质量
      • 缺陷总数
      • 每个类或函数的缺陷总数
      • 每千行缺陷数
      • 编译器检测不出隐含错误的平均时间间隔
    • 可维护性
      • 每个类的公共函数
      • 每个函数的参数数量
      • 每个类的私有方法或变量
      • 每个方法中的本地变量个数
      • 每个类或函数调用其他函数的次数
      • 每个类或函数中的逻辑分支数量(if/while/for等)
      • 逻辑分支的复杂程度
      • 每个类或函数的行数
      • 每个类或函数的注释行数
      • 每个类或函数中的变量或常量定义次数
      • 每个类或函数中空白的行数
      • 每个类或函数中goto关键字使用的次数
      • 每个类或函数中输入输出语句的数量
    • 不要一开始就搜集所有的这些数据，从最简单的几个数据开始
• 请把程序员当人看
  • 程序员的时间组成
    • （有一张很大的表格）
    • 从事情的目的来看，大部分时间在做编码有关的事情
    • 从事情的方式来看，大部分时间在谈话或者听。
  • 不同的程序员写出的代码性能和质量差别很大
    • 人和人之间比较，最好的和最差的：
      • 速度方面相差20倍
      • 调试时间相差20倍
      • 程序大小相差5倍
      • 执行速度相差10倍
      • 统计研究表明：程序员的经验和代码质量、生产力关系不大
    • 团队之间比较，最好的和最差的：
      • 努力程度相差3.4倍
      • 程序大小相差3倍
      • 开发速度相差2.6倍
    • 习惯问题
      • 编程语言
      • 缩进风格
      • 括号的位置
      • IDE
      • 注释风格
      • 可读性和性能两个方面的偏好
      • 开发方法的选择——Scrum、极限编程、evolution delivery
      • 编程效用
      • 命名规范
      • goto的使用
      • 全局变量的使用
      • 生产力等
    • 工作环境
      • 办公室面积
      • 安静的环境
      • 隐私环境
      • 轻声打电话
      • 呼叫转移
      • 频繁地打扰
      • 让人觉得高贵的环境
• 处理好自己与主管的关系
  • 有些管理员虽然技术方面有很丰富的经验，但是技术是很容易过时的，以前的经验在当前环境中不一定适用
  • 几个方法
    
    • 想好你想做什么，然后等你的主管对你的想法做一次头脑风暴
    • 跟主管说明正确的做法。这种方法适合走长线，因为主管也想要进步、升职。这是最好的做法，推荐卡耐基的《人性的弱点》
    • 和主管说话的时候要关注主管感兴趣的地方，了解他真正想做的事，不要说一大堆难懂的设计细节
    • 坚持自己的主见，不要听主管的
    • 辞职