| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 掌握并实践利用软件工程方法构建大规模高质量应用的技术，提升自身工程能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 对学期出提出的疑问进行解答，并回顾软工一学期的收获 |
Part 1 提问回顾
原有问题解答与分析
Q1: 敏捷开发在大型项目中的应用
学期初，我认为“交流”会导致敏捷开发在大项目中无法进行，即使采用切分，也很难处理相关问题。但是，现在我认识到这一想法有问题，原因如下。
- 敏捷的核心思想是交流，但敏捷开发的交流是有规划的，是集中有组织的，这种有规划的交流可以在异地合作的情况下进行。而如果按照我一开始设想的随时可以交流的模式，反而会导致开发人员时不时的转移注意力，无法集中开发。
- 采用切分，可以很好的解决复杂系统的问题，这包括小模块之间有着大量相互重叠的部分的情况。在设计阶段，就应当邀请每个重叠部分的相关模块人交流，确定模块边界和行为。一个好的模块应当是无副作用的，这样就可以将模块间的依赖关系从(N^2)数量级降低至(N)，属于可以处理的范畴。
Q2: 关于goto语句的使用
这里我仍然坚持学期初的观点，即：
- 只有在需要错误处理而语言本身没有提供错误处理功能的情况下使用goto语句
同时多加入两点前提：
-
优先考虑更换开发语言
-
同时应当在项目的README，相关函数的开头加以说明，且确保成员们受到过相关的培训
团队的一切规范都是服务于开发效率的，但是规范对于开发效率和可维护性确实有很大影响，一种不常见的规范本来就是对开发人员的一种心智负担，因此如果没有特殊需要，不要使用这样的构造。
关于开发语言，相信不少人会对此抱有疑问，但是语言本身确实有其专长，如果进行Web开发，那么去使用没有错误处理的C显然是不明智的。事实上，语言本身是根据需要构建的，如果你发现一门语言没有你需要的功能以至于你需要绕很多弯去实现，很可能你的使用方式是错误的，或者这门语言不适合解决你现在遇到的问题。不得不提一提我们项目的React（x
Q3: 关于类的使用
好嘛我这把软工上成编程语言学了
我认为这是开发语言之间的差异。对于多范式语言，混用范式也不是一种明智之举。大胆推测作者还是将C++用作面向过程的工具，而使用面向对象的特性作为辅助。只要能够在开发团队内部统一，自然会更加合适。
不同语言范式没有高下，也没有表达能力上的本质差别，只有在不同问题上表达繁琐度上的差别。因此在遇到一个问题时，会自然选择合适的范式进行编程，如果整体工程中大部分内容使用面向过程的范式更合适，小部分内容才适合抽象成类，此时就会出现作者提出的情况。
Q4: 关于多人合作中的代码同步问题
这一点是我一开始的理解存在一定问题，规范的流程指严格规范向主分支的合并，如果不做这一点问题主分支上会产生无法通过构建的代码。而我接触的项目完全都是保证向主分支的合并修改具有原子性的。同时我个人强烈赞成此种做法，主分支上本就不应存在无法通过构建的Commit。
当然，这就属于严格流程控制的例子，会导致有人一直无法签入，这需要主管Merge的人手动控制，也可以通过VCS的相关功能（如Merge结果自动测试）来保证合并进度。针对书中果冻的邮件，就可以通过自动化测试来解决，同时手动提高他的合并优先级。
此外真实开发后发现，只要模块划分合理，不要有两个人同时工作在同一个文件上，每次先pull，就能有效避免冲突，使冲突只发生在部分容易解决的全局配置文件上。
最后，原文例子里可能是大家不会用git花的时间才那么多（
Q5: Beta期间，修复Bug的门槛要逐渐提高
我认为，这是作者针对传统C/S模式或其他软件的说法。客户端类软件发布困难，一次发布后不易更新，在改动策略上确实需要Freeze和稳定，但是现在常见使用敏捷开发的Web服务，则易于改动和发布，完全可以不断更新。
新的问题
-
初学者在技术不熟练的情况下应该被分配何种任务？对初学者来说即使简单的任务也会出现编码问题和安全漏洞，同样需要大量时间进行复审。
-
敏捷开发是应对变动的模式，那么作为我们课程，敏捷体现在何处？Alpha与Beta之间的一次评审和意见收集，和两次Waterfall有什么区别么？
Part2 实践中学到的知识点
需求
- 在实践中使用NABCD分析判断一个项目的可行性。
- 需求分析需要我们打开脑洞，读取客户在表面需求下的真实目的。NABCD对于评审某个需求，判断重要性方面尤其方便。
- 需求分析时，结合团队规模好好考虑功能的可行性。
设计
- 有笑话宣称，Agile就是Waterfall in sprint，从我个人开发的感受，事实也确实如此，设计阶段的问题，会导致后续大量时间弥补。
- 设计对每个小功能一定要拉上所有有关方决定，以免出现双方理解上的误差，很遗憾，这个技巧我们很晚才发现。
实现
- 一定要编写可维护的代码，可以修改的代码，来应对随时可能发生的变动。
- 实现阶段不能随意修改设计。
- 设计的修改为实现带来了大量困难，甚至导致发生矛盾。
- 实现阶段一定要保持沟通，随时同步进度，一定要首先完成模块的交界处。
- 否则会出现整体阻塞的情况。
测试
- 功能正确性只是基础，性能，更重要的UX/UE也是测试的重点。
- 单元测试不足以发现大部分的问题，需要集成测试，场景测试加以辅助。
发布及时止损，时间不够时不要犹豫，砍掉功能。
- 宣传非常重要，极大影响产品观感。
维护
- 及时收取反馈，快速修复Bug，是课程中敏捷体现最为突出的一点。
Part3 个人总结
软件工程课大致分为三个部分——个人阅读作业、结对编程和最后的敏捷开发。
个人阅读作业阶段，我印象最深的是案例分析作业，让我们第一次以产品分析的角度去看待一个软件。当时太过天真，以为仅仅体验一下产品开发的视角就是结束，想不到后来的团队作业还要和他纠缠不清。
结对编程部分，体验了结对编程这一新型工作方式。结对编程可以有效地在编码阶段发现一些问题，再配合课程组给的这个容易出现理解错误的题目（巧了.jpg），正好能发现问题。但是，大量的时间被花费在了讨论上。这也让我在软工这门课中发现的自己问题：我的思维偏向线性，如果遇到一个问题暂时无法解决，我很难将他放在一边，即使我知道可以进行一些其他任务。包括编写程序时，如果发现一个地方的潜在问题，会希望得到妥善解决后再开始，而不是立即交付自己知道有缺陷的程序。此外，我还收获了不少编写单元测试的技巧。总体来说，我其实感觉就像只做了一次OO作业。
敏捷开发部分，团队项目是本课程重点。我负责项目中解析数据集的部分和整体项目的CI/CD部分。在团队项目中，我实践了许多前沿的持续集成技术，这部分工作完成较好。然而在数据集解析引擎部分中，我上面说到的自己的问题在Alpha阶段对我们团队造成了比较不好的影响，影响了整体的进度。所幸在Beta阶段中，在队友的帮助下我及时发现了这个问题，并且最终在Beta阶段有所改善，没有再次影响进度。不论如何，这是我第一次参加的从零开始的大规模软件开发过程，开发过程中暴露的种种问题都是非常好的经验，非常值得从中学习。最后，还是要感谢谜语人队全体同学的辛勤付出。
Part 4 一些胡思乱想
以下可能存在黑泥请选择性观看（x
总体而言，软工体验下来，大部分时间被花在了产品分析等产品层面的问题上。我至今仍然坚持在和昂神对话中的观点：软件工程课不该过分强调产品。
软件工程是手段，目的是获得最终的产品，可这和我996打工仔又有什么关系.jpg，软件创造了多少价值又给不到我头上，老板让写啥我写啥，我为啥要管客户需要啥。- 当然，这是气话，正经说原因，我认为一款不管是软件还是其他产品，必定是由专业的人去合作负责的。软件需要有什么功能，这是市场调研部门、产品经理和设计师需要关注的；软件怎样提供这些功能才更合适，这是UX/UE需要关注的部分；软件最后怎么发行，那是整个销售部门的思考。作为软件工程师，计算机科学家，我们的任务是用程序对需求进行建模，在合适的成本下实现需要的功能。而我们的课上，我们横跨市场分析，UX/UE，程序设计，销售发行，这显然是不合适的（这是软件工程课程又不是大学生创新创业大赛）。
- 作为软件工程师，我们当然需要理解需求的能力，但是我认为，我们的重点应当放在理解上，而去发掘用户需求和软件创新点的功能，需要专门的产品设计背景的人进行。
- 总结以下：软件是由软件团队生产的，软件团队中除了软件工程师外还要有产品经理、销售、设计师、UX/UE等其他人员。我们的课程要一个产品，这就不仅要求我们做软件工程师的任务，还要求我们完成其他人员的任务。这些任务需要额外的专业知识，对大部分人来说不会全部用到。因此我认为这些额外的负担是不合理的。
此外还有一个最重要的原因，这是一门两学分的课，（而且由三位老师上课，三个班之间差异巨大显然不妥）
然后再说一个稍微偏一点的问题上自己的瞎想，即软件工程中题目的问题。我个人比较希望能不采用Web开发作为题目，而是尝试去写一些命令行工具（Git啊什么的）或者传统的大型软件，原因大概如下：
- 三年来系统上过的语言课只有C和Java，尽管不排除大佬们自学的可能性，但是对我们绝大部分人来说Web开发都是第一次接触。
- 而许多Web开发中使用的框架都是用近年来的新语言来使用的。近年来的新语言和框架们最大的特点就是，他们会在某个领域抽象出一套独特的模型并使用。而如果你无法将你要写的任务抽象成这种模型（而这需要对语言或框架的熟悉和使用），就会产生臃肿低效的代码和各种各样的问题（
没错我们就着了react的道）。 - 只有在熟练掌握和理解的编程语言上，才能写出最优雅合适的代码。尽管用不熟悉的语言有可能能更好的体验软件工程纠正少部分人错误的能力，但一个人在不熟悉的语言上，无论使用什么技术，都难以获得良好的代码，这是软件工程也难以解决的。而学习与成长需要时间，但软件工程并不能给予这么充分的时间。
- 因此，个人认为采用Web开发作为题目（或者使用不熟悉的语言进行开发），会导致我们会把时间花在语言的细节上，进而影响到软件工程中重要的部分：大规模项目下合作能力的训练上。
当然，这是我的一家之言，具体情况还是要分析，比如现在到处都在招Web前后端软件也只有Web前后端啥的。
（20210629更新）对了再补一句，做中学要想办法让我们做的东西是对的，如果能让我们进入一个成系统的团队而不是自己瞎摸索我感觉可能会更好。
Part 5 结语
不管怎么说，软件工程课程是我第一次接触大规模开发。这样的体验是难得的。尽管中途经历了许多波折，最后的成果也算的上满意。在这里我需要感谢结对编程的乔佬，谜语人队的各位，以及各位助教老师们的辛苦工作。
敏捷软工就如同基物实验，看似工作量大收获少，实则能在一个领域收获足以未来数十年获益的思想和方法。希望将来能有更多的同学，体验 快 速迭代的敏捷开发方法，走 入软件工程的殿堂，并从中收获自己的感悟。