提问回顾与个人总结
提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020年春季计算机学院软件工程（罗杰 任建） |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 提高自己的代码水平，熟悉团队合作 |
| 这个作业在哪个具体方面帮助我实现目标 | 反思总结 |
提问题的博客
对自己曾经提出的问题进行解答。
-
问题1：”软件工程是不是教那些不怎么会写程序的人开发软件？“
并非如此。在实际开发过程中，代码的质量是十分重要的。高质量的代码可以让团队的合作变得轻松愉悦，而低质量的代码要耗费其他人更多的时间、精力进行测试、对接工作。程序员的代码水平在软件工程中显得尤为重要，低质量的代码不会被隐藏起来“滥竽充数”，反而会在测试等环节被暴露出来。
诚然，软件工程更注重如何高效率地生产出高质量的软件，但要依靠测试来提高代码质量显然是不可能的。所以软件工程并没有弱化程序员代码水平在开发中地影响，反而提高了代码质量的地位。
-
问题2：为什么要结对编程
合作能更快地解决问题。我提出这个问题，是因为以往的开发任务，都是时间充沛、能够一个人完成的任务。但在软件工程这门课中，我们要在有限的时间内完成体量庞大的任务，有时候一个人就有些吃力。结对编程的话，两个人在一起交流能够一起解决问题，交替工作也给人留下了休息的空间。总体来说确实能够提升效率。有的问题商量着来确实效率很高。
-
问题3：非专业的PM会不会对团队造成伤害
会。PM在分工、原型设计上的盲目性会导致团队的开发事倍功半。而且PM不参与代码的话很难把握项目的进度以及工程质量。如果没有专业的PM，那团队一定要有一个“老大哥”式的任务来指导大家进行工作。总之团队最好要有一个核心。
-
问题4：“好的想法会赢”吗？
不一定。实际上很多设计在最终都要做出让步。团队的技术资源、时间资源都是制约条件。尤其软件工程只是一门课程，大家对项目的付出很有限。不仅是这门课程，现实中也有很多这样的例子。有时候好的想法不一定会赢。
-
问题5：如何维持一个磨合好的团队
关于这个问题，我们在Alpha阶段结束后进行了强制换人。我们当时决定换出我们的测试员，因为换出他我们团队的损失是最小的。维持磨合好的团队实际上是很不容易的，尤其是让团队成员保持高积极性。我能想到的办法就是升职加薪画大饼，除此之外别无他法。更换领导当然会改变团队的氛围，好的领导能凝聚团队，差的领导团队就是一盘散沙。
新问题
-
问题一：
团队贡献分的执行问题。贡献分本来是一个奖励政策，相当于前文提到的“升职加薪”，但是在实际执行中效果并不是很好，最终团队投票占了很大的比重。课程组用了很多办法避免开发中出现“抹不开面子”这种情况的发生，但是在最终评分上却没能体现出足够的奖励机制。希望课程组对贡献分做更详细的要求，比如在每日会议上记录贡献分的详细分配情况。
新知识
-
需求
NABCD法进行需求分析。典型用户帮助我们很好地定位了项目的功能。
-
设计
功能规格说明书、设计规格说明书、原型设计。了解了文档的重要性，学会了使用原型设计工具。
-
实现
一份好的接口文档可以在实现阶段省去很多交流的时间。设计良好的接口可以降低代码耦合度，在前后端对接时帮助找出潜在的问题。
-
测试
使用单元测试保证后端代码质量。前端使用兼容性测试反馈bug。
-
发布
宣传很重要，能根据用户需求改进同样重要。
-
维护
需要每天检查软件的运行情况，有小bug及时修复，重大的修改要慎重。
总结
-
个人项目
项目难度并不大，很大程度上是为结对编程服务的。该阶段主要让我们熟悉一些软件开发的流程，关于git的使用等等。测试真的很重要。
-
结对项目
我是首次接触到结对编程，总体的体验良好。两个人在一起工作确实达到了1+1>2的效果。但我和结对对象本身就很熟，所以免去了很多沟通上的成本。工作开展很顺利。
我学会了沟通，也学会了更多关于git管理、单元测试等方面的知识。
-
团队项目
我作为PM，写了很多篇博客，参与了一些前端的开发。总体来说学习了一些HTML和JS的知识，对敏捷开发流程有了一个更深入的了解。在软件开发中，写代码只是工作的一部分，维护文档、沟通交流与开发一样重要。课程组强制要求的十次会议真的十分重要，有效地促进了开发人员的沟通，对项目按时完成有着重要意义。
虽然在开发中遇到了各种各样的问题，但是软件工程这门课上我还是收获颇丰的。
