[I.3]个人作业：结课总结

[I.3]个人作业：结课总结

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习软件工程的基本构建方法与团队协作方法，最终实现一个完整的软件
这个作业在哪个具体方面帮助我实现目标	总结开发过程中遇到的问题、解决方法，并且回顾之前的疑问

链接之前的文章：
[I.1] 个人作业： 阅读和提问

一、回顾之前的问题

问题1：平衡测试与开发

在追求100%代码覆盖率的单元测试过程中，开发者可能会面临测试代码复杂性和维护成本增加的问题。然而，100%的代码覆盖率并不能完全保证代码的正确性，尤其是在处理错误路径、性能问题、并发问题和外部依赖时。那么，如何在确保代码覆盖率的同时，平衡测试的复杂性与代码质量？

回答
在软件工程实践中，平衡测试与开发的核心在于明确测试的目的与价值。代码覆盖率虽然是衡量测试完整性的重要指标，但不应成为开发的负担。关键在于通过合理的测试策略，在保证代码质量的同时避免过度测试。

首先，应当根据代码的重要性和风险等级确定测试优先级。核心业务逻辑和复杂算法需要较高的覆盖率，而简单的工具类或配置代码可以适当降低要求。测试的重点应放在关键路径和易错场景，而非盲目追求全覆盖。

其次，采用分层的测试方法能够有效降低维护成本。单元测试适合验证独立模块的逻辑，集成测试关注组件间的交互，而端到端测试则确保整体流程的正确性。通过合理分配各层测试的比例，可以在保证质量的同时减少冗余用例。

最后，测试的可持续性同样重要。良好的测试代码应具备可读性和可维护性，避免过度依赖实现细节，从而降低因代码变更带来的测试维护成本。

综上所述，平衡测试与开发的关键在于目标明确、分层优化、适度覆盖，使测试真正成为提升代码质量的助力，而非开发的阻碍。

问题2：结对与团队复审

结对编程中，已经要不间断的进行代码复审，这与团队的复审是否有冲突，或者是工作的重叠？该如何平衡？那么代码既然已经被不间断的复审了，团队的复审是否还有必要呢？

回答
在结对编程和团队代码复审的关系上，通过实践和理论学习，我认识到二者是互补而非重复的。结对编程实现了实时、持续的代码审查，能即时发现语法错误和基础逻辑问题，同时促进知识传递。但这种紧密协作容易形成思维惯性，可能忽略更高层次的设计问题和规范一致性。

团队代码复审则提供了更宏观的视角。正如《代码整洁之道》所述，多人参与的复审能发现潜在的设计缺陷、性能问题和可维护性隐患。不同开发者对代码的理解角度各异，团队复审正好弥补个人思维的局限性。

理想的平衡方式是：对核心逻辑采用结对编程确保基础质量，同时保留团队复审关注架构设计和规范遵守。重要模块可以两种方式并行，而简单功能则可适当简化流程。这种分层审查机制既能保证效率，又能确保代码质量。

问题3：PM的职责

开发和测试是一个软件的非常重要且核心的部分，但是书中写了PM做开发和测试之外的事情，那么PM能不能做开发和测试呢？

回答

关于项目经理（PM）是否应该参与开发和测试工作，通过研读《人月神话》等经典著作和团队实践，可以得出以下结论：

1. 角色定位差异
   PM的核心职责是项目规划、资源协调和风险管理，而非具体技术实现。过度参与开发测试反而会分散其管理精力，影响项目整体进度把控。

2. 技术参与尺度
   PM可以适当了解技术细节以提升决策质量，但直接参与编码测试可能带来问题：

• 技术能力可能不及专业开发者
• 容易造成职责边界模糊
• 可能影响团队技术决策的客观性

3. 例外情况处理
   在初创团队或特殊场景下，具备技术背景的PM可以临时支援开发测试，但应明确：

• 仅限于紧急或辅助性工作
• 需保持管理工作的优先级
• 避免形成长期依赖

最佳实践是PM通过定期技术评审和测试报告掌握项目质量，而非直接介入具体实现。保持适度的技术参与既能确保管理有效性，又不逾越专业分工边界。

问题4：开源还是闭源？

该如何看待开源还是闭源呢？

回答
关于项目开源与闭源的选择，通过《大教堂与集市》等著作的研读和行业观察，可以从以下几个维度考量：

1. 核心价值定位
   开源更适合需要生态共建的技术基础设施，能加速迭代并形成社区效应；闭源更利于保护商业机密和保持竞争优势，适合差异化明显的商业产品。

2. 资源投入评估
   开源项目需要持续投入社区运营，实际成本可能高于闭源；而闭源的维护成本集中于内部团队，但会错失外部贡献。

3. 商业模式适配
   采用开源策略时，需明确盈利路径；闭源则直接通过软件授权获利，但可能面临更激烈的市场竞争。

总的来说，基础技术层可优先开源以建立行业标准，应用层产品建议闭源保障商业利益。关键要统一技术战略与商业目标，而非简单跟风开源潮流。

问题5：如何看待创新和小作坊

那么，应该如何看待技术创新和自己的小作坊的关系呢？是一个人埋头苦干在自己的小作坊里，还是风风光光地展示呢？

回答

关于技术创新与个人实践的平衡，我的理解是：

1. 小作坊的价值

• 提供安全的试错空间：可以不受干扰地验证想法
• 培养深度思考能力：独自解决问题能锻炼技术洞察力
• 保持创新纯粹性：避免过早受外界评价影响

2. 展示交流的必要性

• 获得关键反馈：外部视角能发现盲点
• 建立行业连接：展示成果可能带来合作机会
• 验证市场价值：真实用户反馈是技术落地的试金石

3. 最佳实践路径
   建议采用"螺旋式发展"模式：
   1）在小作坊完成核心验证
   2）选择合适平台小范围展示
   3）收集反馈后继续迭代
   4）循环往复直至成熟

技术创新需要"独处时的专注"和"开放时的勇气"的辩证统一。
正如《黑客与画家》所言，伟大的创意往往诞生于车库，但最终需要走向世界。关键在于把握技术成熟度，在适当的时机寻求外部视角，同时保持独立的思考能力。

二、亟待解决的问题

问题1：在团队化的编程过程中，如何权衡每个人的工作量，以及如何解决团队协作之间可能出现的分工不均、不愉快等诸多问题？

问题2：随着AI技术的广泛应用，我们又该如何看待AI编程与人工编程的应用？又要如何看待AI产物的著作权等隐私问题？

三、各阶段的收获

1.需求阶段
需求阶段进行分析的时候不能只靠自己空想，或者仅仅靠几个人一纸空文的谈话，而是要真真切切地从用户以及软件的可能使用者的角度出发,不仅仅是设身处地地思考,同时还要实地地区询问去调研用户的需求

2.设计阶段
设计阶段是六大阶段的一个核心阶段,要利用好之前需求阶段分析所收集到的信息,从多元化的角度进行软件的设计,主要从功能模块的角度出发进行设计,将一个软件分解为多个功能,并且设计出一个骨干支架来串联各个功能

3.实现阶段
在编码过程中深刻体会到"代码即设计"的含义。仅仅完成功能远远不够，需要特别注重代码的可读性和可扩展性。通过实践掌握了通过合理设计类结构、规范命名、添加必要注释等方式，使代码不仅机器能执行，其他开发者也能轻松理解。

4.测试阶段
认识到测试用例设计需要同时覆盖"正常路径"和"异常路径"。在项目中实践发现，仅测试正常流程远远不够，必须主动设想各种边界条件和异常情况，这往往能发现潜在的重要缺陷。这改变了我们最初只关注功能实现的测试思路。

5.发布阶段
学会了制定详细的发布检查清单。包括环境配置验证、依赖检查、回滚方案等，这能有效避免"明明测试环境正常，线上却出问题"的情况。一个完整的发布流程远比单纯的功能交付复杂得多。

6.维护阶段
体会到文档持续更新的重要性。维护过程中发现，如果没有及时更新的文档（包括代码注释、API文档、部署手册等），即使是原始开发者也很难快速定位和解决问题。这促使我们建立了文档与代码同步更新的机制。

四、个人体会

纵观整个软工课程,先是最初的理论方面的学习,如敏捷开发,结对编程的概念以及作用;再到后来的两两结对编程的实践;再到最后由团队组织进行的一个完整的小型软件开发工作;这一系列的工作,也是从个人到团体的一个演变过程.一个人的力量肯定是渺小的,即使到以后的社会上,仅仅依靠个人也是很难完成能上市的产品的研发与发布的,因此团队意识必须贯穿整个工程实践中.

不论在结对编程还是团队编程的过程中,让我最印象深刻的就是团队成员之间的协作.结对编程项目还好,两个人同时在一起进行一个简单的功能的开发,由于人数较少因此在团队协作方面的差错就比较少了.但是在团队项目中，协作的复杂度就呈指数级上升。我们团队采用Scrum敏捷开发方法，每周进行站会、计划会和评审会。最初大家都很不适应这种高强度协作模式，经常出现任务分配不均、接口对接失误、代码冲突等问题。记得在开发一个核心模块时，由于前期沟通不充分，两位成员分别按照自己的理解实现了相似功能，导致大量重复代码和资源浪费。这次教训让我们深刻认识到每日站会和详细设计文档的重要性。

在版本控制方面也收获颇丰。刚开始使用Git时，团队成员经常因为不熟悉分支管理策略而产生代码冲突。后来我们制定了严格的分支规范：feature分支开发新功能，dev分支集成测试，master分支保持稳定。同时建立了Code Review机制，每个Pull Request都需要至少两位成员审核后才能合并。这些实践让我们体会到工程规范的重要性。

通过这一学期的软件工程实践，我深刻体会到软件开发不仅是技术能力的考验，更是团队协作的艺术。从最初的个人编程到结对协作，再到团队项目开发，每一个阶段都在不断打破我对软件开发的认知边界。最大的收获不仅是掌握了Scrum、TDD、CI/CD等工程方法，更重要的是培养了团队协作的思维方式。这些实践经验让我明白，优秀的软件工程师不仅要会写代码，更要懂得如何与他人有效合作。代码冲突教会我们沟通的重要性，项目延期让我们学会时间管理，需求变更则培养了我们的应变能力。这些在教科书上学不到的实战经验，将成为我未来职业发展中最宝贵的财富。

软件工程没有标准答案，但有一点是确定的：只有将个人能力融入团队协作，才能创造出真正有价值的软件产品。