软件工程-提问回顾与个人总结

提问回顾与个人总结

原提问博客链接软件工程-个人阅读作业#2

一、温故知新

Q1：单元测试必须由代码的作者来写吗？

对该问题我仍然坚持当初的意见，单元测试由代码的作者或者了解功能定义，测试经验丰富的人编写都是可行的。不过根据结对编程中单元测试的经验，我现在倾向于由代码的作者来编写，尤其是对于小规模团队，因为这样有利于分工和责任分配。如果有了解功能定义，测试经验丰富的人，可以让其做整体的功能测试、压力测试等，以保证产品的宏观质量。

Q2：灵感不是职业人士必不可少的一部分吗？

这个问题在不同的人眼里应该有不同的答案，毕竟灵感并没有一个公认的量度。我的团队项目中有一个接口需要访问数据库，但要返回的数据量太大，在Alpha阶段压力测试时表现不理想。在Beta阶段开发时，我突发“灵感”，由于该接口返回的数据基本不变，为何不存储到内存中以避免对远程数据库的访问呢。不过在付诸实践后，经压力测试发现性能改善并不大。虽然说这种“灵感”对于大部分开发者来说已是随手的习惯，根本不能算作“灵感”。但我认为，正如我当初提问时的所感，这算得上是一种广义上的“灵感”。职业人士并不缺乏灵感，只是灵感往往与实践结合，在几番洗刷下只剩下经得住现实检验的作品。

Q3：只研习某一乐器的乐手这样的角色能否适用于计算机领域呢？

对于这个问题，我心中也没有一个准确的答案。不过从现实的角度考虑，将精力投入到单一擅长的方向进行研究对大部分人而言是比较合理的选择。而在我看来，在计算机领域，有所特长的同时最好要对其他子领域有所了解，拓展自己的视野，毕竟广度与深度兼备总比仅有某一维度要高大上些。

前情提要：冲刺期间．团队通过每日例会（Scrum Meeting）来进行面对面的交流，团队成员大多站着开会，所以又称每日立会大家依次报告：
我昨天做了啥
我今天要做啥
我碰到了哪些问题
每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时团队要启动每日构建，让大家每天都能看到一个逐渐完善的版本。

Q4：每日立会是否会适得其反？

团队项目的开发过程证明，这样的每日立会很有必要。在Alpha阶段，我们两天一次的例会虽然要求报告已做、要做、问题等，但是没有要求将已完成工作摆在明面上，只是口头描述。我们团队中的一位成员被分配了少量的项目前端开发工作，因为初次尝试前端开发，许多地方需要学习。在例会上发现该成员开发进度缓慢，始终在开发某个页面，不过大家并未放在心上，认为是不熟悉开发语言的原因。然而到了Alpha阶段即将发布时，前端负责人发现该同学甚至还没安装好前端开发工具，结果其工作不得不由前端负责人代做。在这样的冲刺阶段，例会督促作用十分重要，每个人对DDL的习惯和责任心并不一定相同，有的人会尽量按时完成任务，但也有的人可能完全不把任务放在心上。抵触心理也许无法避免，但毕竟大家都是为了同一个目标努力，每个人应当担负起自己的责任。如果真的适得其反，例会让个别成员开始应付工作，那只能说明其责任心不够。而没有例会的督促导致最终开发任务没有完成，这才是大家真正难以接受的事情。

Q5：对于课程中的结对项目而言，结对的成员水平可以不相当吗？

参考@syncline助教大大的指导，课程中的结对编程本质上对我们来说是一种尝试。尝试两人水平不相当的结对编程有何不可？虽说我在结对编程没有进行这种尝试，但我觉得不管结果如何，这种特别的尝试经验十分可贵。尝试的结果也许是一人编程一人旁观，然后水平高的一方直接把水平低的一方拉进黑名单；也许是菜鸟积极学习，寻找互补之处，努力跟上大佬的步伐，大佬也在教导中有所收获。总之，这种尝试并不会被否认，因为结果有好有坏，而这其中的关键是两人在面对这种局面时的想法和行动，是寻找突破口，还是破罐子破摔。

二、学习知识点

需求阶段

用户需求可分为必要需求和辅助需求，产品功能可分为杀手功能和外围功能，两两结合我们能得出功能分析的四个象限。

在团队项目开发中，如何分配最珍贵的资源——时间变得十分关键。首先要将时间优先分配在必要需求上，尤其是在第一象限的杀手功能上，这是产品的核心竞争力，而外围功能则要求不能落后于竞品。而对于第三和第四象限的功能则应当投入最低比例的时间，如果代价太大可以考虑直接砍掉。

设计阶段

设计阶段要注意文档的产出，如数据库设计、前后端接口设计。此外还有数据流图、控制流图等用来描述设计的模型。必要时可以直接用代码体现设计，如定义接口。当设计更改时，相关的文档、模型需要及时地更新。

实现阶段

作为团队项目，源代码的管理就十分重要。合理使用Gitlab的branch、issue功能，每次版本提交要与issue关联，每个开发任务完成就将相应的branch合并。当然利用CI/CD进行自动单元测试、自动部署也能大大地提高开发的效率，一定程度上保证代码的质量。

测试阶段

功能性测试根据范围由小到大可分为单元测试、功能测试、集成测试、场景测试、系统测试等。一般开发人员通过单元测试保证自己代码的质量，之后可以根据模块的复杂度、模块之间的耦合度来决定使用多大颗粒度的测试。如果时间资源有限可以将精力集中在场景测试上，以用户的角度尝试产品，这样更容易发现影响用户体验的问题。

发布阶段

渐进发布的方式给予我们里程碑式的开发方式。Alpha阶段要完成主要功能的试用版本。Alpha阶段结束后要有总结与反思的缓冲时间，进一步了解用户需求，接收用户的反馈，然后再开始更完善的Beta阶段的开发。不同阶段的覆盖范围也可以成递进关系，Alpha产品趋向于尝试，测试用户可以偏少；Beta产品侧重于稳定，可以用更大的力度宣传。

维护阶段

作为最后一个阶段，该阶段应当举行事后诸葛亮会议，进行总结与反思。具体可以采用5WHY的方法，从现象和结果出发，沿着因果关系链条找出问题的根本，得到以问题为根，分类为枝干，原因为叶的树状图。要牢记核心问题——如果你可以重新来过，什么方面可以做得更好？

三、心得感悟

整个课程由个人博客到结对编程，再到团队项目，每个阶段的体验都不尽相同。

个人博客侧重于自我剖析和理论知识的学习。个人阅读作业#1让我不由回想起当初选择计算机的初心，回忆这三年来各种学习经历，并给未来一个简单的规划。而个人阅读作业#2深入教材，提出问题，并调研源代码版本管理软件和持续集成/部署工具，为结对编程和团队项目做下铺垫。最后案例分析作业中，我对VS Code和VS进行了调研和评测，对产品的特点和市场进行分析，这让我以一种理性、量化、深入的全新视角来看待现实中的产品，是一笔宝贵的经验。

结对编程我最大的教训就是明白了沟通的重要性。沟通对于多人工作来说是如此重要，但很少有这样一门课程能真正教懂我们沟通的艺术，实际情况往往是在实践中不断探索方能找到适合自己的沟通方式。更具体的感悟和结对编程中遇到的各类问题可以参考结对博客结对编程终章 - 结束也是新的开始。

“团队合作”，这是本人在这一个学期的软工课程中感慨最多，同时也是需要自我批评的一个方面。7个人的团队（更准确的说是6个）已经不像结对编程那样沟通为重，而更要讲究规范。代码风格、会议过程、前后端交互等等，这些规范的落实能大大提高团队间沟通协作的效率。而本人作为后端负责人，虽然完成了自己的开发任务，但没有对整体任务有一个大体的把控，也没有做好issue及分工，实属失责。在我个人眼中，其主要原因是责任心不足，其表现如其他团队成员的私信没有心思回，DDL临近时开发动力却不足等。在此我十分感谢各团队成员的付出，我会谨记这次团队合作的教训，在今后继续努力。

不得不说，这门课是我本学期感悟最多的课，结对、团队，这些对我来说都是全新的体验。不过同学们的精力有限，还是希望课程组体谅一下能适当减少课程压力，比如减小结对编程的难度，毕竟在忙碌的课程安排中找到相同的空闲时间还是一件不容易的事情。最后感谢课程组的辛勤付出~