| 这个作业属于哪个课程 | 2020春北航计算机学院软件工程(罗杰 任健) |
|---|---|
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 不求变强，只求做好，成为一颗有用的螺丝钉。 |
| 这个作业在哪个具体方面帮助我实现目标 | 总结回顾本学期软工收获 |
| 以前提问题的博客地址 | 提问链接 |
问题回顾与解答
如何面对非专业能力培养的课程？
这学期比较典型的一门课叫做计算机科学方法论，是一门主讲展示与写作的课程，不涉及代码编程，也不涉及任何学术知识，但是我们从中学到了很多技能。比如：快速熟悉一个领域的专业知识，做好一个presentation，写好一篇科技报文。在学习之前，这些技能在我们看来是没用的，学完之后的感觉则是技多不压身，以后可能有机会用到，也确实在某些场合用到了。
以及一些政治性课程，在出席市政府组织的宴会时，宴席上的长辈都会谈论关于党和国家的话题，在问道的时候不至于一问三不知，避免了书到用时方恨少的尴尬。
就这个问题而言，没有绝对没用的课程，学了都有它的用处，但也有可能一直用不上。
对占80%工作时长的测试工作，只算20%工作量存疑
这个问题在实际合作中非常真实，我们接受上届的项目之后，新增的工作，尤其是后端，几乎没有写多少新的代码，大部分时间都是在熟悉项目，或者为了修改由于不熟悉项目而造成的bug。写的测试文件找出的报错太多（包括测试文件也会出错），有些时候得删些测试文件一个一个排查。项目越往后，bug越少，而测试的工作其实也会随之bug的减少而懈怠。后期找漏洞的难度要比前期找漏洞难（我们的开发质量有点莽），那么以bug数量论测试工作就很不合理。在实际找bug的过程中，除了测试文件找出的bug，大多都是前端反馈的问题。而对应的测试文件，也是对应的开发人员写的，基本上不会出现写这个API的人，为另一个API写测试文件，即使写了也无法保证测试文件的质量，这是真实发生过的事情。
毛绒玩具提高注意力存疑
我为了证实这个结论，我买了手办放在了电脑旁边。
效果很好，真的可以提高注意力。当我熬夜写代码困了的时候，看见手办就会精神抖擞，有了继续奋斗的勇气。
熟人社会问题
世界这么大，熟人一起工作挺难，一个团体只有一个人被孤立就更加不可能了，所以这个问题只存在于假设。在实际配合过程中，我们小队互相都不熟悉。在换人阶段，也是去留随意。
大学生不能直接胜任白领问题
在本次软件工程合作中，我们小队的每个成员都是由生疏到熟练一步步走来的。一个新的工程，新的项目难免有不熟悉；新的环境，新的队友都需要时间去习惯，去磨合。小飞的想法非常简单，但是直接把他安到白领的位置，没了领路人，他反而会无所适从。就像我们的PM一样，一开始什么都不会，连喊人开会都喊不齐，以至于前几次开会都搁置了。
角色扮演经验缺失
一旦合作后就会熟悉其他人的工作，剩下的就是依葫芦画瓢。在实际合作过程中，我们后端管理数据库的随时可以去写API，写API的还一边写着测试文件，负责测试的时不时去管管数据库。后端和前端的互动也非常频繁，经常一起开会共同找bug（因为不确定到底是哪边出了问题）。经验缺失不是非常严重，就我个人而言，对后端的各项工作非常熟悉，对前端和PM干啥也有所了解。
待解问题和新困惑
很多博客都是告诉我们要努力，给了我们很多中肯的建议。有很多大佬都取得了非凡的成就，就像高中返校宣讲的都是成功的学长学姐，但从来没有人告诉我们失败了该怎么办。我想说，我们即将就业了，投出去的简历肯定会遇到被筛掉的时候，我们该如何面对这些拒绝。大部分人都是成功后讲述自己如何熬过人生的低谷，但是很少有人在人生的低谷平淡的叙述自己的经过。马云在叙述自己的发家经验中提到，成功的经验是相似的，失败的人各有失败的理由。我们该如何做好对失败的准备？比如没能上岸，也没有offer。
学到的知识点
需求
了解用户需求才能做出让他们满意的产品。但是用户的叙述往往很不专业，有时候他们的需求连他们自己都说不清楚（五彩斑斓的黑？），这就需要我们有很强的理解能力和沟通能力，进一步引导他们准确表达自己的需求。
设计
在产品设计阶段，一万个人眼中有一万个哈姆雷特，但是最终只有一个设计方案。我们采取圆桌会议的形式群策群力，敲定了最终的设计方案。
实现
我们接手的是上一届的项目，首先就是学习相关文档，了解项目框架和代码规范。复现上一届的功能，再新增代码。复现上一届的功能远比想象中困难，文档寥寥千余字，环境搭起来各种问题都会出现，甚至会出现文档与代码不匹配的问题，这带来的麻烦是最大的。这也就体现了说明文档的重要性，不好好维护的文档还不如没有文档。
测试
在测试阶段我们结合了人工测试和单元测试。单元测试保证每个接口的正确性，人工测试验证最终结果的正确性，即网页是否正确显示，功能是否正常运用。测试代码的编写主要由开发人员编写，因为开发人员对这块代码实现的功能最清楚，这应验了书中的要求。
发布
发布后一定要有使用说明。一定要争对核心用户宣传。不同于其他队伍，我们团队的核心用户为社联和社长，所以没有在各个群进行铺天盖地的宣传。
维护阶段
日常检查服务器是否死机。写好API文档。写好使用说明。
心得体会
个人项目
一个人开发随心所欲不逾矩。只要在本地仓库管理好版本就ok。
结对项目
需要及时沟通，不能延误对方进度。需要做好代码管理，及时上传代码，适时merge。这次结对编程的问题很明显，开发周期短，磨合期短，互相不熟悉导致难以开口，效率较低。
团队项目
人多开会难，意见多。开发过程中阻塞情况时有发生，对于配合的要求更高。作为项目中的一员，专注于自己手头的事是远远不够的，你的队友可能会遇到一个人无法解决的问题，这时候他就需要其他人的帮助，防止整个队伍被拖节奏。