软工[I.1] 个人作业：阅读和提问

[I.1] 个人作业：阅读和提问

---

项目	内容
这个作业属于哪个工程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13365
我在这个课程的目标是	学习团队软件开发方式, 丰富开发经验
这个作业具体在哪个具体方面帮助我实现目标	能够从成熟教程,博客中了解什么是优秀的软件架构,思考自己能够在软件团队中发挥怎样的作用, 如何更高效的推进软件的开发与完善

---

阅读提问

1. 对于书本第二章-2.3-个人开发流程(P34), 其中提到了PSP模型并将它用于评估工程师实现需求的效率. 这种评价方式放到现代我认为有一些不合理性.主要想到的有几个方面:

   • PSP模型中使用"所花时间百分比"来体现"效率", 例如书中也提到了大学生与专业工程师在需求分析,代码编写,测试几个方面耗时有差别, 但专业开发任务与大学生实践项目显然是无法画等号的, 在正式工作中训练过的工程师可能要遵循正规开发的评审测试流程, 而大学生可能并不知道这些工作要如何下手, 这种对比下出现的耗时百分比差距真的有很高的参考价值吗, 说学生到专业程序员写代码的时间反而少了, 会不会是专业开发中整个开发流程拉长而导致的假象?

   • 放在现代, 大模型使用, 开源项目的借鉴等新的元素加入到软件开发的过程中, 合理的使用工具与开源代码无疑是可以提高工程师开发效率的, 并且提高程度很多时候可以填补工程师本身的经验差距, 这在PSP模型中并没有体现.

   • 软件开发流程通常并不是简单的单向流程, "代码编写-测试-需求重审"有时候才是开发的常态, PSP模型中似乎并有考虑到这一情况.

2. 第四章-4.6-两人合作中的不同阶段和技巧, 其中提到的一个关键点是尝试理解沟通对方的思维方式, 但实际合作中这一点往往难以达到, 在合作双方对对方的领域都不了解的情况下, 这种沟通方式可能需要双方都投入大量的学习成本. 而在敏捷开发的情形下, 这种小规模的合作往往是短暂的, 若每次合作都要学习对方的领域, 一方面效率较低, 一方面也并不利于工程师自身的垂直发展, 要如何解决这种问题?

   我认为短期合作的状态中, 双方并不需要达到相互了解的程度, 可以通过一个共识约定/协议来达成高效的合作模式, 例如前后端共同协调一份api文档, 而不需要关心对方的具体实现方式.

3. 第十章-10.4-功能驱动设计, 这一部分介绍了将用户需求转化为成员开发任务的几个步骤, 在此外有几个没有提及的问题:

   • 技术更新问题: 常见的开发领域中开发框架往往是在不断更新进步的, 如何保证新技术出现时项目能够最灵巧地迁移到新框架中

   • 协调问题: 书中描述的是一个完整的团队针对一个新需求的初步拆解过程, 但初步评估中往往难以确定具体开发成本, 在持续开发中如何协调不同领域的开发进度, 排期中出现风险时如何管理

4. 十二章-12-1-1-用户的第一印象(P259)中提到隐藏遥控器的过多功能, 面向学习较弱的老年群体推出简洁的遥控器. 这种做减法的优化思路很多时候确实有一定作用, 但并不是通用的, 很多较复杂的工具使用确实有较多的功能且并不适合舍弃一部分. 在这种情况下有没有其他优化的方法.

   老人难以使用复杂的遥控器本身并不是不想要使用高级的功能, 只是按钮过多带来了压力而无所适从, 这本质是前端与硬件设计上的不合理, 我们可以使用更加符合一般人直觉的UI界面, 推出功能更集成且直观的控制硬件(例如语音集成控制, 遥感手柄等), 填补复杂技术与老年人学习能力之间的差距, 而非以删减的方式逃避问题本身.

5. 十三章-13.2.9-压力测试(P291)中提到压力测试要考虑客流量与时间维度的波动, 这在现代云服务弹性化,无服务化的背景下还需要投入太多的精力考虑吗, 或者有哪些新的应对设计来最高效的满足用户访问需求?

   我认为压力流量管理方面可以在云服务中满足, 这样使得工程师能够专注于软件本身的优化完善上, 事实上一些厂商(如cloudflare)已经推出了这样的服务, 能够对接Next, Remix等现代全栈框架. 当然这部分服务的体验还有很多可以优化的地方, 但我认为这是软件抗压问题更好的解决方案.