软件工程作业-提问回顾和个人总结

项目	内容
这个作业属于	2020春季计算机学院软件工程(罗杰 任健)
这个作业的要求是	个人博客作业
我在这个课程的目标是	掌握软件团队工程化方法，提高自我软件编程能力
这个作业在哪个具体方面帮助我实现目标	回顾、总结一学期的软件工程实践，并给之后的软件开发留下经验
提问博客	软件工程作业1——序章
作业正文	如下

一学期的软工课，这么快就接近尾声了，我在实践中收获很多，对于之前困惑的问题，也都有了自己的见解，记录如下。

同时，也就在前天，我们大创的一个新的软件工程团队开了第一次信息交流会。会上有教授、有公司总经理、有研究生学长、也有计算机学院和软件学院的学弟。所以，下面的文章，也会部分整合信息交流会上不同角色的软件开发者，对于软件工程开发的看法。我也会对这次软工课的优秀经验做一个整理，以期应用在接下来实际的软件开发中。

提问回顾

1. 大学生和工程师PSP数据对比表，阅读思考后有以下问题

• 大学生和程序工程师在PSP的需求分析、具体编码、测试环节时长区别产生的原因是什么？

结合课外两个项目对实际开发工程师的了解，我写一个基于现有观察、但可能还不全部的回答

• 需求分析

  • 实际工程师在开发过程中，不会轻易的更换大的方法、或者工具。实际软件工程师，开发是需要签合同的。软件合同上，写清楚了合同额、交付时间、交付内容、验收依据，以及无法按时交付的惩罚。所以在软件最初需求分析阶段，需要对时间、内容、特性，都有精确的判断。同时，也需要确定使用什么开发工具，在什么时间节点需要完成哪些内容。 所以，可以部分认为需求分析的质量很大程度上决定了项目质量如何、项目能否按时交付，这两个关键性的问题。
  • 而对于我们学生而言，我们写软件不需要签合同，那也就意味着没有严格的交付时间和内容的要求。而且在需求分析环节，我们学生相较工程师，在开发经验、技术了解层面，都有很多不足。也就是，我们不太会需求分析，同时，即便我们花费很多时间去需求分析，我们很可能达不到工程师那种看清整个项目的效果。
  • 所以对于学生而言，需求分析可能是相比起工程师来说，最薄弱的一个环节。

• 具体编码，差距可能主要体现在两个方面：

  1. 学生团队的需求分析过程做的不够好，导致具体编码过程中可能要对开发方法和工具做反思，并且更换导致时间的耗费。
  2. 同样，学生的开发经验和代码熟练度，相较工程师团队略弱，这也是导致具体编码时间变长的一个原因。

• 测试环节

  • 软件工程师团队的测试是非常重要的，因为投入使用的程序出现致命bug的后果比较严重。所以，一些我接触到的商业软件，在投入使用前，会请不同角色的人员，一起参与测试，比如学生、老师、医生等等。然后团队中负责测试采集的人员，也会收取多轮意见，然后作为修改意见交给整个软件团队去修改。同时，一些商业应用的程序，会涉及服务器的高并发、使用的多平台、使用的便捷性，技术和平台的复杂性也会需要更多的测试时间
  • 学生团队的测试，更多是面向课程展示的核心功能，确保核心功能不出现问题同时也保证答辩的可展示性，而无需过多的考虑用户多平台等商业特性。而且测试人员构成上，也大多数是团队中的有限几个开发人员，得到的测试意见也相对较少。这两点导致花费在测试上的时间相对较少。

• 最理想的PSP时长分配是什么？是工程师所花时间范式吗？

我认为，不同软件工程师的阶段、不同软件的需求、面向不同应用的项目，PSP时间的分配，会是不同的。所以没有最理想的PSP时长分配。

但是对于软件工程的学生来说，应该在大型项目开发之前，多向工程师团队讨论确定最合适且不需要重做的软件架构和技术方法。同时，在完成一些实际功能之后，也可以和公司联手进行软件测试，来在项目的展示性和实用性直接取得优质的平衡。

• 从大学生编程向工程师转变成长的过程中经历了什么？

技术和开发经验的积累、成年人的压力、以及脱落的头发吧...

• 当面对一个具体的项目时，我们对项目进度有什么预测和时间分配？

这个可能也取决于具体的项目。比如我们面对的冯如杯参赛项目，DDL已经确定，那么我们需要根据总时长确定项目的工作量、特色和创新点。然后根据工作量、特色和创新点，进行正推确定各时间节点（milestone）。之后每一步都需要根据时间节点来进行，未按时完成的内容需要反思和补救或者放弃。

2. 结对编程的问题

问题二：书本4.5.2. 为什么要结对编程 P85，课程在第3周有结对编程项目，我有一些课程上的和结对编程方法的疑惑。

• 结对编程会是一项提升大多数项目质量的软件工程技巧吗？
  • 结对编程在实际开发中并不常用，虽然在某些方面有奇用，比如Google的Jeff Dean & Sanjay Ghemawat，但似乎也只存在于某些默契度非常高的两位水平相同互补性程序员身上

是的，结对编程可以聚集融合两个人对于同一个项目的不同的认识，更容易提出创新性的方案。而且在两个人的讨论中，也可以淘汰一些过于不切实际的想法，使得整个开发过程不容易走弯路。而且我们在团队编程的过程中，也应用了结对审核的前端代码测试方法，保证了前端代码的正确性。

但由于开发成本、代码规范不同等多种原因，我在观察各种工程师团队的开发过程中，没有看到结对编程的身影。不过我认为在老员工带领新员工开发的过程中，是非常适合结对编程的。

• 两人之间的契合度，实践过程中对代码风格实现习惯的纷争，反复审核带来的开销，相比起双人的分模块确定接口开发，是否能提高质量和效率？

在实践中我意识到，两人的契合度、代码风格习惯不同、反复审核的开销，无论在结对编程中还是分模块开发中，都是一个需要解决的问题。也就是，结对编程和分模块编程，都会面临同样的问题。

而从质量和效率方面来说，结对编程能够保证以写代码的高质量，但是开发效率可能不及双工模式的分模块开发。但是对于较长期的较大规模开发来说，由于两人或者多人初期在编程代码和方法相对独立，随着代码规模的增长，代码上需要更多的相互调用和相互关联。分模块开发在后期可能需要很多时间去进行调用上的交流和磨合。而结对编程由于代码是两个人一起写的，在后期更多关联和调用出现时，也无需回溯到之前写的代码上再去磨合。

• 两位队友之间的磨合、督促的压力似乎对长期编程合作更有优势，我们课程为什么要用一个一周的项目来实践，能否得到一定的效果？

目前，我认为，结对编程的优势，更容易在较长期的较大规模开发中体现。课程采用一两周的项目来实践，可能更想让我们去体验结对编程，从中掌握一些结对编程协作的工具和方法。

而从工具掌握和协作软件的使用上看，取得了一定的效果。

3. 团队协作的问题

• 问题三：书本6.1. 敏捷流程介绍 P116，课程要求实现冲刺，连续10天每日例会记录，对此有一定困惑。
• 公司开发每日例会的间隔，一天一次是不是太频繁了？尤其是面对复杂的bug探测和研发问题时。
• 结合我自己实际科研项目经历，可不可以一周一次例会和一次项目进度督查，把更多时间留给个体探索和深入挖掘？
• 虽然科研和工程实现的工作性质相差很大，但一天一次的工作会是不是在团队交流上花费太多时间了？

以我现在的实践的经验来集中回答一下上述几个问题。

• 工程和科研是有显著区别的。可能我们都知道，工程可以尽情使用已有的工具和方法，而不强调创新。但科研是一定需要创新的，才能叫科研。
• 举个例子。工程上，我们发现一个可用的轮子，我们花几十分钟看了他的规格说明书，自己尝试在工程上进行调用。而在科研上，我们发现一个和我们目标差不多的文章，需要去看他的来龙去脉，需要做相关复现来熟悉其底层方法。而且在复现的过程中最好能发现一些我们可以突破的点，来作为我们科研的一个切入点。
• 所以，我们可以认为，工程上，在实际开发过程中，完成一个feature的时间基本上是以小时或者半天为单位的。但是科研上，做复现、提出并完成自己的问题的设计、实施之后评估，都是以周甚至月为单位的。因此，软工例会，以天为单位进行是完全没有问题的。甚至我们在实际开发中，一天要进行几次会议，比如相似功能成员小范围的互审和每日工作完成报告和后续计划，基本上是一天两次会议了。而科研团队，每周交流工作和方案，也是和科研工作的工作量和时长相吻合的。

4.敏捷开发的适用范围

• 问题四：书本6.5. 敏捷的问答 P128，敏捷的适用范围，如下表。
• 敏捷、计划、形式化这三种开发方法的适用范围？是不是可以理解为敏捷开发适用于现在迭代速度快的多数互联网公司开发，计划驱动适用于较大型项目交付型开发，形式化的开发方法适用于大型军用或者安全要求性高的民用开发？
• 为什么我们课程要着重强调敏捷开发这种方法？而不是后两种？

我在和同学的讨论中意识到，我当时写的：“敏捷开发适用于现在迭代速度快的多数互联网公司开发，计划驱动适用于较大型项目交付型开发，形式化的开发方法适用于大型军用或者安全性可靠性要求高的民用开发”这句话是没有问题的。

那我们的课程为什么强调敏捷开发呢？ 我认为，在这三种开发方法里面，敏捷开发是门槛最低，要求成员较少，可以在一个学期内出成果的开发方法。而且，通过敏捷开发的学习，我们也可以学到软件开发的方法论和相关开发技术。而与敏捷开发相比，计划驱动需要一个整体的计划，然后5-7人的团队可能在短期内只能完成一个小的模块，这样不适合总体效果的展示，同时在选题和计划过程中也有比较大的难度。形式化开发，其实也是课程可以选用的一种教学方案，可以和敏捷开发并行教学。我个人认为，形式化开发，对开发核心模块的可靠性、测试重复性、算法优化都有着比较高的要求，似乎和敏捷开发构成了软件开发的两个方向。都可以作为计算机专业的课程内容来学习。

5. 需求分析的问题

• 问题五：第8章 需求分析 P157，我结合自己实际科创科研创新对于软件工程的需求分析有一些问题。
• 相比创新创业式的需求分析，软工方法的各种基于已有数据的分析方法（比如调查问卷、EyeTracking），具有多大的现实意义？是不是书本中的几个方法只针对软件开发中的产品迭代更新时的需求分析改善，而不在于产品创新？
  • 需求分析，我在做科创项目的时候，最常被问到的一个问题就是，你的项目解决了什么痛点满足了什么需求，而且能开发出一款独特的、满足或者创造公众新需求的产品的公司，从产品研发来看已经成功，比如微信或者拼多多，或者阅读链接中的 对于三线城市的实践需求分析方法。

我在和项目老师的讨论中学习到。工程中的大多数创新，是经历了需求分析阶段后提出的。但创新也分很多个层面，比如拼多多软件可以认为是一种购物模式的创新，而基于调查问卷或是EyeTracking的创新，也确实更多是用户体验改进的创新。

无论是模式创新，还是用户体验创新，还是核心功能更新，都是软件工程开发中需要通过需求分析来分析清楚，然后完成实际创新点落地的。所以这些需求分析也都是有意义的。

• 公司的创新性功能是不是大多数由PM在原始想法中提出？

公司的创新性功能，谁都能提。PM可能只是一个项目管理的角色。但一种常见的思路可能是，一位员工，有了一个创新性想法，他在想法变现的过程中，联系到了很多的技术、测试人员，一同进行开发。在这个过程中，他也担任了PM的项目管理、计划、决策的角色。所以现在看到的一种情况是，很多项目的PM就是创新性功能的提出者。

• 假设软件工程的需求分析大多由PM提出，那么全方面的NABCD似乎在很多大的公司中是多个部分合作完成的，在软件工程开发里面讨论，是意味着软工开发需求分析人员也很需要和公司其他部门建立深入联系或者内嵌入其他部门吗？

是的，我认为不仅是需求分析的人员。技术人员也要根据用户具体需求判断功能开发的优先级，测试人员也需要寻找这个软件的核心用户，了解他们对软件的核心诉求和使用习惯，来更好的完成软件测试。

6.多快好省的问题

• 问题六：在书本9.3. PM做开发和测试之外的所有事情 P195
  • 之前听说艺术行业的一句话“多快好省本身就是个悖论，多了没法快，好了没法省”，所以软件行业中，可能满足在多快好省中三选二吗？有具体的案例吗？而优秀PM在其中的作用和对PM的要求又是什么？

我认为是可以满足的，VS Code应用开源平台就做到了又好又快。

我在自己课外项目中担任PM，认为优秀PM的主要作用和要求是：

1. 对核心需求和创新点的准确把握
2. 对项目最优使用技术的准确把握
3. 对项目管理方案和时间规划的丰富经验
4. 对团队人员的了解和充分的调配

上述这些，也不一定要PM一个人都做好，可以依靠团队成员来协助完成，但PM需要意识到上述要求某一点的失误，都可能造成整个团队最终开发效果的不佳。

7.测试与bug的问题

• 问题七：在书本11.5.5. 小强地狱 P250
  • 小强地狱的方法是否在可行性上，对于不同层次的程序员值得分开讨论？
  • 对于编程能力强的程序员团队，小强地狱是一项有效的平衡项目推进和bug消除的方式，但对于编程能力太弱的程序员团队，似乎很难在bug阈值设定、团队稳定开发和避免小bug导致“大怪物”之间权衡，很容易出现bug阈值设置太低导致程序员只能去debug，而影响稳定开发，设置过高之后，导致测试人员无法正常工作，甚至出现“大怪兽”，是不是这套软件工程方法或者说很多的工程方法的适用范围在编程能力相对较高的程序员上，而对于能力较弱的程序员反而累赘？

我的结对编程和团队编程过程中，还没有经历类似的bug地狱的开发流程。所以对于这个问题，我现在还没有新的有见解的意见。

但是我们团队编程中的代码互审技术，可以减少bug合并入主分支，而导致灾难性的后果。我认为代码互审和合并也是一种很好的测试和消除bug的技术。

新的问题

软件工程课程，我收获了很多。对于课程本身，我没有太多问题，但是有一个课外工程实践遇到的问题。这个问题也和软件工程息息相关，我也记录如下。

我们学校的软件工程团队，相较公司中的工程团队，我们的优势到底是什么？我们知道，学生团队的工程开发经验相比起工程团队，有很多不足。但是我们学生的创新性、创造力有时能够和工程团队相当。

在这种优势的基础上，我们是更应该做工程项目还是科研项目？假如我们还要做工程项目，我们适合做什么样的工程项目？

做中学到的知识点

• 需求：对实际有产品需求的人进行调研，同时对相似竞品进行多方位的、基于自己实践的考察
• 设计：把总体功能设计，分为核心功能设计和拓展功能设计，分优先级来完成。同时前后端统一的技术文档可以统一代码命名、开发进程等问题，非常重要。
• 实现：采用GitHub提供的项目管理平台，采用issue-pull request的方法来完成任务的分发和合并。而且工程开发中，可以尽情的用轮子~
• 测试：采用代码互审，才能合并到dev主分支的模式
• 发布：将实现、测试、发布分离为三个分支，我们团队中，采用的是production、dev、个人分支的并行运转的方案，能够在个人分支和dev分支中消除大部分已有bug。且production分支保证发布的功能正常运转。
• 维护：在维护过程中，会出现一些运行过程中的bug，我们采用热更新的方案，对这些bug进行消除。

团队项目经历中的心得

这学期的软件开发，我作为团队中的开发人员。学习了Vue.js的组件化开发方法，实践了基于GitHub的管理方案，同时也亲身经历了软件从无到有的整个过程。我在具体开发知识和管理方法中，都收获了很多。在团队开发中，我们团队有时候凌晨还在开组会，我也被队友认真负责的态度打动，也从他们的想法、代码中学到了很多很多。

总之，团队项目开发经验，对我来说，是一笔宝贵的经历。这也对我日后的软件开发，有着积极的借鉴作用。我也会在现在的大创团队的项目中积极采用软工课上面学习的方法，以期开发出更优质、能为更多人使用的程序。