个人作业-提问回顾与个人总结-20373974阮正浩

[20373974阮正浩]

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	掌握团队开发软件的能力并实践
这个作业在哪个具体方面帮助我实现目标	总结团队开发软件的经验

一、问题回顾

提问博客链接

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

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

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

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

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

解答：

实际上很难说怎样的优化时机是合适的，如果在开发过程中感到当前架构无法满足需求或者拖累开发方向，就应当果断地进行一定的重构。在实际开发过程中，我深刻地感到有必要在一开始就尽量掌握整体的需求，设计出合适的架构，最大程度上减少重构次数，这样才是治本的方法。

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

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

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

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

解答：

在团队开发过程中，我深刻地体会到软件工程需要的计算机人才远远不只是会编程那么简单，除了编程能力，团队环境下的统筹管理、交流能力以及对需求的敏锐度都是宝贵的能力。计算机行业中不仅有个人的艺术，更有合作的艺术和工程的艺术，因此作为程序员需要在多方面磨练自己，成为难以代替的一员。

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

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

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

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

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

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

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

解答：

所谓敏捷流程说到底只是一个框架，最终还是要服务于实际开发。面对重大需求变化，PM应当先与客户进行充分的交流，排除误解的可能，当形成新的需求后，依据对开发影响的大小有理由中止当前开发转而进行新的改动，以避免无谓的时间消耗。

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

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

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


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

解答：

我认为美学方面的评价应当包含进用户体验的评价标准，因为其重要性不可忽视。就以我们开发的打字练习软件为例，如何呈现给用户一个符合审美的界面相对于其他部分反而是非常重要的一点，因为这直接关系到用户日常的使用体验。

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

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

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

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

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

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

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

解答：

这个问题还是不能死板，得看情况。不过一般情况下，系统而完善的测试最好有专人负责，因为这确实是一项重要而且工作量不小的工作。就像我们的开发过程中，一开始各自负责测试自己的部分，但是最终合起来总有一些隐蔽的bug，后来还是需要整体地进行相对完善的测试。

二、知识点

需求阶段：

竞争性需求分析的框架——NABCD：
N——need，需求
A——Approach，做法
B——Benefit，好处
C——Competitors，竞争
D——Delivery，推广

设计阶段：

表达实体间的关系：思维导图、ER图、UCD
表达数据的流动：DFD
表达控制流：FSM
统一的表达方式：UML

实现阶段：

开发者签入时需要做：

• 运行单元测试，相关的代码质量测试
• 代码复审，有参加复审的员工名字
• 和此次签入相关的issue，任务/task，缺陷/bug编号，等等，以备查询

测试阶段：

测试有很多种，按测试设计的方法可分为黑箱和白箱，按测试的目的可分为功能和非功能测试；具体的方式有单元测试、回归测试、压力测试等等，各有其特点和作用。

发布阶段：

金丝雀发布：在生产环境上引一部分实际流量对一个新版本进行测试，测试新版本的性能和表现，在保证系统整体稳定运行的前提下，尽早发现新版本在实际环境上的问题。

维护阶段：

提高可维护性的方法：

• 保存软件开发各阶段的文档,这对于理解和掌握软件的功能结构、数据、接口和约束有很大帮助
• 从需求文档弄清系统功能、性能的改变
• 从设计文档检查和修改设计
• 根据设计改动源代码，并从测试文档的测试用例进行回归测试
• 减少维护人员的精力和花费,提高软件维护效率。

三、心得体会

在本学期的软件工程课程中，我首次参与了团队开发，经历了从需求分析、设计架构一直到软件发布的整个开发流程。在团队开发中，个人能动性固然重要，但是团队的统筹配合更是重中之重。无论是代码风格、分支管理，还是接口设计、开发进度控制，都是需要整个团队去思考、去配合的。在团队中，我主要负责后端的开发，具体到后端的整体架构和接口的设计实现，同时，由于人手紧张，前后端的对接以及服务器上的部署工作也主要由我负责。总的来说，这次团队开发的经验对我来说十分宝贵，让我学到了许多在书本上难以体会的知识。

[GreyZeng]

美学方面的评价是否同样重要？

最明显的是：某些APP的精美皮肤需要付费或者vip才能使用。