进行一个软件工程的学
| 这个作业属于哪个课程 | 2021春软件工程实践 W班 (福州大学) |
| 这个作业要求在哪里 | |
| 这个作业的目标 | 回顾总结 |
| 其他参考文献 | 邹欣老师的博客园讲义 |
第一部分：课程回顾与总结
1、以前提的问题
2、奇怪的解答
*问：在4.6.2如何正确的给予反馈中提到：“评价别人有三种层次1.最外层：行为和后果 2.中间层：习惯和动机 3.最内层：本质和固有属性 同时也给出了妥当的处理方法——‘三明治’法”，我也赞同使用最外层来评价别人，减少攻击性语言，先认同，建议，最后鼓励。不过在实际的合作中，苦口婆心劝不动的人使用三明治法来评价效果不见得显著。在评价别人时情况可能会更复杂，是否需要要考虑人际关系，职位，情感，对方的个性问题等等，所以我表示疑惑。
*答：有时候绞尽脑汁地使用各种方法评价别人，在知道大致后果地情况下是无可非议地；但有的人不是那么好相处，还是不做评价为妙
*问：团队合作的模式中有“交响乐团模式”和“功能团队模式”，根据其描述个人认识这两种模式只是规模不同，前者更大一点，其他并没有什么不同却分出了两种模式？
*答：查阅自资料：功能团队模式优点：能够互相沟通，能够发挥自己的特长，缺点：团队人员的能力不一样，需要长时间 的磨合。交响乐团模式优点：各司其职，分工明确，需要强大的领导者，缺点：不能互相沟通，如果没有领导者，这个团队就不能运行。长期地磨合与进步中，每个人都有可能成为新的领导者。
*问：技术是创新的关键，技术真的是创新的关键吗？
*答：高新技术如果能迅速满足人们的需要，被人们迅速接受才能说明技术是创新的关键，但据我个人经验来看很难就此定义。查阅资料：创新的关键是人生观、价值观以及决定这些的社会环境与文化土壤。技术是创新的基石，还不至于是关键。
*问：“有人试图用‘re-work’（返工）来表示软件的质量”，个人认为只凭返工数来衡量开发质量缺乏合理性。
*答：在查阅的资料中是这样描述的：被广泛认可的衡量标准同时在教材中也有提到的是千行代码Bug率 =Bug数量/ (代码行数/1000)，千行代码Bug率数值越小质量越好。结合平时在开发中的经验，一个bug有可能引发其他bug，在调试的过程中有的bug不易修改有的就易如反掌，造成“返工”的时间差异，由此我想用平均返工时间+平均返工解决的bug数来衡量开发的质量会更合理点，开发质量=平均返工时间/平均返工解决的bug数，数值越小质量越高，这样做的缺点就是为了计算开发质量要做许多记录和大量计算，耗费了时间。
*问：“软件的不可见性和易变性会导致软件的依赖关系很难定义清楚，导致软件不易得到及时的维护和修复。”，我感觉文中所说的复杂的依赖关系不是导致软件不易得到及时维护的原因。也查不到有关资料来验证书中的说法，所以不太懂。
*答：在个人的开发经验中，使用多方的没有体系的依赖来开发软件不是一个聪明的选择，即使使用过多依赖，在维护时只需先更新所用的依赖，在按需维护即可。软件的不可见性和易变性不只会导致依赖关系很难定义清楚，更多的是重新阅读是难以理解，而后者才是维护困难的直接原因
3、做中学
需求分析阶段：学会使用NABCD模型分析需求
设计阶段：学会使用经典的设计方法设计系统
实现阶段：第一次开发游戏服务器，简单查阅有关资料后就开始着手做了，学会了先设计框架在完成各项功能，由大到小的开发流程
测试阶段：学会单元测试，继承测试，简单的系统测试；增强沟通能力，与伙伴一起分析错误报告，修改bug
发布阶段：无
4、理解与心得
对个人的编码能力有一定提高，养成良好的编程规范，初步了解团队合作的工作流程；但是，作业量过大失去了对细节的把控，没有将新技能很好的学会，只是单一的学会某个小功能就了事的，时间久了变会忘记。
第二部分：个人技术总结
