提问回顾与个人总结

提问回顾与个人总结

项目	内容
这个作业属于哪个课程？	北航计算机学院2020春软件工程(罗杰 任健)
这个作业的要求在哪里？	提问回顾与个人总结
曾经提问的博客	阅读《构建之法》
我在这个课程的目标是？	学习工程化软件开发方法，提高设计与架构能力、团队协作开发能力
这个作业在哪个具体方面帮助我实现目标？	回顾与反思自己曾经提出的问题，总结一个学期以来软件开发的经历

一、请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。

问题1：

软件工程师比大四学生多读了3年书，多工作了3年，两类人任务的质量要求也不一样。我们可以看到，工程师在需求分析和测试这两方面明显地要花更多的时间（多60%以上）。
——第2章 个人技术和流程 第3节 个人开发流程

起初我认为：“花更多的时间做需求分析和测试”与“写出优秀代码”之间的关系，不是前因后果，而是前果后因。这是因为我站在普通学生的角度考虑，在平时的作业中，如果学生对编程语言不够熟练，或是设计与架构能力不足，导致在编码上耗费了大量的时间，以至于要赶在DDL之前完成作业，在这种情况下做需求分析和测试的时间很可能会比较紧缺。在我与其他学校的计算机专业的同学交流时，也曾经谈论过需求分析与测试的时间权衡问题，结果是同学们大多是粗略地做需求分析，测试也仅仅是为了拿到AC，缺乏系统而科学的分析与测试过程。

回答：

本学期的团队软件开发，让我从不同的角度看待写代码这件事情。大作业与一个真正的软件有很大的区别。首先很多大作业都可以用评测机来对代码正确性进行检测，这难免会导致很多学生“面向评测机编程”，而缺乏完备的自主测试；但是在软件开发过程中，很多情况下开发人员需要自行编写大量的测试样例进行检测，这要求我们必须具备良好的测试能力。其次，大作业的需求分析一般比较简单而明确，甚至有时会给出规格书、实验指导书等需求文档，这确实减少了很多需求分析上的工作量，也在一定程度上导致很多学生轻视需求分析环节；但是在软件开发过程中，很多情况下开发人员需要自己调查、分析需求，自行编写规格文档。

这些区别在一定程度上导致了工程师与在校大学生在开发过程中具有不同的偏好。站在软件工程的角度，需求分析和测试这两方面的确需要花费大量的时间。并且优秀的代码确实离不开详尽的需求分析与测试。

问题2：

函数最好有单一的出口，为了达到这一目的，可以使用goto。
——第4章 两人合作 第3节 代码设计规范

其实我当时也并非对这种说法提出质疑，只是从个人角度对其进行了补充，认为goto语句要尽量少用。

回答：

经过一个学期的软件开发，我对代码规范有了更深刻的认识。在保证正确性的前提下，代码规范让团队中的开发人员更加轻松地阅读、理解同事的代码，便于维护。作者提到函数最好有单一的出口，这一点在我们的开发过程中有所体现。本人曾经在一个函数中写了一个比较复杂的分支结构，返回结果的部分比较分散，结果在一个不易察觉的角落出现了bug。这让我在debug的过程中花费了较多的时间来理清我自己写的代码，让我明白了代码规范的重要性。而goto语句本身并没有什么bug，为了维护代码的规范性也可以拿来使用。

问题3：

只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。
——第4章 两人合作 第5节 结对编程

我当时提出的问题是：如果结对双方的水平差距较大，会不会导致实质上的决策权利失衡，或者两人的决策权利平等是否会导致开发的效率低下、影响代码的质量。

回答：

比较遗憾的是，我在本学期的结对编程中并没有找到这个问题的答案——因为本学期的情况特殊，我们的结对编程变成了分工编程。经过反复思考，我觉得作者提出这个观点的目的在于强调结对双方都具有决策的权利，与级别、资历无关。同时，作者也提出：只有水平上的差距，没有级别上的差异，我认为作者的侧重点在于软件开发过程中不应有论资排辈的现象，而水平上的差距导致的决策权利的失衡是自然而然的，无可厚非。

问题4：

下面是一个实际项目的燃尽图，有三个每天跟踪的时间值：实际剩余时间、预估剩余时间、实际花费时间。
——第6章 敏捷流程 第2节 敏捷流程的问题和解法

最终完成的工作量为524小时，是预计的1.5倍。（这暴露了什么问题呢？）

我提出的问题是：在实际开发中，如何准确地估计项目的耗时。

回答：

经过一个学期的团队开发，我对于项目耗时的预计有了更加深刻的认识。当一个团队拿到了一个比较陌生的项目，或是一个项目遇到了一个新建立的团队，这时对于项目耗时的预估是比较感性的、依靠直觉的。随着项目的推进与团队的磨合，大家对于项目的认识逐渐加深、对于彼此的开发节奏更加熟悉，对于项目耗时的估计就有了借鉴与经验。我们的团队开发中，起初对于项目耗时的预估也具有比较大的偏差，这导致我们在前期的开发过程中节奏较慢。后来，我们的开发周期逐渐固定（1-2天），在一个开发周期中的任务量有了更加准确的预计（对照之前周期的任务量），这使得我们的开发更加有条不紊，没有前紧后松、前松后紧的情况出现。

问题5：

但是，有些创新是颠覆式的(Dis-ruptive Innovation)，这些想法一旦出现，便会引起现有技术拥有着的极大不安。
可以看出，在算法和数据库领域，创新的想法一开始往往不被接受，而那些建立在前人基础上的“线性扩展”则往往有着更好的命运。
——第16章 IT行业的创新 第1节 创新的迷思

我当时的问题是，若真如作者所言，我们在将来从事计算机科学的研究，或者进入IT行业之后，是否要舍弃颠覆性地研究与创新，而安稳地在前人的基础上进行“线性扩展”。

回答：

经过反复阅读原文，我认为作者举了一些例子来说明现代IT行业在创新上的迷思，并非要打消读者的创新积极性。相反，作者从现实出发，在客观上讲述了哪些方面的创新会更加可行，哪些方面的创新会更具风险。普通人能够做到“线性扩展”已是不易，而颠覆性的创新也要有人来做，某些利益集团的阻挠无法使历史的脚步停歇。

二、产生的新的疑问。

1.代码的测试工作究竟由谁来执行。由于分工问题，我们团队中并没有专人来负责测试，而是采用自测+互测的形式来进行测试，一个学期以来并没有觉得有什么不妥。如果一个开发团队的规模较小（比如4-6人），那么究竟有没有必要设置单独的测试岗位？

2.如何进行工作量的统计。我们团队对于工作量的统计有一些主观的成分，比如对于issues的大小衡量。若完全根据代码量的统计结果来决定成员的工作量，也许会导致“注水代码”的现象出现：能用10行代码解决的问题要写20行代码。在实际的软件开发中，是否有更加科学的工作量的统计方法？

三、软件工程中学到的知识点。

• 需求阶段
  • 学到了NABCD需求分析法；采用一些方法获得用户需求与反馈：调查问卷、反馈窗口；学会根据用户的反馈进行设计上的修改。
• 设计阶段
  • 考虑多个因素：可行性、项目耗时与进度、审美因素、合法性等；从需求分析阶段提炼功能模块的技术要点；根据用户反馈调整设计。
• 实现阶段
  • 首先学习了微信小程序的原理，对于js熟练运用；其次亲身体验了团队协作，在分工与协作上积累了一定的经验；最后在反复调整与修改中锻炼了心态，亲身体会到成熟的架构需要一定的可扩展性。
• 测试阶段
  • 学会制定详尽的测试计划，编写了大量的测试样例；进行模块化测试，有针对性地对于不同的功能模块编写测试样例。
  • 进行了大量的互测，主要是验证对方的功能模块在不同情况下能否正常运行。
  • 基于微信小程序的官方IDE进行多角度的测试：页面调试、静态测试、真机调试等。
• 发布阶段
  • 学习了微信官方的审核与发布流程；认识到了推广的重要性，体会到了微信小程序平台的优越性——巨大的用户流量。
• 维护阶段
  • 不断搜集用户反馈，根据用户的反馈对软件进行调整；好的架构可以减轻维护与功能扩展的工作量。

四、结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。

• 在个人项目中，我认识到需求分析的重要性：作业中对于坐标值的精确程度要求极高，由于我对于需求的认识不足，仅仅用double类型来表示坐标值，导致精确度损失严重，正确性无法保证。充分的需求分析，保证了设计与实现的正确方向，事半功倍。
• 在结对编程中，我认识到沟通的重要性：由于我和队友在沟通上出了一点问题，导致双方的工作方向出现重合、任务划分不合理，使得最后的时间比较紧张、匆匆地交了代码。其实结对编程本来应该是两人一起编程，但是由于本学期的情况特殊，我们没能坐在一起进行项目开发。总之，良好的沟通能够提高软件开发效率。
• 在团队项目中，我切身经历了团队开发，和大家一起创造出一个可用的软件。一个优秀的软件开发团队需要一个能力出众、高瞻远瞩的PM，几个积极肯干的起带头作用的骨干成员，以及一些态度端正、编程基础扎实的成员。团队的风气与氛围需要得到正确地引领，不能死气沉沉、得过且过，也不能矛盾重重、勾心斗角。我们的团队虽然没有什么技术大牛、编程大佬，但是具有和谐与积极的氛围，这使得我们没有一个人掉过队，并且彼此之间能够进行高效、积极的沟通与交流。
• 总之，“纸上得来终觉浅，绝知此事要躬行”，很多事情要亲身经历才能有所收获。而软件工程就是这样一门“做中学”的课程，让我们在实践之中学习知识、积累经验，留下宝贵的回忆。