| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 软件工程任健班 |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 培养软件工程能力，取得大于85分的成绩。 |
| 这个作业在哪个具体方面帮助我实现目标 | 学完课程后，对自身所学知识和实践经验进行全面的总结。 |
一、链接到以前提问题的博客
二、对以前问题的解答
- 请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
- 是否原来的问题还不明白？如果有，请分析。
- 是否产生了新的问题？如果有，请提出。
问题1：效能提高
第33页：将代码段
for(int i = 0; i < m_wordList.Count; i++)
优化为
int count = m_wordList.Count;
for (int i = 0; i < count; i++)
第44页：
大家也要注意避免没有做分析就过早地进行“效能提高”。
问：类似上述代码的优化，是否可以视为必然能够提高效能，而无需每次都进行分析呢？
解答：这种优化过于细枝末节，不分析也没有什么太大的影响。
追问：书上举的“小伞追女生”例子不够贴近实际开发，请问有没有结合实际工程的例子？
问题2：开发与测试的对立
有些团队把开发和测试有意无意地对立起来，好像二者是矛盾的。
这种对立情绪，也许在短期内能刺激成员的工作热情，而从长远来看是有害的。
——第7章 第137页
问：北航计算机学院某课程的每份作业都采用如下的评分标准：修课的同学代码随机分配至其他人手里，找出别人的BUG会为自己加分，而自己的程序被别人找出BUG会被减分。这种评分规则是否可以看作违反了上述原则，而应被废止或修改呢？
解答：在那篇博客后面的评论区与邹欣老师讨论了一下这个问题。这种评分制度作为本科生课程有其存在的必要，而出现的乱扣分现象可以通过制度的持续完善得以解决（据说今年该课程对此作出了重大改革）。
注：应任健老师建议，课程名称已经略去。
问题3：第8章 需求分析 之中的内容，有一部分与北航经管教材上的知识重合。例如167页的“用户满意度模型”、177页的“分而治之”思想。
可否认为软件工程在进行需求分析时，较多地借鉴了传统管理学知识？或者认为软件工程是管理学的一个分支？
解答：这个问题主要是跟助教进行讨论。
软件工程研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。
所以软件工程这一学科必然结合了管理学知识技能。认为软件工程是管理学分支则是错误的。
问题4：11.5.2 每日构建（235~237页）
这一节的写作有些漏洞。阿超与小飞的对话，主要论证的是“构建”的重要性，却忽略了论述“每日”进行构建的必要性。
所以，每一天都进行构建工作是否是有必要的？如果不是，这一名称是否有修改的必要？
解答：“每日”不应当死板地理解为每一天，指的是经常性进行构建。经常性进行构建其实是十分必要的，待一个模块写好且通过单元测试后，就应当尝试构建从而尽早发现更高层次的问题。
问题5：第14章 质量保障 第312页
作者设想了第三方的软件质量认证服务将为人们的生活带来的便利。那么，第三方认证软件质量为什么尚处于起步阶段，其难点在哪里？
回应：依然不能给出合理的解答。第三方认证软件质量没有取得太快的发展，其原因可能是多方面的，涉及的因素很可能与软件工程无关。
三、请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。
需求：竞争性需求分析的框架NABCD
NABCD之前作为博客作业布置过。这几个字母分别代表Need, Approach, Benefit, Competitors, Delivery。由于公客网项目有两个组在做，因此我们必须要考虑在功能上进行创新，从而形成竞争优势。例如我们在Gamma阶段推出了他们组没有的“管理员”功能。
设计：实体关系图（Entity Relationship Diagram, ERD）
表达现实世界中的实体和它们之间的关系的一种设计图。下图为本人绘制的公客网项目ERD图：
实现：源代码管理
使用合适的源代码管理工具，可以更方便地进行版本管理、测试和修复缺陷。我们组使用Github作为源代码管理工具，并采用了GitFlow模型进行分支管理。
测试：场景测试（Scenario Test）
以场景为驱动的集成测试。场景测试需要考虑在现实环境中用户使用软件的流程是怎样的，然后模拟这个流程，看看软件能不能满足用户的需求。
例如用户注册时输入某些邮箱会导致后端误报"mail repeated"的缺陷，就是在场景测试中被首先发现的。
发布：软件项目的会诊（Triage）
在发布之前进行，确定哪些BUG必须修复，哪些BUG需要留待下一个版本修复，等等。
在Beta阶段末期，我们发现了网站上传用户头像上的一些BUG（没有进行格式检查、没有实现剪裁等）。经过会诊，我们最终决定将这些问题留待Gamma阶段解决，以保证产品的按时发布。
维护：完善性维护
完善性维护是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。另外，还包括对处理效率和编写程序的改进，这方面的维护占整个维护工作的50%～60%，比重较大．也是关系到系统开发质量的重要方面。这方面的维护除了要有计划、有步骤地完成外．还要注意将相关的文档资料加入到前面相应的文档中去。
——引用自百度百科“软件维护”
由于公客网项目是在往届学生的基础上继续开发，因此我们所做的工作主要是完善性维护。我们在Beta阶段补齐了文档，增加了许多公客网一开始设计时没有考虑的功能（例如管理员和用户头像）。
四、结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
结对编程：
这次结对编程的经历可谓一团糟，用“灾难性”来形容都不为过。自己归纳了以下几点原因：
一是自己确定团队太晚，而且那几周在忙着准备GRE考试，所以留给我们编程的时间其实十分有限了。二是两个人的课表重合的时间不多，因此一起编程的时间比较少。当然这也是我们思想过于僵化了。本可以采取分一部分任务各自完成的形式。尽管这有违结对编程的形式，但是可能对整体项目完成帮助更大。
第三，也是最重要的一点，就是两人没有进行随时随地的复审，违背了这一项目设计的初衷。个别问题（例如文件路径的放置）如果换成是我自己独立完成想必更容易发现从而避免，然而潜意识里把责任推给了队友，最后两个人的成绩都惨不忍睹。
当然有了这次的失败经历，估计我以后再也不会采用结对编程了。。。
团队项目：
我们团队选择了“公客网”课程评价网站作为团队项目，团队名称是“笨拙软件工程”。我本人承担了三个阶段的测试工作，以及Alpha阶段的UI设计工作。
团队整体成果还是令人满意的，但是我后两个阶段的个人贡献分都在组里排倒数，所以可以预见这部分的得分也不会高。
团队整体上成功的心得：
一是项目选择的策略比较合理。团队部分成员通过学习“数据库原理课程设计”课程，已经掌握了基本的数据库、网站构建知识技能。课程评价网站整体上比较“接地气”，团队成员自身对此就有很多深刻的认识，可以少花一些时间精力在用户调查、需求分析上，推广也稍微容易一些。
二是项目管理上比较成熟。无论是Alpha阶段的PM WWJ，还是Beta, Gamma阶段的PM ZYN，都能够做到定期组织开会、合理分配任务。ZYN擅长用思维导图的形式展示任务之间的关系和项目整体的关系，是一个比较实用的技能。在组员的建议下我们采用了Git-Flow分支管理模型，避免了可能的代码冲突。
个人贡献低的理解：
其一是自己的软件编程能力本身就差，数据结构、算法和OO都是涉险过关，除了课程作业外自己从来不写代码。上个寒假由于在学习GRE，连电脑都没怎么碰过。编程能力欠缺、手感生疏，导致PM不敢把太多或太重要的任务分配给我。
其二是自己的态度比较被动，基本上PM说让干什么就干什么，没有自己主动要求承担任务的经历。也不太擅长经营人际关系。其它组员很可能通过巴结组长承担了更多的任务或是调高了自己任务的难度和完成度，从而拿到了更高的分数。