软件工程管理——第二次作业

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个软件）