刚写完第二次结对编程的作业，也就意味着这学期的软工就算是结束了。到了现在，自己感觉很疲惫，不只是软工这门课造成的，这学期的后半学期，各种各样的作业，大作业小作业，大考试小考试……最终走到了这里。累，想要快点放假，但是我还有一个大作业……
前几学期，自己基本上是在荒废中度过来的，这学期开始，醒悟了，想要好好学习。做好自己应该做的事情。学期之初，通知我们班和另外的一个班的软工课是由邹老师来上的，感到挺高兴的，当时就是怀着满腔的热情一定要把这门课上好，可以第一周，软工课不上，第二周，邹老师有事出差，最终第三周，我们才算是见到了邹老师，挺兴奋的。更多的兴奋是听到这门课老师安排的各种各样的作业（这个是实话），因为以前都没有十分严格的这样的做过，按照老师的要求做下来，这学期的收获一定不少。
个人作业，结对作业，团队作业，还有各种各样的阅读作业，调查作业……做第一个编程作业的时候，要求做一个词频统计程序，当时挺兴奋的，周一布置了，大概周三的晚上大概就跑起来了，时间花得有点多，可能有的牛人用一两个小时就搞定了，但是我是一直尽力做下来的，很开心。后面又出现了很多状况，老师又明确了要求，中途又改了很多次，但是那种不断优化自己程序的快感还是挺好的，最开始统计一个200M左右的要两分钟，然后就是不断的提高，最终到几十秒。这个过程真的让人兴奋。这也应该要成为以后不断的追求。
接下来就是到了结对编程的作业，写一个电梯调度程序，老师给了框架，然后我们在框架的基础上只需要完成Scheduler就行了，当时最初拿到程序的时候不懂，也不知道怎么写，就去读整个框架，读下来还是不太明白。反正中间的过程就是一点一点的调，一点一点的改，最后在截止日期之前交上了程序。
接下来就轮到了团队作业，我们小组在游戏的时候很惨，倒数的成绩。所以，最终就没有了选择的权利，只能够做其他团队挑选剩下的工作。那就选到了什么作业就做什么作业吧。也就开始做这些作业了。
这里老师要求回顾以前读的教材、资料，解答一些自己曾经的一些疑问。
1、Cathedral model 和 Bazaar model，我们的软件工程作业适合采用哪一种模式，最终的团队作业的效果并不好。这两种模式对于我们的作业都还没有到可以使用的时候，我觉得一个软件工程的作品，至少要先将其原型做出来，然后才是这样那样的问题，很多时候，都很难再原型这一块做好，导致项目死掉。
2、曾经在一篇博客中提到Google的research和development工作和我们学好软件工程这门课没有太大的关系，其实并不是这样的，老师在我们学习的过程中一直在强调要做有用的软件，我们这学期的团队项目的目标决定的也是要做有用的软件，软件工程要用软件工程了理论知识来解决我们的实际问题，才是真正的软件工程。而像Google，微软……这些公司，他们的目标都是解决我们日常生活中面对的一些问题。所以，其实Google的工作，和我们学好软件工程有很大的关系的。
3、在M1阶段，我们组的工作造成了A BIG BALL OF MUD，为什么会造成这样的问题呢，首先有我们的需求理解得不到位，第二，我们想象了复杂的场景，而期待一个简单的解决方案。第三，团队分工不明确。这些都让M1的效果非常差。在M2阶段中，我觉得这个事显著改变了的，虽然还是一个大泥球。原因就是我们的那些问题都在一定程序上明确了，我们确定了我们要处理的具体的情况，缩小了范围，也划分清楚了每一个人的工作。这些都是提高的地方，但是我们团队的作用仍然没有更好地发挥出来。
接下来再说说我的要怎么学好这门课的观点吧：
现在国内很多学校的软件工程课都是一门偏理论的课，而这门课实际上应该是一门偏实践的课，理论学习，同时要将理论上的内容用到实际中来，然后通过实际来反思自己对于理论的理解。关键还是要做，多实践，多思考。既然这是一门软件工程的课，那么也就必须要按照软件工程中的一些流程来进行，比如要求项目要如期发布，那就要做到这一点。要求的scrum，也要按照这个scrum来，我们做的过程中国，虽然说是进行了scrum，但是有些时候并没有做好scrum。
很多时候，我们在抱怨这门课作业多，但是实际上，很多时候只是我们不想做事情，不积极做事情的借口罢了。
最后在这里感谢一下邹老师，谢谢。