期末个人总结博客----（谢永青）

　　在写这篇博客之前，还是要感叹一下时光飞逝。不知不觉这一个学期已经结束了。

　　以前对软件工程的概念完全是模糊的，平常自己写了几百行的代码就已经思维混乱，一个工程怎么进行？对测试的理解仅限于从main函数开始，F10到函数结尾。在技术层面，以前的代码概念完全存在于循环,递归，怎么把一个数变成另外一个数而已。开发是一个遥远的名词。经过了这一学期，不能说自己懂得了太多，在结项答辩的问卷上，对各个能力的自我评价填上能够达到面试水平，还是诚惶诚恐。但是，起码我感觉自己也有了一些改变。

　　首先，就是对于整个课程的看法。到现在，我还是坚持一个观点，那就是同学们的技术水平离完成一个优秀的程序，差的有点远。邹欣老师强调“习而学”。对于大部分投入其中的同学来说，很多都是在跌跌撞撞，翻翻查查中进行的。对于没兴趣的同学，大多数也就是大个酱油吧。当然，如果把这个课放在大四，照样会有很多同学仍然技术不行。所以，这个观点只是我的一个感觉，并不是一个批评。我很感谢接触到这么多的大牛，接触到自己没接触过的技术点。虽然只是浅尝辄止，但是仍然拓展了眼界。课程的设计最棒的一点就是一定要让同学们做出来东西，并且发布出去。程序员估计是世上最苦逼，又最懒的生物了。你不去逼它，它会处于睡眠状态。让我们做出一个能发布的东西，很好。这门课，最让我头疼的一点就是pairWork了。虽然我不知道以后这种随机抽一个人一起编程的概率有多大。但是我可以说，起码我这学期的pairWork没有成功的，要么是partner是个大牛，抱一下大腿，或者自己写写。很少有两个人在一起编程的。究其原因，于我个人来说，是有推脱责任和偷懒的成分在里面。大家想的都是让对方写最好了。一个有趣的事情是，在shine或者codingCook团队里，大家基本上都是在pairWork，效率比一个人要高的多。为什么？因为每天都有一个daily Scrum在赶着我们写。每个人的责任都是明确的。你推脱不了的。我想，以后再pairWork的时候，能给我们一个责任分工或者说两个人中选一个负责人，效果会好得多。

　　然后，对我的团队合作经历谈谈感想吧。我前期是在CodingCook团队，后期转队到Shine团队。首先，两个队的工作风格完全不同。在分队的时候，大家就是靠着彼此的熟络程度和性情来组队的。因此，团队成员的个人风格也比较相似，起码，核心人物是这样的。CodingCook的核心人物是PM郭立轩，说他是这个队里的唯一牛人应该没人吐槽的。Shine团队的大牛好几个，但是因为各自有事，PM黄杨在推动着整个团队的运作。从团队的流程来看，Shine团队的design做得很不错了。CodingCook的design我个人在实现的时候，脑中总是一团迷雾，只有几个接口，实现的功能只是简单的框架。写完之后，没有一个明确的要求来检测我的结果时候能够“交货”。当然，Shine团队做的是一个游戏，个人的任务分的比较明确。CodingCook做的只是一个大项目的组成部分，条件差太多。但是，差距仍然是存在的。第二就是PM的个人风格。我一直不认为PM应该是一个好脾气的人。虽然郭立轩恰恰是这样的人。他可以把所有人的代码全部改一遍，然后自己干85%的活，但是这失去了团队的意义。虽然我认为是Shine团队的工作量太大导致黄杨没能包揽85%的活，但是PM要学会去push这个团队。第三点，整个团队的工作氛围。总的来说，CodingCook得到工作量比较小，工作氛围也比较轻松。所以我个人也偷了很多懒。Shine团队工作量很大，我个人能力一般。所以整个开发期间，我个人感觉气氛是比较紧张的。尤其到后期整个项目面临“跳票”的处境，让我感到有点沮丧。但是总体来讲都还不错。两个团队的成员工作我不做太多的评价，但是有一点让我很困惑就是测试人员去哪儿了？两个团队都有测试人员的责任分配，但是我很少在代码中见到他们留下的痕迹。两位大牛PM在每天深夜默默调bug。

总之，我认为一个团队能做到“各司其职”，这个团队就很成功了。

　　其次，对软件开发的感悟。首先，这门课让我了解到，软件开发是一个工程的含义。建筑，需要图纸，预案，资源准备，动工，检收等等。软件开发也一样。由于课程的价值取向，我们采用敏捷开发。敏捷开发的一个结果就是文档写的太少。文档绝对是个非常非常重要的东西。我现在努力培养我写注释的习惯。如果前期的设计文档写的更好，团队的结果应该也更好。再者就是对于测试。我一直再做自己代码的单元测试。在把自己的代码“交货”之前做好充分的测试应该是做dev的基本准则吧。做好单元测试会带来很多方便。M1阶段我在CodingCook团队，写出来的代码应该是一个标准的a big ball of mud。后来我转队了。但是一直在听PM说“我要改接口”。他们重新设计了接口和要求之后，应该开发的顺畅的多了。在Shine团队，M1的成果应该算是一个不错的初级demo，不能说是大泥球。在M2阶段，PM对团队的任务也重新进行了分配，任务和要求明确之后，工作效率也好了很多。但是，由于对工作量的估计不足，最后导致发布延迟。应该是一个教训。

　　总之，每个团队在M2开始后，都会有一个任务重新分配的过程。个人感觉这个过程就是在弥补敏捷开发造成的design阶段工作缺少带来的后果。以前我总是认为大泥球的造成是因为大家技术不行，但是，结束这门课之后，我感觉不是这样的。对于我们的项目，谷姐和度娘给出的资料足够满足我们的需求了。有效对项目进行划分，进行各组成的衔接才是避免大泥球的关键。

　　一学期结束了，整理一下自己。代码写了1000行左右，看了很多博客。阅读了邹老师布置的所有个人阅读作业。没有错过daily Scrum。压力有点大，但收获也不小。另外，感谢两位PM吧。很辛苦。