提问回顾与个人总结

提问回顾与个人总结

项目	内容
本作业属于北航软件工程课程	博客园班级链接
作业要求请点击链接查看	作业要求
我在这门课程的目标是	系统学习软件开发理论和流程，通过实践积累软件开发经验
这个作业在哪个具体方面帮助我实现目标	总结一学期学习的收获

一、链接到以前提问题的博客

软件工程个人博客作业中我在以下五个方面提出了问题

• 关于goto使用的问题
• 关于复审的问题
• 关于任务时间估计以及划分
• 构建自动化验证测试的输入数据设计问题
• 关于创新与重构的问题

二、对以前问题的解答

• 关于goto使用的问题

  函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。

  书中第四章代码设计规范4.3.2中提到为保证函数出口唯一，可以使用goto，但是根据我在程序设计课程和面向对象课程中的学习来看，老师都是极力阻止我们使用goto，原因是goto打乱了代码的结构，不易于之后的阅读和调试，这里却说goto有助于程序逻辑清晰体现，这之间是否冲突？如果不冲突，如何在代码结构和程序逻辑之间找到一个平衡点？

  解答：有人证明任何程序都可以用顺序、分支和重复结构表示出来。这个结论表明，从高级程序语言中去掉goto语句并不影响高级程序语言的编程能力，而且编写的程序的结构更加清晰。但是对于C++语言来说，程序员需要自己管理资源的分配和释放。倘若没有goto语句，那么在某个函数资源分配后的每个出错点需要释放资源并返回结果。虽然可以不使用goto语句完整地写完流程，但是代码将变得又臭又长。加入goto语句之后，流程会变得更加清晰。

• 关于复审的问题

  复审者必须逐一提供反馈意见。注意，复审者有权提出很多看似吹毛求疵的问题，复审者不必亲自调查每一件事，开发者有义务给出详尽的回答。

  书中第四章4.4.2代码复审的步骤第6条如上，我并不觉得开发者必须详尽回答复审者每一个吹毛求疵的问题，因为很多时候不是开发者代码的问题而是复审者没有理解代码，如果复审者并没有仔细弄清楚代码的原理，自然会有很多不明白的地方，如果不自己研究而是每个问题都去问开发者，那会不断的打断开发者当前的任务，极大地拖慢开发者的进度，我觉得复审者还是应该有一定程度的调查之后，如果还有不明白的地方再去问开发者会更好。

  解答：通过这一学期的学习，我深刻的认识到了复审的重要性，也碰到了由于复审不仔细导致合并之后出现一系列问题，复审者必须要理解开发者修改的每一行代码，不能感觉没什么大问题就一笔带过，做到吹毛求疵是很有必要的。因为复审者同时也是开发者，所以遇到无法理解的地方直接找开发者解答反而能够节约时间。

• 关于创新与重构的问题

  如何帮助创新软件工程中有没有一些做法是帮助创新的呢？当然有很多，例如：快速原型，持续重构，在每一个里程碑之后做总结，等等。

  书中十六章创新16.6的第4问中提到持续重构能帮助创新，但是在面向对象课程的学习后了解到好的代码必须有很强的可扩展性，尽量避免重构。重构到底是好是坏？创新和好的代码架构是否有冲突？

  解答：通过学习《重构》这本书，我了解到了面向对象课程中要求的尽量少重构的意思其实是从设计角度来说的，在设计阶段就开始预测未来的需求变动并设计出一个好的架构以不变应万变。而真正的需求变动是十分频繁的，优秀的程序员也无法保证第一次写的代码能适应未来所有的变动；书中所说"重构与设计是互补的"，也就是说新需求来临时，如果维护原有的设计成本过高时，就应该考虑重构，防止代码过于臃肿。而设计并不是一定要越巧妙越好，如果能很容易的通过重构来适应需求的变化，那么就不必过度的设计，当需求改变时再重构代码。

三、不明白的问题

• 关于任务时间估计以及划分

  软件工程师在长期的实践中，摸索出一套经验公式：实际时间花费主要取决于两个因素—对某件事的估计时间X，以及他做过类似开发工作的次数N。

  Y = X ± X ÷ N //注：Y是实际时间花费。

  ——8.6

  在项目开始之前，有很多队员还没有接触过编程语言（例如C#），导致PM在分配任务时很难用时间来衡量，就拿写一个Web Service这一模块来说，一个熟练的程序员可能只需要两个小时，而对于初学者来说，就得先花两天来理解Web Service的实现机制和原理。在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。这时应该怎么办？

  阿超：对于这些队员，可以考虑在他们自己的任务估计值之上再乘以4。

  ——11.6

  如果一个任务的估计时间太长（如超过16个小时），那么它就应该被进一步分解。

  ——6.1.2

  以我在团队项目的经历来说，在项目初期以天为周期制定任务效果并不是很好，因为对项目不熟悉一个任务可能要三四天才能完成，每天验收实际成果并不明显，也会出现为了赶时间而导致代码质量下降的问题。很多时候，一些看似很简单的问题也需要很多时间去解决，所以时间估计是一个难题，通过这学期的学习，我还是无法做到准确地估计完成任务的时间。

  修改bug这类任务往往不好划分，因为可能出现问题的地方不止一处，可能涉及到多个人的代码，对于代码架构较差的项目前后端都可能出现问题。交由一个人解决定位问题所在需要花费大量时间，交由多个人解决又需要考虑沟通成本。

• 构建自动化验证测试的输入数据设计问题

  顾名思义，构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。在大多数情况下，这些验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。

  这次团队项目我主要负责前端，对于后端代码可以使用覆盖率测试，但是前端代码的测试只有代码风格检查以及人工手动测试。前端是否也存在可靠有效的覆盖率测试呢？

四、新的问题

• 每日例会真的是必要的么？

  就如同之前所说，由于个人时间安排以及实际写代码时可能出现的意料之外的问题，每日进行进度检查的效果并不明显，通过团队项目的练习，我认为两到三天进行一次例会汇报进度效果会更好，因为两到三天足够完成至少一项任务，对于遇到困难而无法按时完成任务的同学也能在例会结束后分配其余成员与其共同解决问题，保证项目的进度稳步推进。

五、“做中学” - 在实践中学习知识点

• 需求

  学习了NABCD需求分析，从目标用户的角度出发制定需求分析。

• 设计

  分为功能设计和技术规格设计。先从需求出发，制定相应的功能设计文档，明确开发的大方向。之后再由对应的成员进行讨论，制定出技术规格文档，规定实现功能的技术，这样能节省写代码时纠结使用什么技术来实现的时间，也能使代码的风格统一，便于之后加入的成员理解。

• 实现

  保证每一次提交都必须可运行，在每一次提交前都要先进行回归测试保证原有功能正确，在代码互审时，首先要告诉复审者自己修改的思路以及每处修改的理由，之后还要展示所改动的模块是否工作正常，复审者在审完代码后还要自己进行测试，保证产品时刻可运行。

• 测试

  对于前端使用ws自带的代码风格检查以及人工手动测试，在使用网站的时候如果发现问题，立刻写入项目的issue。对于后端使用覆盖率测试，保证后端api可用性。

• 发布

  在alpha阶段实现了最小可用版本，发布给用户使用。在beta阶段对功能进行扩充，更好地满足用户需求。在发布阶段也学习了一些基本的推广技巧，向其他大学的学生推广了我们的产品。

• 维护

  设置了用户反馈入口，收集用户反应的bug以及对我们产品的建议，针对用户的反馈我们也在力所能及的范围内进行修改和调整。

六、心得

• 个人项目

  体验了软件工程的基本流程，在这之中我学会了单元测试的使用，体会到了单元测试的便捷之处，不过我对个人项目印象最深的还是容器的重要性，计算的时间只是鸡毛蒜皮，容器的查找和插入的时间就能占到95％以上，容器选的不好，做再多其他方面的优化也是白搭，相反容器选的好纯暴力算法应该都能在规定时间内运行完。

• 结对项目

  第一次进行多人编程，感觉还是比较新颖的，但实际上我们并没有做到真正的结对编程，只是把任务分成两份，两人分别来完成，在一定程度上确实减小了每个人的工作量，效率也比一个人编程要高。

• 团队项目

  在the_Agiles团队，我学会了基本的js语法以及vue的使用，因为团队的初始理念是把每个人培养成全栈选手，所以我虽然是负责前端，但对后端的ruby代码也有一定的理解，能做到修改前后端代码来实现新的功能。

  在敏杰开发团队，我学会了github在多人开发时的项目管理流程，新团队的成员对我十分友好，耐心且细心地为我介绍新的项目，使我很快就融入了新的集团。

  我很荣幸我所在的两个团队的氛围都十分融洽，在我遇到困难时都能及时为我伸出援手，两个团队的成员都十分优秀，与他们合作的过程中通过阅读他们的代码我感觉自己代码水平也有很大的提升。

  团队合作是一个全新的体验，为了不拖团队的后腿，我也一改之前喜欢拖延的毛病，尽可能及时交付任务。虽然团队项目这几个月非常辛苦，但确实是一段值得珍惜的回忆。