北航 2022 软工个人阅读作业——提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2022北航敏捷软件工程 |
| 这个作业的要求在哪里 | 个人阅读作业-提问回顾与个人总结 |
| 我在这个课程的目标是 | 回顾学期初的问题，总结个人收获 |
| 这个作业在哪个具体方面帮助我实现目标 | 理论分析与总结 |
问题回答
第一次作业博客链接
问题与回答
“技能”比“解决问题”更重要吗？
问题：作者在文中提出说“通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。”对于这一点我还是非常认同，但是对于作者在文中推崇先解决“低层次问题”，我仍然有一点相反的意见：在我看来，在一些情况下这种“解决低层次的问题”未必比学习“解决问题的方式”更重要，在技术发展日新月异的今天尤为如此。举一个简单的例子：例如学习网页开发，在十五年前某个人学习网页开发时，可能会花很大精力在 Flash 上，因为 Flash 在当时能做出令人惊艳的动画效果，并且在许多网站中都大量运用了 Flash。但是在 2022 年的今天，我们却很难再见到 Flash 技术的应用了，因为这项技术已经被扫入历史的垃圾堆了（当然，Flash 在当时本身是一项不错的技术）。同理类似有微软开发的 Fox Pro，在今天也被遗弃了。那么学习熟练解决这种“低层次的”的技能真的还要那么大的价值吗？再如从前一个人能熟练地背诵库中的各种 API，但是在当下这个 IDE 技术迅速发展的今天真的有用吗？对此，我认为在目前这个技术迭代飞速的时代，尤其是在互联网这个领域，“技能”或许本身的重要性没有以前来的大了，反而“解决问题”本身更能适应当前时代的发展。
经过实践，我稍微改变了原来的观点。一个重要的例子就是我在本学期的项目开发中学习了 Django 的使用，而在此之前我只学习过 Rails，但是熟练掌握了 Rails 的使用后，我发现我也能够迅速学习 Django 的使用。由此可见所谓“技能”与“解决问题”不一定有着谁更重要的问题。“熟练的技能”有时也是非常有用的。
对于技术而言，“精通”比“全栈”更重要吗？
作者在文中用“单人乐队”与“乐手”举例，想说明我们应当精通某一样技术，而不是做一个泛泛的“全栈工程师”。然而实际上仅仅精通某一项单独的技能已经不足以满足现实的需求了。尽管现代软件工程利用“封装”等思想大大简化了开发的难度，但是在开发的过程中，人们仍然会不时地遇到一些只了解单个领域就无法解决的问题，此时往往需要一名了解多个领域的“全栈工程师”的帮助。事实上，现在越来越多的领域正在成为交叉的领域，这一点在人工智能技术飞速发展的今天显得尤为明显。除了在研究人工智能理论的一小部分人外，大多数人聚焦在如何使用人工智能技术为现有的领域提供更好的支持，这使得人工智能成为了一个非常广阔的一个交叉领域，许多大学中也开办了许多面向这种交叉学科的专业，例如“智能制造”等。一名工程师往往需要将某样技术应用到现实生活中来，这样的技术可能是某一样非精通的“技能”，也可能是某一样精通的“专业”。优秀的工程师需要同时具备技术的深度与技术的广度。
经过本学期的实践，我认为“全栈”在现在的开发中也十分重要。在我们的项目开发中，一些“全栈”的知识大大提高了我们开发的进度，尤其是加快了我们团队 bug 修复的进度。
结对编程是否对结对者的水平差异提出了更高要求？
在书中作者介绍了许多结对编程的好处，例如减少 bug、提高工作效率、提高解决问题的能力等。同时作者推荐结对编程时不需要过于注意两个人水平上的差距，认为双方具有同等的决策权力。但是在各种编程概念（例如 Go 语言中的协程、Rust 语言中的 Linear Type）和编程范式（例如函数式编程）的今天，两个人水平上的差距是否愈发是结对编程中不可忽视的重要影响因素之一呢？尤其是在函数式编程中（例如 Haskell 或者 Scala 等语言），往往会用比较抽象的组合子对问题进行建模，而这一点是非常依赖于编程者的函数式水平的。如果两个人水平上差距过大，很有可能会经常出现一个人不断询问另一个人某段代码的含义。诚然，在某种意义上这可以帮助开发者尽早发现自己代码中的 bug，但是我认为这对于开发进度的拖慢是不可忍受的。
在我们的结对编程实践中，我发现结对编程时如果二人的开发水平有较大差距，确实会拖慢一定的开发进度。但是反过来，这一定程度上也可以让另一个人更清楚地解释自己的开发思路，考虑到后续的 bug 修复的成本，这未必会和我之前想的那样大。因此我认为在一定程度内的水平差距仍然是可以接受的。
软件开发中的重大决策应该由“猪”来定夺吗？
问题：作者在这篇文章中将项目人员按照投入程度分为了猪、鸡、鹦鹉三种，并提出“应该让研发和市场第一线全心投入的‘猪’来定夺重大决策”。但是在实际的生产当中，猪未必适合这个位置。例如在某个开发团队中，“开发人员”是团队中“猪”的角色，他们为团队编写关键代码，并且全力投入。那么在这个团队中应当由“猪”来引导产品发展方向吗？实际上，在一个团队的分工中，其他角色也占用很重要的位置，例如市场调研的人员往往可以比开发人员先一步了解市场变化的动向，因此他们也往往能够更清楚地把握市场风向。尽管他们在投入上可能并不如开发人员，但是由他们进行决策可能更加科学。另一方面，需求调查和团队管理一样都是十分专业的任务，需要交给专业的人来完成。尽管某个开发人员非常投入，但是他未必能够胜任这样的角色；反之，尽管某个成员在团队中承担着“鸡”的角色，但是他做专业的事也未必不如外行的“猪”。因此我认为这里仅仅按照这个方面划分团队人员有点粗暴了。
通过本学期的实践，我发现在真正的项目开发中，往往是我们的所有成员共同决定项目的开发方向，由每个人提出自己的意见，从而影响项目的开发。当然，这或许也是因为项目中的每个成员都是“猪”，因此大家都能为项目提出合理的建议。
软件开发时应当由 PM 负责分解需求吗？
问题：在谈到分解需求时，作者提出 PM 应当是“责无旁贷的领导者”。然而，在实际开发中，开发者可能会遇到各种技术层面上的困难，而这一点 PM 有可能是无法预料到的。因此如果简单地让 PM 成为项目需求的分解者，那么在项目管理和项目时间安排上极有可能出现估计错误的情况。因此，我认为除非 PM 是一位有着丰富经验的开发人员，而且对于开发的项目有着足够的了解，那么这样的 PM 有义务领导团队进行任务规划。否则在分解任务时应该让主力的开发人员与 PM 进行协商；否则，PM 的错误估计可能会导致项目的开发工作无法继续进行。
通过实践我发现，在软件（尤其是敏捷软件过程）的开发过程中，不仅仅可以由 PM 来决定项目的需求。在开发的 SCRUM MEETING 上，PM 提出需求后可以与开发者进行沟通交流，取消不切实际的需求，或者修改现在需求的呈现方式，从而实现技术层面的可行性。当然，项目的整体规划仍然是由 PM 进行的，因为开发者虽然清楚技术细节，但是未必了解市场、用户等方面。
设计用户体验时，如何把握用户的需求而不造成体验的割裂？
问题：作者在这里描述了必应搜索的“实时显示英语解释”，并指出在实际应用时，英文解释无需显示“a”“on”等简单词汇。但是应该如何掌控这个设计的尺度呢？不同的人的英文水平可能是大不相同的，例如一个上网查找英文资料的小学生与一个托福 110 的大学生，二人对于英文单词的学习进度也是不同的，如果软件自作主张地取消一些词的显示，可能会造成体验上的割裂感。那么在实际设计时，考虑到这一点该如何准确把握用户的需求呢？
经过了一学期的实践，我发现在开发软件的初始阶段，需要通过用户调研、利用 NABCD 法分析需求等方式确定软件面向的用户，然后根据调研的结果做用户体验上的决定。此外，当权衡需求的过程中发现无法满足所有人的需要，可以通过一些其他手段引导用户自己选择需要的方案，例如提供一个按钮等。
知识总结
- 需求：
- 在需求分析阶段，我主要学习了通过 NABCD 法对软件需求进行建模。NABCD 综合考虑了用户需求、市场竞争等多方面的情况，可以充分为软件的开发进行铺路，同时还起到了一定的功能设计作用，防止后期软件因为需求不明确而造成开发失败的情况。
- 除此以外，通过此阶段我还进行了真实的用户调研，通过实践学习了需求调研的方式。
- 设计：在本阶段，通过作业要求的《功能规格说明书》和《技术规格说明书》，我了解了软件架构设计的基本方法，包括前后端交互时的错误类型设计、网络安全方面的设计等。此阶段不仅需要考虑项目的功能，也有设计实现项目功能的技术手段。
- 实现：在实现阶段，我的收获分为以下两个方面
- 团队协作：通过本项目我学习到了很多 git 操作方面的知识以及合理利用 GitHub 的方法，能够更加熟练地使用 pull request、issue 等功能以及 git rebase、git stash 等命令。同时，我还学到了在团队协作中如何合理利用这些功能进行团队开发上的管理，这让我对于团队开发工作流有了更好的了解。
- 技术学习：在项目开发之前，我没有过接触过大型项目的管理运维操作，包括数据库使用等知识也不充足。经过此次开发，我对于大型项目的维护有了更加深入的了解。此外，通过这门课的开发，我还学习到了 Django 框架的用法以及 PostgreSQL 等工具的用法。
- 测试：通过本项目，我学习了通过单元测试加强项目鲁棒性，并充分理解了单元测试的重要性，并且开始习惯在编写项目的同时写单元测试。在项目的开发过程中，单元测试是保证项目正确性的重要手段。此外，单元测试还能起到回归测试的作用，也为我们的项目发现的很多 bug。
- 发布：此阶段需要讲本地的项目部署到云端的服务器上，中间包括了配置服务、数据库、用户等方面。同时，发布后需要需要推广才能吸引到足够的用户。
- 维护：维护阶段的主要任务包括项目运行情况的实时监测，防止工程因为意外情况而宕机。在本项目的开发过程中，我经历了一些需要实时修复线上 bug 的情况，这让我对于项目的维护有了更深入的了解。
心得体会
《软件工程》这门课让我第一次真正参与到了中大型项目的合作开发中，也第一次真正让我认识到了团队开发与个人独立开发的不同。此外，通过这次的开发，我也学习了 Django 框架和 PostgreSQL 的用法，让我掌握了新的开发工具。在团队开发中，比起开发水平而言，更重要的是多人的合作。尽管我们在开发之前就制定了严格的多人协作规范，但是在开发的过程中仍然因为一些不可抗的因素而没有能够完全遵守。例如说考虑的时间的短暂，没有能够实现让大家都合理使用 git rebase 进行开发，以及运维的过程中出现了一些操作失误等。但是敏捷开发的过程总是会充满意外的，而只有灵活地调整现有的才是敏捷开发过程中最重要的能力。
通过了这次的开发经历，也让我认识到了测试的重要性。在项目开发的过程中，我们出现了一次大范围的模型修改和 API 修改。所幸的是，我们在开发时就严格遵守“对自己代码负责”的要求，为几乎每一行业务代码都编写了相应的单元测试，而这些测试也使得我们能够在回归测试中发现了大量 bug，大大提升了修 bug 的效率。
唯一希望这门课改变的地方就是希望能够减轻结对作业的任务量，让题目更清晰一些，降低同学们理解的难度，让大家有更多的时间去完成后面的作业。
