软件工程管理——第二次作业
1. 代码规范（读教材）
读了《构建之法》中关于代码规范的章节，笔记加个人理解如下。
为什么要规范代码？ 有利于代码维护，有利于代码评审，有利于团队合作。
1.1 代码风格规范
代码风格规范——个人理解就是代码的排版。
1 注释：解释程序做什么。
—— 不要写不必要的注释。
—— 注释与代码同步。（代码变动需要注意注释是否需要修改）
—— 注释与团队合作。 很多人在实际的开发中往往不重视注释，没有好的注释，团队成员合作是会受到影响的。假如你发布了几个类似功能的接口，如果你在注释中很好的解释了接口的功能，输入参数限制等，其他人通过你的注释就会明了使用你发布的哪个接口。反之，需要去研究你的代码实现——若你的实现很复杂，调用很多其它接口，理解起来困难耗时，影响团队合作。
2. 换行：每行只写一条语句；每行只定义一个变量；用空行分割小功能块。
3. 缩进：建议使用4个空格或是把tab设定为4个空格。
分支结构，循环结构中使用缩进。
4. 大括号：分支结构，循环结构中使用大括号，即使仅包含一条语句。
5. 命名：第一个单词全部小写，其他单词首字母大写。
函数名采用动词，动名词；其他采用名词。
6. 行宽：80字符或100字符。
1.2 代码设计规范
对于代码风格规范，相信大家都有所了解，遵守了很容易做到。（有些开发工具可以帮助自动设定好风格规范，除了代码注释， 开发的时候可以不用过多关注。） 但对于代码设计规范，很多人就不是很了解了。教材对代码设计规范的一些通用原则做了很详细的介绍，仔细的读了两遍，发现这方面如果要做好，需要慢慢训练。
1. 函数功能唯一：一个函数只做一件事，并且要做好。（函数代码行数建议80行，最多200行）。
2. 函数参数校验：Debug版所有参数进行校验；正式版本对外部传参进行校验。
3. 一个函数最好有单一出口，有利于逻辑控制。
4. 错误处理：当对某件事不确定时，需要写代码处理可能发生的与预期不符的错误情况。
5. 断言的使用：当对某件事很肯定，就这一种预期结果，不允许出现其他结果，此时可使用断言。
6. 代码重用性——（TODO）注意利用语言、类库、框架里提供的方法。
7. 日志 ——记录关键重要信息（例：购票系统中，记录谁在什么时间买了什么火车票）
便于查找bug。
（建议调用标准库或者系统API）
2. 列出一个checklist
| 阶段 | 检查项 | 结果 |
| 需求分析 | 检查是否有需求遗漏 | |
| 检查是否进行了需求设计书评审 | ||
| 检查是否进行了测试用例设计评审 | ||
| 设计 | 检查是否进行了Demo或界面原型评审 | |
| 检查是否进行了概要设计评审 | ||
| 检查是否进行了详细设计评审 | ||
| 开发 | 检查代码的功能是否实现所有需求 | |
| 检查代码的效能 | ||
| 检查是否进行单元测试 | ||
| 检查代码的可移植性 | ||
| 检查是否遵从代码风格规范和设计规范 | ||
| 检查代码是否有硬编码 | ||
| 检查是否有无用代码未删除 | ||
| 检查是否有可优化代码 |
3. 效能分析和测试
关于效能分析：看了教材中关于效能分析的介绍，正如书中所说，不要随便猜测，要进行实际验证，数据才更具有说服力。
尤其作为新手和这方面经验不足的人，只有你实际验证过了，逐渐掌握的多了，才能像别人那样直接指出效能差的地方。
关于测试：
4. 用户需求
5.1 功能需求
5.2 非功能需求
5. 过程控制：燃尽图、鱼刺图、甘特图
6.1 燃尽图
燃尽图：用图形展现故事点随时间的变化情况（对故事点理解的不好）。
试着自己画了一个燃尽图（在这里假定有5项任务：1. 编写概要设计 2. 编写详细设计 3. 开发代码 4. 测试 5. 发布）
其中： Y轴代表任务数（燃尽图的Y轴一般描述故事点）； X轴代表时间 （时间以天为单位）。
在执行整个过程开始，根据计划，画出了如上图中红色线的一条参照线。（红色参照线是计划的理想情况，随着时间的推移，剩余任务数逐渐较少）
图中黑色线条代表了整个过程中剩余任务数随时间变化的实际曲线。
从整个黑线可以看出3.17，3.21日新添加了2个任务，但在3.18——3.23黑色线条一直在红色参照线的下方，说明最初的计划高估了完成任务所需时间。
燃尽图——方便管理者可视化的观测工作随时间的变化，根据实际燃尽曲线和参照线的差异做合理调整。
通过燃尽图如何评价过程控制的好坏呢？若燃尽曲线在参照线上下小浮浮动，说明该过程控制计划很合理，无需调整；若燃尽曲线在某一天后一直在参照线上方，则说明该计划有风险，可能要延期，需要及时调整；若燃尽曲线在某一天后一直处于参照线下方，说明高估了任务完成所需时间，也需要调整。
注：燃尽图中不展现具体任务。
6.2 甘特图
在6.1中用燃尽图，我们看到的是剩余任务数随时间的燃尽情况，无法通过该图来观察到具体有哪些任务，也无法观测到还剩下哪些任务，各个任务进行到了什么阶段。
甘特图描述了整个计划中具体任务与时间的关系。
6.3 鱼刺图
6. 互评博客
进行了互评，只评论了一人。
7. PSP
| job | type | date | start | end | total(min) |
| 编写随笔大纲 | 随笔 | 2016.03.14 | 12:30 | 12:46 | 16 |
| 代码规范 | 读书 | 13:00 | 13:30 | 30 | |
| 更新随笔：代码风格规范读书笔记 | 随笔 | 13:31 | 14:13 | 42 | |
| 更新随笔：PSP | 随笔 | 14:13 | 14:26 | 13 | |
| 更新随笔：代码设计规范读书笔记 | 随笔 | 2016.03.15 | 08:10 | 08:33 | 23 |
| 更新随笔：checklist | 随笔 | 9:30 | 10:11 | 41 | |
| 了解燃尽图，甘特图，鱼刺图 | 读书 | 2016.3.16 | 09:35 | 10:21 | 46 |
| 更新随笔：燃尽图 | 随笔 | 12:00 | 13:20 | 80 |
8. 选做：从范围的角度，对比一类软件（3个软件）
