个人作业-阅读和提问-20373974阮正浩

项目	内容
这个作业属于哪个课程	软件工程
这个作业的要求在哪里	阅读《构建之法》第三版，思考并提问
我在这个课程的目标是	学习软件工程的一般方法并实践
这个作业在哪个具体方面帮助我实现目标	帮助我在理论层面了解软件工程

问题一：什么是合适的优化/泛化时机？

阅读到第3章关于过早优化/泛化的相关文字：

过早优化：既然软件是"软"的，那它就有很大的可塑性，可以不断改进。放眼望去，一个复杂的软件似乎很多模块都可以变得更好。一个工程师在写程序的时候，经常容易在某一个局部问题上陷进去，花大量时间对其进行优化；无视这个模块对全局的重要性，甚至还不知道这个“全局”是怎么样的。这个毛病早就被归纳为“过早的优化是一切罪恶的根源”

过早扩大化/泛化（Premature Generalization）：软件的“软”还表现在它可以扩展。在写一个程序的时候，需要某个函数可以处理整数类型和字符串类型的信息，有的程序员往往灵光闪现————哎，能不能把类型抽象出来，让这个函数处理所有可能的类型？这样不就一劳永逸了么？有些软件本来是解决一个特定环境下的具体问题，有的程序员一想，我们能不能做一个平台，处理所有类似的问题，这样多好啊！这样的前景的确美妙，程序员的确需要这样的凌云壮志，但是要了解必要性、难度和时机

我虽然编程经历不算丰富，但还是深有同感。在例如面向对象课程实践中，由于需求会迭代，我总是期望在一开始就通过各种抽象提高程序的可扩展性，但是往往因为缺乏对项目的整体理解而使这些工作在后面的开发中成为无用功；但是另一方面，编写某个模块时如果视界过于狭窄，又容易让后面的优化和扩展工作难以进行，最终不得不重构。
所以，如何选择合适的优化/泛化时机，应当在对项目的整体把握到何种地步时展开工作，对我来说还是比较困扰的。

问题二：新发展趋势下如何保持核心竞争力？

第3章谈职业发展时引用了这样一个故事：

两个劫匪在亡命的路上看到一副绞刑架，劫匪小弟说，大哥，如果这世界上没有绞刑架，咱们的职业就好干多了。大哥说：你真笨！如果没有了它，这世上做劫匪的人怕是太多，我俩恐怕竞争不过同行，早就饿死了！

结合当下时代，计算机行业的入行门槛不断降低，竞争也越发激烈，上有大量培训班生产CRUD程序员，下有少儿编程大受家长青睐。就在最近，chatGPT出现，让世人认识到ai也有能力进行相当水准的编程行为，这更加压缩了一般程序员的生存空间。
在这种发展趋势下，什么才是计算机行业从业者的核心竞争力，应当如何保持？这个问题令人深思。

问题三：敏捷开发中用户的行为不可控怎么办？重大需求变化是否应当考虑突破敏捷流程框架？

第6章的敏捷流程的第四步：

第四步：得到软件的一个增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进。

按照这个流程，用户需求的变化当且仅当在形成一个迭代版本后产生，但正如书中后面提到的：

冲刺到一半的时候，产品负责人突然发现要马上做重要的改动！或者某个大佬要看某个不在计划中的功能的演示，怎么办？这种情况非常考验Scrum Master。如果一个运动员在跑一百米冲刺，但是跑到一半的时候，领导突然想看一百一十米栏的比赛，前面马上会摆起栏架，大家要准备8步上栏！怎么办？

有正常头脑的运动员和教练员会说：去你的，要改主意，也要等到老子冲刺完了再说啊！

有时用户会在开发过程中突然提出重大需求变化，书中的考虑是不应当中断冲刺过程，但我觉得可能要视情况而定。如果用户比较成熟，对需求的变化有充分的考虑和把握，同时需求的变化十分重大，涉及大量任务的修改，那么这个时候依然硬着头皮完成旧的意义不大的冲刺任务是否不太必要？是否可以考虑适时突破流程框架？

问题四：评价用户体验时，美学方面的评价是否同样重要？

第12章中有关用户体验的评价标准，作者总结了这些：

1. 尽快提供可感触的反馈
2. 系统界面符合用户的现实惯例
3. 用户有控制权
4. 一致性和标准化
5. 适合各种类型的用户
6. 帮助用户识别、诊断并修复错误
7. 有必要的提示和帮助文档

可以看到，作者并未特别提及美学方面的评价，但就我个人使用各种APP的经验来说，有许多软件在功能方面实际上大同小异，而一个充满美感的UI设计反而能帮助其夺得多数用户的青睐。这种情况在需要长时间或经常性操作的软件上尤其常见，比如市面上许多笔记软件就有这种特点。

问题五：敏捷流程中单独的测试角色是否真的不需要？

第14章质量保障中提到一个独立的测试角色往往是有益的：

14.2.1 测试的角色（Test）要独立出来么

首先，有分工是好事，软件团队中应该有独立的测试角色。所有人都可以参与QA的工作（报告Bug什么的），但是最后要有一个角色对QA这件事负责。不但角色要独立，而且在最后软件发布时，必须得到此角色的签字保证（Sign Off）。分工是社会和行业进化的结果，开发和测试其实是软件工程的两个分支，对于不同的软件/服务，测试的方式和程度都有所区别。独立的测试角色从用户的角度出发验证产品质量。独立专业的测试等同于代表客户对产品进行认证。

而回想之前敏捷开发中提到的：

以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负
责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。

这是否有一定理念上的冲突，敏捷开发的这种模式或许对个人要求过高，是否还是需要一个整体的测试角色？