软件工程实践总结&个人技术博客
软件工程实践总结&个人技术博客
| 这个作业属于哪个课程 | 2021春软件工程实践|W班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 课程回顾与个人技术总结 |
| 其他参考文献 | GORM 中文文档 |
回首过去
提出的问题
问题1：章节4介绍了结对编程，提出了结对编程的优点及一些要领，但为什么结对编程在所了解到的工作过程中（至少国内）很少实施？
- 在提出问题后助教有评论道：结对编程也是有前提的，要高效率合作，两人对需要完成的业务逻辑和接口都要熟悉。
在结对实践作业中，我与结对的同学间因为接口协商不充分的问题大大影响了效率，因此可以深刻体会到这样点。
结对编程的原本定义是两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。
但我认为这在当下主流的前后端分离的开发中，前后端的不同程序员显然不会采用这种模式。而即使是同样技术栈的程序员，无论他们本身或者企业都并不太会愿意承担磨合的时间成本和失败的风险。
问题2：章节5,6介绍了瀑布模型和敏捷流程两种区别很大的开发流程，当今软件相关企业会采用哪种？利与弊？
- 在刚提出这个问题时候，我的猜测与查阅资料得出的结果都是敏捷流程更适合当下环境的软件开发：瀑布模型有明确的需求、甚至说需要明确的需求驱动才会一步步进行。而敏捷开发则是通过部分需求开发满足最小需求的版本投入市场测试，根据反馈不断迭代更新软件。
但在本学期的软工团队实践与质量管理课程上，我更能体会到当下更多使用的是二者混合的版本：在大方向上选取敏捷的方法不断迭代新版本，但在各个版本内也借鉴瀑布的方法按一定流程逐步实现，如需求分析、初步设计以及再进行编码测试，并且其中每个流程会有相关的文档更新或推出，也体现出了瀑布模型的特点。综上，对于二者我们应该取其精华而用。
问题3:章节9.2.1中提到了Master Programmer（MP）和SlaveProgrammer（SP），MP和其他成员交流，了解需求，MP只写抽象的伪代码，或者对功能的描述；SP根据MP的文档，实现具体的功能。SP只用和MP交流。MP其中MP和现在的产品经理PM有什么区别？
- 通过构建之法可知，MP是核心编程人员(master)在微软创办人之一查尔斯提出之际就遭到了反对，因为没有人想做非核心的SP。
文章着力介绍了微软的PM，这个职位最重要的特点是：管事不管人，和团队的其他人平等工作，带领团队达成最重要的目标，并保持团队的平衡。在学期结束后，观察各个小组的组成可以发现，小组中可能不一定存在技术突出的MP、但一定存在链接团队的PM。
问题4:章节9中提到了PM，介绍了一系列优点，那这个职位的存在对于软件开发是有利无弊的吗？
- 此为阅读中产生的疑问，当时在后文中便得到了解答：“PM太多了以后，由于大部分决定都是经过平等而反复的讨论协商折中得到的，一个可能的负面后果便是委员会设计（Design by Committee），
“牛人主导的项目，往往会大起大落；PM主导的产品中，“不犯大错”成了一个特点”。在实践中，我个人便是担任这一职务，在过程中确实更多是验证项目进展中是否符合先前文档安排等等，在确定目标后较少提出新的功能。
对于问题的答案仍然保持原来的观点，即PM不会百利无一弊，但对于追求稳定性的企业来说，利远大于弊。
问题5：章节16.1.4中提到：“大家听了很多创新者的故事，有些人想，他们真了不起，第一个想出了这些美妙的想法，要是我早生几十年，也第一个实现那些想法就好了”，应该如何看待这个观点？
- 后文明确指出了“成功的创新者未必是先行者”，通过阅读后的思考，我认为首先应把握关键词“成功”，提出想法实施的先行者必然称为创新者，但关键是不一定成功。
结合前文举例可以知道这有多方面的原因：
1、创新有颠覆式和改进式两种，而往往出颠覆性的创新才被人标记为成功的。
2、原文提及“创新是几代人、许多团队前赴后继持续创新的结果。就像拼图一样，往往拼好最后一块的人得到了最大的荣誉。” 这一点在基础学科的发展经历可以得到深刻的认识。而在软工实践中，同样类似的项目可能在往届的小组中也有人提出甚至施行，但最后留下深刻印象的只会是完成最好的那组，但这不意味着前面小组的想法不是创新的。
阶段收获
需求
- 需求分析阶段，收获最大的是作为一个小组对一个软件项目进行分析思考，讨论的过程。往常编写程序不会做过多的分析，简单的直接开始敲代码，稍微有困难的则是思考后上网搜索。而在软工实践中，经过所有组员集思广益往往能在每个需求点提出更好的解决方法，让我学到很多。而作为pm在协调人员和具体模块的安排上体会到了分工合作的重要性，在答辩上听取老师和其他同学的提问也认识到作为开发者视角往往会受限，从用户的角度出发才能设计出功能与健壮性更佳软件。
设计
- 设计阶段包括了原型设计、项目数据库设计和系统设计，其中还有功能模块层次图、E-R图、接口设计等小项目。这阶段收获便是将往常课本中抽象的知识点进行了实际的操作设计，加深了体会。在整理如数据库设计等部分时，从后端主要负责人的设计中学到了很多设计规范与思路。在制作设计书时与其他成员配合推进、制作ppt时尝试了精简呈现大量内容也提高了相关技能。
实现
- 实现阶段主要是作为pm协调前后端开发，如更新接口文档等，也进行了小部分后端接口的编写。在该阶段充分感受到了良好的接口文档的重要性，因为之前的商量的存在未解决问题，在编码中便造成很大的困扰，不少地方对不上不得不推翻重做。其次是第一次接触了Go语言，使用了它相对丰富的标准库进行了一些业务逻辑的编写，增强了一定的编码能力。
测试
- 测试阶段主要使用了postman测试后端接口和go的testing包单元测试。虽然不是主要测试人员，但仍然体会到每个接口都要进行测试是痛苦但必要的过程。而由于在编写同时进行测试，及时更新接口文档并提醒前端极为重要。同时在实现阶段最后还应该留有一定时间作为缓冲，否则出现问题可能来不及修改。
发布
- 发布阶段的收获集中在了解了小程序审批流程，也通过问卷收到了许多有益的反馈，反思了设计和实现工作中的缺失。
理解和心得
个人项目
- 个人项目主要作为热身，在假期和开学间过渡以进入学习状态。个人项目编写中体会了久离键盘后的生疏，还初步学会了使用psp表格进行规划和github进行代码管理。
结对编程
- 在结对编程中，我初步体会了前后端合作的过程，学习了vue框架的使用。尽管最后结果并不完美，但在过程中更深的体会了合作编程的优点缺点，也对原型设计、接口文档设计有了初步接触和应用。
团队项目
- 团队项目中进行编码部分较少，更多在于分析需求，协助协调前后端，撰写文档等。对于相关技能得到了一定的锻炼，但对于编码能力需要更多的练习提升。
