终章——软工提问回顾与个人总结

Posted 2021-06-23 Gracia

终章——软工提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业的要求在哪里	作业要求
我在这个课程的目标是	积累软件开发经验，提高工程能力
这个作业在哪个具体方面帮助我实现目标	课程回顾，解决自己最初的疑问，分析自己的收获

一、提问回顾

在课程初，曾经通读过邹欣老师的《构建之法》一书，并在通读《构建之法》与CI/CD工具尝试一文中提出了一些疑问，主要有六个问题，如今回顾，思考如下：

1. 复审者有权提出很多看似吹毛求疵的问题，复审者不必亲自调查每一件事，开发者有义务给出详尽的回答。

   对于这句话，经过实际的开发过程后，我有了实际性的体会。对于提问可否被查看代码注释所代替一问，首先规范的代码注释，说起来容易做起来难，尤其是在此次软工的开发中，开发人员一般只在关键地方做了注释，而难以做到在每个位置、每种函数之间的关系之间都做清楚的说明（或者说有但是复审人员也不一定能找对位置，实现相同的作用，也可能会因开发者的编码习惯问题，而呈现出大不相同的结构表达），因此，实际看来，复审者通过对开发者进行直接提问反而能够达到较高的效率，也能在与开发者的沟通过程中提出更有价值的问题。

   而对于复审者复审的范围及粒度一问，个人仍觉得复审者除了能够在整体上把握代码表现的正确性之外，也应该尽量在更细粒度上对代码进行审查， 以便能够发现更加细节、容易忽略的问题（如在特殊条件下代码会产生的bug）。但是开发过程中往往会产生大量的代码，这也增加了复审者审查的难度，大概也是其无法逐行对代码进行审查的原因，而这也是无法避免的。

2. 每日例会是否必要？

   对于这个问题，当时记得有很多人问了，现在回顾这个问题问的也很有必要，经课程组调整，两日一次的例会对于我们来说还是比较合适的，而且定期的例会可以及时把握项目进度，让成员之间互相沟通，及时解决问题，达到更好的开发效果。实际看来，采取线上例会的话，可以省去很多时间，也能达到例会的目的。

3. 敏捷开发究竟特别在哪里？

   对于这个问题，评论区有人进行了比较详细的回答

   这可能是种错觉，这里”普通的软件工程的项目流程"例如传统的"瀑布模型"，它的执行就严格按照线性进行。举个栗子，目前团队处于“需求分析”状态，那整个团队就一起把未来这个产品形态所需要满足的一切需求列出来，然后逐个分析，得到一个非常充实/完备的需求分析文档，接着进行下一个流程。

   从我的描述中应该能体会到，瀑布模型不强调快速迭代，虽然同样是以用户需求为核心，但每个迭代阶段都是需要以上个阶段的完成作为起点（比如按部就班地先撰写“完备”的需求分析文档，再撰写“完备”的系统设计报告等），这样下来可能一个开发周期会拖得很久。比如，半年开发了一个软件，这时候用户的需求可能已经变了，或者跟开发者想象的需求不太一样，或者同类竞品早已占领市场。

   我个人觉得敏捷开发的精髓在于"敏捷"二字，这就意味着我们需要快速地设计一个最小可用产品"MVP"，然后快速投入市场获得验证，吸取用户的初步反馈后再定下个开发周期要做什么，如何做。

   据此看来，敏捷开发在于其快速性、及时性，再经过实际开发，个人感觉的敏捷开发如下：

   • 团队事先需要进行需求分析以及功能设计，但是不需要形成有关的完备的文档
   • 开发过程中，可随时根据出现的问题以及用户需求变更进行功能调整，而这一调整通常不影响最初形成的需求文档
   • 团队可以反复快速进行设计→开发→测试这一迭代过程，而这往往只需要简单的记录，而不需详实的文档
   • 团队能够做到在更短的时间做出更加符合用户要求的产品
   • 但在个人看来，这种方法更加适合小型的产品项目

4. 新加入的成员（初学者）在技术不熟练的情况下应该被分以什么样的任务？如何快速地与团队进行融合？

   这个问题，经过一学期的学习，我有了一些新的理解，但仍存一些疑惑。一个团队中难免有“经验丰富者”与“初学者”，对此，首先，项目中的关键任务不会分配给初学者，其次，初学者在同等工作时间内被分以了更小的任务量，这两点都是合理并且能够接受的。而对于这类人，不妨先从小项目开始做起，找更加适合自己的团队，慢慢积累经验，提高自身能力，然后再去挑战复杂项目。此外，测试工作也可以通过学习“前辈”的代码，提高自己的能力，未尝不是一个好的机会。所以将挑战性的任务交给初学者，似乎变成了一件风险极高且并不获利（不包括初学者）的事情。

5. 创新与技术，二者不可得兼？

   在一个团队中，二者兼得的人必然是人才，而在一个配置完备的团队来说，自然有设计、开发、测试等的分工，开发人员只需按照事先设计好的，专注开发，去实现必要的功能。而若开发人员同时具有创新性，也可为项目注入新的活力，给人惊喜，否则也不应苛责。

   如同本次软工的开发过程，开发的同学只需按照实现讨论过的页面设计（或原型设计）实现功能，而进行页面美化等却不是他们的硬性任务，如若在开发过程中开发者能够对页面进行美化，这无疑是一件让团队惊喜的事情，但是如果他们只完成了其基本任务，那团队也不应过分要求。

6. 成员自行探索的能产生有利影响的新技术为什么不进行采用呢？

   这个问题，我在开发过程中也有了一些体会。首先，开发所用的技术是在一开始就确定好的，这样方便各个部分之间的整合，如若使用新技术，即使对自己那部分产生了有利影响， 但是这种影响很难扩展到整个项目，甚至会给整个团队的整合带来很多麻烦，未免有些得不偿失。然而如若这种新技术真的有价值的话，应该在充分测试之后，考虑在开发新的项目时对其进行推广使用，而非影响当前项目的进度。

二、在实践中学习

1. 需求

   需求分析时应该通过向各个年龄阶段、不同工作背景的人发放调查问卷（尤其是项目的目标用户），来进行充分的需求获取与分析，集百家之长，而非一家之见。

2. 设计

   做功能设计及页面设计时，应充分考虑用户需求与使用习惯，功能设计上尽量直观、简便，让用户能够凭借使用习惯顺利地使用这种功能，否则应该给予充分的使用指导。在界面设计上，应该符合软件定位，并在此基础上进行自己的设计，让其具有自身的独特性与标识性。

3. 实现

   在实现上，应该完全按照设计文档，尤其是接口方面，一旦定义最好不要进行修改，如若遇到了设计中的不合理之处，应该与团队中所有成员进行沟通之后再做合理改动，确保团队中每人都知悉。

4. 测试

   应保证测试覆盖的充分性与全面性，除了对基本的功能实现进行全面的测试之外，也应该对某些特殊行为进行测试，如压力测试、多平台测试、用户错误行为处理测试、单元测试等。

5. 发布

   发布之前应保证做了充分的测试（尤其是基本功能），并准备好收集用户反馈的渠道，便于之后的修改，此外，应该尽可能在多种渠道对软件进行宣传，扩大用户量。

6. 维护

   软件发布之后，除了根据用户建议进行修改，并发布新的版本之外，也要定期进行维护，保证软件的一切行为表现正常。

三、个人总结

本学期的软工课主要分为两个部分，结对编程与敏捷开发，包括为了写博客做的各种调研工作，均使我收获颇多。

首先是结对编程部分，通过与伙伴进行合作编程，了解他人的编程习惯，进行领航员与驾驶员的角色转换，让我在检视自己的编码规范的同时，也学会了一些新的编程技巧，同时，也在结对中感受到了合作的力量，体会到了思维的互补。

在敏捷开发部分，通过与团队成员长达两月的合作，我们完成了一个虽然仍有缺点，但是却饱含我们的辛酸与努力的项目。在这个过程中，十几次的例会，十几篇的博客，在此时回顾，都是很有意义的产物。我学会了如何在团队中找准自己的位置，如何与团队成员相处沟通，也学会了在团队中要更加看重集体利益，要懂得有所取舍、有所奉献。

通过这两次项目经历，我更加意识到了规范的重要性，不同于个人项目，可以随心所欲，只追求结果，合作项目往往个人只是完成一个部分，要保证自己所完成代码的易读性、规范性、正确性，才能顺利与他人的部分进行整合，不给他人带来困扰，最后获取一个令团队满意的结果。