软工期末总结

0. 前言

  回想起这门课的第一节课时，一百多人挤在了一个只能容纳30多人的小教室里，之后又更换了大教室。老师介绍了这门课需要大家花费大量的时间，我现在回想起来，一方面是希望我们能重视这门课的项目经历并且真正从中学到东西；另一方面也是帮助我们筛选了队友，把一些想混学分的同学劝退了。而我当时也是想着毕竟研究生了，多学些东西总是好的，而且本科时期也有过很多次“被折磨”的经历，所以最终选择了这门课，并且也投入了较大的精力，也收获很多的认知和技术上的收获。

1. 整个过程的回顾

  在课程的前期，我们主要是学习了基本的软件工程的基本知识，各种UML图的绘制规范和一些样例的学习。并且分析了一些传统软件和现在软件的区别，我当时也是比较清闲，还阅读了格雷厄姆的《黑客与画家》，这本书至今都让我印象深刻，其中的许多段落也是常读常新。让我对于这些软件开发者的想法有了大概的轮廓。此外，也在网上学习了一些有关设计模式的知识，这是我从前从未接触过的，让我知道了软件开发绝不是代码的堆砌，有经验的工程师写出的代码应该是什么样子的，意识到了自己原来写的代码比较丑陋，也在以后的设计和编程过程中更加注意这一方面。
  在课程中期是我们自己项目的构思与讨论，起初我们想做一个Java程序的数据切面，追踪某个变量的变化过程，由哪些函数所影响。答辩时老师说这个需要考虑到各种值的传递和引用的传递，这是我们当时没考虑到的，经过课下的调研和讨论我们确实觉得这个方案不太可行，当时觉得比较失落，毕竟这个想法也是想了好久，再加上有几个队友也退课了，当时也萌生了退课的想法，但是回顾半个学期的努力，放弃了有点可惜，现在回想起了福楼拜的一句话“人的一生中最光辉的一天，并非是功成名就的那天，而是从悲壮与绝望中产生对人生的挑战，以勇敢迈向意志的那天。”
  在课程的最后时期，正所谓deadline是第一生产力。我们已经有了清晰的层次，完善和迭代起来速度很快，周二和周三都一起讨论并且完善功能直到12点多才回宿舍，周四一天也是查漏补缺，最终做到了我们都比较满意的结果。

2. 技术的收获

  通过本学期的学习，发现以前画的UML图大多讲究神似，并没有去细抠其中的细节。这门课老师带我们很仔细地梳理了每幅图的细节。比如在用例图时，用户一定要写具体，不能仅仅写一个软件使用者。而且同一个用户可能会以不同的身份来使用软件，比如可能在某门课上是学生，在另一门课上就是助教，所以不同用户的用例要区分开来。然后学习使用了starUML来绘制各种UML图，比如用例图、时序图、状态图、类图等。还学习了RUCM的使用规范，各种前置条件和后置条件是我们应该注意的
   其实，画这些图并不耽误时间，反而是帮助我们理清整个项目的规范，并方便我们与用户相交流，用户看到这些天可能很快就理解了我们要表达的意思，一幅图胜过千言万语。并且学习了Maven包管理的使用和Java parser的使用。
   并且，体会到了合作开发的问题和优点，有利于我们封装接口，方便他人使用的同时也提高了自己模块化的编程能力和交流沟通的能力。

3. 认知的收获

  由于之前写的东西都是比较小的项目，而且基本不需要多人协作开发，所以没有养成写注释和文档的习惯。但是自从软工的第一节课起就意识到了如今软件开发行业中文档的重要性，由于代码量大、开发人员多，规范地写注释就尤为重要。我们从前也是先写代码，写完比对着代码再写需求文档，这很容易导致开发出的功能不是用户真正需要的功能。而且每部分代码的功能可能会有一些重叠，项目的结构也不会很清晰。
   而且，文档最好写版本号，这样才能够看出我们的整个思想变化，增加了哪些东西，又删除了哪些东西，以及增删背后的原因。
   本次课程也写了不少的文档，发现了自己的语言表达能力存在很大不足。有时写完一句话，自己再读一遍都理解不了，通过前面的课程对自己的表达能力也是一种锻炼。
   需求不仅仅是给用户一个他没有的东西，而是能告诉他这个新东西能够给予他怎样的帮助，能够告诉用户how to do。这个对用户才是有意义的，因为即使我们有很多的东西展示给用户，但是用户自己都不知道能拿它来做什么，这需要我们进行挖掘、引导。
   举例来说，我们一开始认为生成一个类图对用户来说很有意义，但是我们没能讲清楚用户能用类图去做什么，这个类图能给用户带来什么样的帮助，能告诉用户how to do。这是我们所要去思考的地方。此外，按照我们讨论的想从一段代码中获取知识，最直观地当然是阅读注释，但是用户拿到这些注释之后又能做什么，对他有什么帮助，这都需要我们来把这个故事将清楚、讲明白。