软件工程实践总结
软件工程实践总结
| 这个作业属于哪个课程 | 课程链接 |
| 这个作业要求在哪里 | 作业要求链接 |
| 这个作业的目标 | 对软件工程实践进行总结 |
| 其他参考文献 | ... |
目录
第一部分:课程回顾与总结
回顾自己列出的5到10个问题
- “我上班后，发现以前同事写的程序真是垃圾，根本看不懂，无法维护。我要推 翻重写！后来一个老员工笑嘻嘻地告诉我，我们现在看到的程序，就是去年的新员工愤怒地推翻重写之后的结果，大家反映还没有以前的版本好用呢。”相比重写，除了后期程序的大量维护有其他更好的方法吗？
软件缺陷会逐渐被发现，编写语言是更新换代的，软件的可维护性取决于该软件的设计模式，当软件难以维护的时候程序的重写会是更好的选择，当软件可维护的时候后期程序的维护量也不会增长过多。
- “具体步骤如下：1. 根据场景和开发任务来决定集成的次序 2. 互相依赖的任务要一起集成 3. 在测试场景时，要保证端到端的测试 4. 场景的所有者必须保证场景完全通过测试，然后把场景的状态改为“解决” 在集成代码的时候应该需要注意什么准备工作来避开代码冲突？
“功能分配中尽量不要有交集，功能区块分配尽量小，代码冲突容易发生在功能区块有交集的地方，应该把功能区块有较大交集的先合并，提交对产生的代码冲突选择正确的合并方法。
- “阿超：我好像有几天没有收到每日构建的报告了。小飞：已经有一阵子没成功了。 阿超：哦？我们上课的时候不是说过“每日构建”的重要性么？ 小飞：我同意在我们有时间的情况下，要做每日构建，但是工作一忙起来，我们的确没有时间去管构建的问题。”，有个疑惑“每日构建既然很重要，那对于我们学生平时应该注意强调每日构建吗？每日构建具体是什么？”每日构建意味着自动地，每天，完整地构建整个代码树，我们现在就应该养成每日构建的习惯吗？
构建（构建代码树是一个巨大的工程，构造整个代码树），开发过程中模块、文件的相对位置就不会混乱。但是目前写代码过程中经常会忽略。
- 除了利益因素以外，创新还应该坚持吗？这些‘过剩’的创新有价值吗？
创新的价值是看每个人的不同价值观而决定的，每个人的利益是不同的。在别人看起来没有利益可循的创新中，也许蕴含着巨大的价值。广信是需要被鼓励和坚持的，即使是‘过剩’的创新也是会有价值的。
- 我们主要注重自己专业方面的创新，平时不会注重其他领域的创新，那么在拿手领域外其他领域得到的创新跟该领域的基础又有什么关系呢？
在我看来，我们主要注重自己专业方面的创新，很少注重到其他领域的创新，并不是要成为领域内的专家才能创新，其他领域的创新可能延伸自自己专业方面领域的思考创新。
5个阶段，每个阶段收获最大的知识或能力是？
- 需求阶段
收获到的知识：在需求阶段，对我们而言我们要从用户的角度出发，用户想要什么，用户的使用体验，才是一个项目需求阶段最先要考虑的部分。 - 设计阶段
收获到的知识：设计阶段，原型设计尽量简单，功能尽可能覆盖，数据库设计对于之后代码的开发会比较简单。数据库设计阶段要考虑到之后开发需要用到的数据，通过将多个数据表关联起来，删除不需要用到的数据。 - 实现阶段
开发部分是业务逻辑层中的部分代码，提供前端界面所需要的接口所传递的数据，代码能力得到了锻炼。 - 测试阶段
使用JUnit，单元测试每个功能测试，集成测试功能并从中发现Bug并修复Bug。 - 发布阶段
通过调查问卷的反馈，通过用户的反馈来增加删除改进项目的功能。
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得
- 个人阶段
个人阶段，对于WordCount这个作业，用了PSP表格，加深了对Java语言的认识，对于命令行参数，文件io，同时也熟悉了使用Github来存放和更新自己的代码，接触了单元测试，在测试过程中能注意到自己在开发过程中疏忽的点，但是测试用例需要多加思考， - 结对编程
刚开始的时候，对作业的要求不是很理解，遇到了不少困难，但是有了队友的帮助，感觉解决困难的效率高了一倍，结对编程的过程中具体分工，除了完成自己的部分以外，互相帮助，通过沟通交流，做到了1+1>2。 - 团队项目
在整个团队项目的过程中，学习到了新知识并运用到开发的过程中收获许多，也获得了团队项目的经验，也有自己的技术不足导致效率不高的问题，还需要提高自己的代码水平，更了解了软件测试。
