软工个人作业 4 - 提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	熟悉并在实践中体会软件开发流程，学习软件构建思维，提升编码能力
这个作业在哪个具体方面帮助我实现目标	总结反思了实践过程中体会到的软件开发团队协作过程

回顾

🔗 以前提问题的博客链接：软工个人作业 1 - 阅读与提问_HJin_Gwok的博客

问题解答

Q1：Build to Win 是种种技术突破最好的试金石吗？

根据我自己的项目实习经历，构建以赢得用户为出发点的产品和衍生技术线的确可能触发有价值的研究（尤其是当下大热的计算产品线）。这种以用户或者说业务方为中心的开发方法通常会关注业务需求和用户体验，致力于提供有吸引力、易用且有价值的解决方案，而很多时候，亟待解决的业务需求恰恰与相关领域的技术难点相吻合。通过深入了解用户需求并根据其反馈进行迭代改进 —— 这种方法无疑可以帮助开发者构建出更加符合市场需求的产品，实际上，我们的团队实践也印证了这一点，来自用户的需求让我们注意到了许多设计上。

而且，在商业环境中，产品的商业可行性和盈利能力通常也是重要考虑因素。时代风口可能会推动某些技术或产品在市场上获得更多关注和机会，因此，在产品和技术研究中考虑市场趋势和商业机会也是合理的。

要实现有价值的研究，需要在用户需求和商业考量之间取得平衡。关注用户需求和体验是构建有竞争力产品的基础，而商业模式和市场趋势则为产品提供了增长和成功的机会。在设计产品和进行研究时，开发者应该将用户为中心的方法与商业目标结合起来，以便在满足用户需求的同时创造商业价值。

Q2：单元测试“不自动”的限制在哪里？

个人的体会还是：代码的执行与具体的应用场景结合过于紧密，导致对“正确性”的判定无法像判定算术指令那样完全自动化执行。例如，不论是在结对编程还是在团队实践中，我们都没能真正地完成“前端单元测试”，以它为例子分析，“不自动”的技术限制可能包括：

1. 用户界面交互：前端代码通常与用户界面进行交互，包括处理用户输入、响应用户操作等。这种交互性可能导致难以自动化模拟用户行为和测试用户界面的各种情况。
2. 外部依赖：前端代码通常依赖于许多外部资源和服务，如后端 API、数据库、第三方库等。这些外部依赖可能无法直接模拟或替代，从而导致在自动化测试过程中出现困难。
3. 异步操作：前端代码经常涉及异步操作，如处理定时器。这些异步操作可能会导致测试时序的复杂性，使得自动化测试变得困难。
4. UI 变化：前端界面的设计和布局通常较为灵活，可能经常发生变化。这种变化可能会导致测试用例失效，需要及时更新和维护测试代码。

只不过，尽管存在这些技术限制，前端单元测试仍然可以通过一些方法和工具来实现自动化测试。例如，可以使用专门的测试框架（如 Jest、Mocha、Karma 等）和模拟工具（如 Sinon、Mockito.js 等）来模拟浏览器环境、处理异步操作和替代外部依赖。此外，可以采用UI自动化测试工具（如Selenium、Cypress等）来模拟用户界面的交互。但是，依旧需要在编写测试代码和设置测试环境时仔细考虑这些技术限制，以确保测试的可靠性和可维护性。所以，与应用场景高度相关的软件产品本质上还是无法完全实现像代码静态分析那样的自动化单元测试。

Q3：不在变量名中补充尽量多的信息是合适的吗？

不合适。作为经常需要修改他人代码的美工，我体会到：在需要修改和 Review 他人代码的时候，信息丰富的变量名可以大大提高代码的可读性与可维护性，尤其是在充满各种开关逻辑的前端页面，在变量名中明确诸如 toggle 这类指示灯变量的职能不仅能够理清交互逻辑，也能方便他人查找维护，样式的 class 、id 等属性也存在此类需求。

Q4：个人软件开发流程记录的意义

在团队实践中，Notion 文档实际上充当了个人软件开发流程记录的有力工具 —— 无论是公共文档还是私有文档。可以看到，我对其意义提出质疑的主体并非流程记录本身，而是书中给出的流程记录样板，即一个反映工作用时分配比重的简单信息表格，如果采用任务看板、TODO List、燃尽图等结合的形式，开发流程记录可以非常有效。具体而言，我体会到了以下意义：

1. 知识管理：记录个人开发流程可以帮助开发人员记录和整理开发过程中的思路、决策、问题和解决方案等。这些记录可以作为有价值的知识资料，供自己在未来的项目中参考和复用，避免重复犯错，并提高开发效率。开发 Ficus 的过程中，我们没有使用任何组件库，作为实现样式的主力人员，我在流程记录的过程中总结了许多的 CSS、JS 技巧，这无疑提升了我的开发水平。因此，个人软件开发流程记录成为了我在本次开发过程中获得个人成长的重要资料。通过回顾自己的开发流程，可以发现不足之处、改进的空间和学习的机会。这有助于不断提升自己的技术能力和专业素养。
2. 可追溯性和审计：记录软件开发流程可以提供项目的可追溯性，即能够追踪每个开发阶段的活动和决策。这对于项目管理、代码审查和故障排查等方面非常有价值，能够提高项目的可靠性和质量。

然而，记录个人软件开发流程并不是每个开发人员都必须执行的要求。对于个人小规模项目或独立开发者，记录开发流程可能显得过于繁琐和冗余，例如，结对编程的过程中我就完全没有在流程记录中体会到什么积极之处。在这种情况下，灵活性和效率可能更为重要。

Q5：挑选舞伴——什么是适合结对编程的双方

在结对编程实践中，我体会到还是与代码水平和技术观点相近的程序员结对更加舒适，实际上也并没有太多“浪费时间”、“思维趋同”的问题，与 Y 同学的合作是相当愉悦与顺利的。如果换成与水平远高于我或远低于我的人合作，或许并不会有如此美好的回忆。如果两位结对编程的开发者水平相近，他们可以更容易地共同理解和解决问题，避免沟通障碍。他们可以互相促进，相互学习，并共同努力提高技术能力。在工作中，他们可以共同分担任务、迭代改进代码，并共同完成项目。

只不过，比起水平，个人认为更重要的是建立良好的沟通和合作机制。双方应该互相尊重，积极倾听和交流，共同制定工作计划和目标。双方应该以共同的项目成功为目标，并愿意相互学习和提供支持。同时，定期进行反馈和评估，以保持合作的有效性和效率。

不明白的旧问题

无。

产生的新问题

其实并非是一个问题，而是在实践过程中，与之产生了冲突的一则信条。

软件的存在和发展是为了满足用户的需求和提供价值。没有用户，软件就失去了存在的意义。

有的时候我们还是难免会变成傲慢的开发者，规训甚至忽视用户。这种情况下开发的产品更应当被称为 toy ，那么，应当如何在开发过程中战胜这种程序员的傲慢呢？

在实践中学习到的知识点

需求

• 用户需求调研和收集
• 需求规格化和优先级划分
• 用例分析和用例建模
• 需求文档编写和管理
• 需求验证和确认技术

设计

• 系统架构设计
• 数据库设计和数据建模
• 用户界面原型设计和用户交互体验设计（数不清手画了多少 SVG ……）
• UML 建模和图表设计
• 接口设计和 API 设计
• 性能优化和可扩展性设计

实现

• 编程语言和开发框架
• 数据结构和算法
• 更深入的前端开发技术
  • 不使用任何现成组件库意味着从样式到动画都需要手搓，在这个过程中学到了很多不一定有用的奇技淫巧，例如卡 keyFrame 做动画等等，虽然效果粗糙，但十分有趣
• 版本控制和协同开发工具

测试

• 单元测试和集成测试
• 自动化测试工具和框架
• 测试计划和测试用例编写
• 性能测试和负载测试
• 安全测试和漏洞扫描
  • 此处需要感谢我们的用户，为我们爆出了一些安全漏洞
• 质量标准和流程规范

发布

• 软件版本管理和发布策略
• 部署和配置管理
• 易于阅读的用户文档编写
• 市场调研和竞争分析
• 必要的营销和推广策略
• 用户反馈收集和分析

维护

• 及时的故障排除和修复
• 版本升级和迁移（热更新）
• 及时的用户反馈管理和改进
• 安全更新和漏洞修复
• 性能优化和代码重构

理解与心得

结对编程

结对编程优缺点

• 优点
  较大程度上可以改善代码质量，伙伴的审查往往能及时发现代码中的问题，避免埋下后患（虽然这个发现问题的效果是有限的，所谓的后患有时依旧会发生）。
  一定程度上增强了沟通和知识共享的水平，减少了信息交流和理解上的问题，Yyy 具有创意的抽象思维时常启发笔者这个算法费勿。
• 缺点
  需要相互适应：两个程序员之间有不同的工作风格和作息习惯，需要相互适应才能顺利合作。非常抱歉笔者的阴间作息带坏了 Yyy 。
  笔者个人感觉结对编程导致自己花费了更多的时间和精力来完成任务，增加了成本和时间开销，如果一个人完成这个任务可能双方都没必要花这么多时间 —— 当然也有单词链任务本身的复杂度限制原因。

心得体会

在实践中初步体验了软件开发的团队协作过程，一定程度上提高了跨生态开发的编码能力与信息整理能力，犹记得被环境折磨的那几个晚上有多么崩溃，当然看到成果的那一刻也是相当欣喜的。

团队项目

跟 Ficus 团队的大家合作非常愉快，在增长开发知识、编码经验和一份足以让我写进简历的“小”项目的同时，我更高兴的是一下子收获了与六位兄弟的宝贵友谊，这对在计算机学院自闭了两年的笔者来说弥足珍贵 —— 正如我在前面的“新问题”一节提到的，其实我一直以来是一个傲慢的不相信团队协作的程序员，但在 Ficus 度过的时光让我非常愉悦、深切地体会到了 1 + 1 > 2 的实感。

我想，我今后会长久地记得我们在主楼研讨室闷热的空间里度过的星夜。