在自我追责中超越
Posted 都不吃大白菜
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了在自我追责中超越相关的知识，希望对你有一定的参考价值。
| 这个作业属于哪个课程 | 2021春软件工程实践|W班(福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 通过回顾，对自己这个阶段有更清楚的认识和总结 |
第一部分：课程的回顾与总结
《构建之法》问题回顾
- 问题链接
《构建之法》阅后疑问 - 问题解释与阐明
在之前的寒假作业中，对于《构建之法》中提到的相关内容，仅仅只是提出了自己的问题，经过了将近一个学期的项目学习，对于问题的理解也加深了不少。于此，为之前提到的问题做个简单的总结与回顾。
问题一：在开发过程中有时候是由自己全程开发，项目又较长，别人往往不情愿帮你审核代码，那自己该如何高效的复审自己的代码呢？
答：在大一大二编程语言学习中，项目的体量相对而言小了不少，因为大家都在做同样的作业，大家也都学了一样的C/C++等；所以代码的复审用一两餐拜托别人是可以做到的。
但是在真正的团队项目开发过程中，大家的技术栈不同，分配的任务不同，其他人也没有空来给你复审代码，所以复审的工作往往交由自己来完成，那应该如何高效的复审自己的代码呢？
在我自己开发过程中80%的代码复审，都来自于BUG的出现，但这种情况严格来说并不能被称为一种代码复审，所以对于代码复审来说，个人感觉最高效的方法就是列好一个checkList在每天commit之前过一遍，比如代码规范，效能，可读性等
问题二：感觉自己在开发的过程中特别容易陷入写了再改模式，文章提到RUP是方法的集大成者，但RUP的实现其实有点复杂，时间花销也是存在的。那RUP在什么程度的开发任务中值得做呢？
答：RUP是一个面向对象且基于网络的程序开发方法论，在实际开发过程中，小型项目例如我们的团队作业，是用不上如此规格化的模板，我觉得只要做好需求分析和系统设计就好了，采用原型模型来开发Web项目。
问题三：关于在章节8提到的需求分析，若不是定向面对需求的软件，该如何平衡需求和开发任务？
答：这题我感觉应该搞错了。。。。所有的软件不都是应该面对需求，通过需求分析来确定开发任务。
问题四：关于在章节13提到的软件测试，软件开发工程师应该自己测试吗？或者说该测试到哪一个程度？
答：经过了一个学期的学习，无论是软件质量与测试还是软件工程，都提到了测试的模块，作为一个优秀的软件工程师，不应该完完全全把测试交给专业的测试人员，基本的测试也是软件工程师应该要做的事情，基于自己的开发，我觉得开发人员至少应该做好单元测试，其中用例应该不仅仅只是普普通通几个，要学会测试软件的健壮性，注意测试用例的边缘性；在Web项目开发的过程中还应该做好对于Web接口的测试，因为经过了前端人员的测试再返回给后端人员修改会花费特别多点时间。
问题五:关于在章节6提到的敏捷流程，敏捷流程对团队的要求好像很高的样子，在参差不齐的团队中敏捷流程还能高效的发挥作用吗？是否可以理解为敏捷流程的执行是有前提要求的？
答：敏捷流程我将其总结为项目的快速迭代，技术能力参差不齐的团队里，敏捷流程仍然适用，可以取其适合团队的地方，比如每日例会，就算能力比较薄弱，但总能完成一些任务，进行版本的迭代。
各阶段收获
需求
需求阶段，主要运用的是分析能力，还有面对对象的建模能力，在此阶段主要是熟练学习了UML建模语言。
设计
设计阶段，我负责的是模块设计任务，模块设计的过程中加深了，对整个项目结构的理解，混合使用自底向上和自顶向下的设计适用此次比较小型的项目。
实现
在实现阶段，我运用的刚好是在本学期学的JAVAEE的技术，在软件工程开展的同时由于JAVAEE课程还没有跟上持久化框架Mybatis还没教，所以用的是网上学习的JPA（Java Persistence API），所以在编码过程中其实很想改成Mybatis，但是已经很难纠正了，所以在实现过程中，一定要先对准备使用的技术有个大体的了解，认真思考该技术的特性是否适用于此次项目，不然后期再改就来不及了。
测试
测试，在小型项目中，往往容易被忽略，在测试阶段，自己也只是简单的做了些单元测试和接口测试，其实这是远远不够的，并不能保证该模块的健壮性，所以今后的项目中还需要对测试部分加强关注。
发布
发布阶段，发布阶段主要是对调查用户的使用反馈，在此过程中，也是碰壁比较多的。所以在发布阶段还是得明确最主要面对的人群是哪些，面对那些人群再去定向投放调查问卷，我们做的是菜购（基于菜谱买菜），所以在校学生就不应该是我们的用户群体，所以在投放问卷的过程就比较困难，收集到的信息比较少，如果能够在父辈中老年纪推广开来，那将会明智许多。
心得体会
-
个人项目：自己是由于没有看清楚先决条件JDK版本导致，有一次WordCount直接编译失败0分处理。所以面对这种体量较小的任务，认真！认真！认真！反而比那些庞大的规划来的实在。今后的编程之路上，再次遇到一些限定外部条件任务，大抵会花上更多的心思来认真审题。
-
结对编程：结对编程的任务，其实是我第一次感觉到能够做出一个那种有实用意义的软件，自己完成的也不是很好，第一个缺陷是缺少了和同伴的交流，我们都是各做各的最后整合，经过了团队作业之后，真真切切的体会到了前后端一起写代码，能够提高多少的效率，能够减少多少的麻烦！所以第一结对过程沟通交流要摆在第一位；第二个缺陷是在最后的打包阶段，那时候时间太赶没有认真学习打包知识导致整个项目崩溃（POM文件消失，那些映射全没了，应该是Maven某个选项点错了），所以抗压能力也是我在结对编程中体会到的很重要的东西。
-
团队作业：这次软工实践的团队作业着实让我受益匪浅，无论是团队的交流啊还是个人的编程能力，其实一开始感觉项目任务分割有点不均衡，感觉自己分到的后端任务有点不平衡了，在Alpha阶段其实我拖了团队很大的后腿，因为数据库设计没有参与，对于数据库真的不熟悉，那个数据库让我弄得很痛苦（嵌套太多了）；Beta阶段算是调整好了心态，把Alpha落下的工作也补上了。总结来说，团队作业，让我体会到了团队的重要性，做事情一定要考虑到和你交接的上下游；其次要建立边开发边学习边积累的习惯，在以后的工作中，不断用到新技术的可能性很大，这时不应该学完用完就忘记了，应该有相应的积累。
第二部分：技术总结博客
因为在软工团队作业中用的技术都比较基础，所以选取开学规划的学习路线中的一个技术进行总结。
UE4角色体系——AI行为树
以上是关于在自我追责中超越的主要内容，如果未能解决你的问题，请参考以下文章