提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | |
| 这个作业要求在哪里 | |
| 我在这个课程的目标是 | 学习并掌握利用软件工程的思想与方法构建大规模高质量的软件系统的能力\团队协作能力等 |
| 这个作业在哪个具体方面 帮助我实现目标 | 温故而知新，总结本课程的收获 |
一、提问回顾
在学期初，我写下了一篇关于构建之法的
-
Bug or feature
现在回顾之前的问题，我觉得这个问题没有必要过多地讨论和深究。
It's Not a Bug,It's a Feature，具体起源或许没人能知道。这句话虽然曾经是程序员的行话，但如今可以适用于各个领域。通常意义上来说，这个问题是开放式的，带有哲学意味的，不局限于软件行业；而从技术领域来看，对待bug的态度应该是尽量在软件开发和测试的过程修复，而不是等到产品发布之后，无奈而又调侃地说一句It's Not a Bug,It's a Feature. -
单元测试必须由最熟悉代码的人（程序作者）编写吗？
单元测试必须由最熟悉代码的人（程序的作者）来写．代码的作者最了解代码的目的，特点和实现的局限性． ——《构建之法》
经历了团队项目的实践，我对于这个问题的认知有很大的变化。
当时我认为，做好单元测试很重要，最好由他人（而不是程序的作者）编写，因为这样做能在测试的时候尽量做到客观和理性。
但现在我的想法是完全赞同《构建之法》作者的观点。在小型项目中，项目代码量较少，由他人负责单元测试的成本不是很高，这个时候无论是程序的作者还是他人，编写单元测试我认为问题不大。但对于一个大型团队项目，如果由不熟悉代码的人进行单元测试，由于代码规模很大，重新熟悉代码的成本过高，测试需要额外花费大量时间和精力。而对于一个快速开发的项目来说，时间是最宝贵的。另外，由最熟悉代码的人员进行单元测试，由于代码已经具备一定的复杂度和规模，作者不太会局限于之前的思维定势
因为之前写的细节都已经不记得了,所以不用担心作者编写单元测试会忽略很多bug的问题。事实上，在团队项目中，我们都是负责自己代码的单元测试。
-
结对编程的实用性和搭档的选择
在结对编程的模式下,一对程序员肩并肩,平等地,互补地进行开发工作.他们并排坐在一台电脑前, 面对同一个显示器,使用同一个键盘,同一个鼠标一起工作.他们一起分析,一起设计,一起写测试用例,一起编码,一起做单元测试,一起做集成测试,一起写文档,等等.
——《构建之法》
我的想法和之前一致。我认为结对编程对结对人员素质要求极高，并且敏捷开发要求快速产出MVP，而结对编程让两个人做同一份工作，在现实生活中结对编程很难有实际应用场景。
-
如果你是病人，你希望你的医生是下面哪一种呢？
作为一个软件工程师, 你觉得自己表现如何? 有没有这样的体会:
看书的时候觉得“技止此耳”，开发项目的时候才觉得实际情况和书上讲的都有一些出入，一些重要的细节书上没有提。我们很多人是边看asp.net的书, 边开发asp.net 的项目，这相当于一边看医学书一边动手术……如果你是病人，你希望你的医生是下面的哪一种呢？
a）刚刚在书上看到你的病例，开刀的过程中非常认真严谨，时不时还要停下来翻书看看……
b）富有创新意识，开刀时突然想到一个新技术、新的刀法，然后马上在你身上试验……
c）已经处理过很多类似的病例，可以一边给你开刀，一边和护士聊天说昨天晚上的《非诚勿扰》花絮……
d）此医生无正式文凭或正式医院的认证，但是号称有秘方，可治百病。
事实上，很多软件项目就是用a）或者b）这样的方法搞出来的。当然 也有一些人走d）这条路。
——《构建之法》第三章
这个问题我的看法也与之前一致。但现在有了新的想法。我认为与其将医生划分为abcd，不如将手术分类：a) 需要边翻书边开刀的手术，对应于需要边学边做的项目 b) 冷不丁实践新技术的项目 c）驾轻就熟没有任何难度的手术 d) 宣称能按时完成，但无任何具体计划的项目
我认为作为一个软件开发者，我们需要多做做a手术，私下练功夫时做做b手术，争取让c这样的手术越来越多，这样做手术时才能越来越胸有成竹。也就是说，完全没有难度的项目没有挑战性，对个人的成长帮助不大；在团队项目的过程中，最好不要临时改变技术，这会给团队带来麻烦，建议私下尝试。
-
在校学生如何为成为一个PM做准备？
你是否觉得你的长处不在于写代码和debug，而是协调、沟通，让一个团队或组织有效运转起来？你是否喜欢表达，善于和各种专业背景的人沟通？你是否经常思考如何该井生活中点点滴滴的小问题？你是否会思考这样的问题么：新浪微博、豆瓣、qq、微信都可以社交，它们的定位、产品特性、用户群、解决的需求，有什么不同？你是否对以下领域感兴趣，甚至自己找过相关的书来看：心理学、社会学、组织行为学、统计学、商业模式？
当时对这个问题颇有疑惑，如何成为产品经理，以及大学里是否有对应的专业和培养方案。
参与了团队项目、参与软工讲座以及这学期的生活经历让我对PM这个职业有了进一步的认识。我认为产品经理这个职业在大学里是没有专门的培养方案，也找不到对应的专业。从某互联网公司对产品经历的招聘也能看出来，这个职业对专业没有太大限制。
从团队项目的实践来看，合格的产品经理需要具备良好的管理能力（计划、组织、领导、控制）；具备人际交流能力，能与团队成员进行沟通交流，推动项目进展；具备设计概念图、进行需求分析的能力，能使用相关设计工具、对相关行业/产业/产品/用户需求有深入独到的了解。
虽然产品经理对专业没有太多限制，但我认为计算机相关专业、工业设计、数学专业、经济学相关专业都有成为产品经理的优势和潜力，当然成为优秀的产品经理，更重要的是个人能力的培养。
新的问题与思考
在团队项目工作分配时，我选择了爬虫和数据库存储的工作。在此之前我对软件开发没有什么经验，团队选型的技术也是我当时不掌握的。于是我考虑了我对数据分析有所经验，并对爬虫工作有信心，做出了这个选择。事实证明，虽然开发过程碰到了一些困难，从结果来看，我的工作完成得还不错。
可惜的是，由于爬虫可以作为项目中相对独立的模块，在实际运行中也是作为一个单独的进程常驻后台。虽然负责爬虫模块的开发让我学习到了很多爬取数据的知识和技术，但由于时间和精力，我没有深入地参与到”传统的前后端工作“中。
在团队项目中，个人应该如何选择或者接受团队的工作分配？是选择有利于自身成长、最具挑战性的工作、还是有利于团队、有把握的完成的工作，这个问题我在某段时间总是会思考。经过一番思考，我认为应该以集体利益为核心，选择后者。对技术栈的扩展还是放在个人项目里吧。
二、在实践中学习
罗杰、任健老师的软件工程课程内容丰富，在”做中学“的过程中，我学习到了一些知识和经验。
-
需求阶段
实践证明NABCD分析是一种非常有效的需求分析手段。NABCD模型从Need-Approach-Benefit–Competitors-Delivery/Data五个维度刻画需求，能让立项时的需求变得很清晰。
-
设计
设计阶段的工作涉及到方方面面，包括软件总体架构设计、功能详细设计、数据库和API接口设计、界面设计等。在实践中我学会综合运用很多设计工具，如UML（划分模块、模块功能）、原型图设计（界面设计）、E-R图（数据库设计）等等。
-
实现
在开发阶段，定期召开简短的例会并总结非常必要。定期例会以及分配计划阶段划分好的issues，能够有效推动项目顺利开展。值得注意的是，例会时间不宜过长，应该将大部分精力放在开发上，周期以1day或2days为宜，在例会上应该总结一个周期内完成的工作并计划下一周期的工作，最后就遇到的问题进行讨论；计划的isssues可以结合实际情况动态调整，但一定要全力保证每一个周期都有任务完成，这样才能保证在规定的开发时间内圆满完成项目。
scrum meeting在项目管理上给我很多帮助和启发，我相信我会将它运用到之后的项目开发中。 -
测试
测试的工作应该从项目开始时就考虑。CI的部署在项目开始就完成，必要的单元测试随着代码的编写完成；在开发工作结束后，应该进行压力测试和性能测试。
-
发布
项目开发完成不是项目的结束，对于一个项目来说，有效且多样化的宣传才能实现对用户的有效交付。
-
维护
项目发布之后，我们需要对软件进行日常维护，包括运营、修复bug、版本更新。在宣发的时候就应该考虑到如何有效收集用户反馈的问题。
三、个人小结
过去了，软件工程课程即将正式落下帷幕。这一学期，我经历了一个结对编程项目，两个阶段的团队项目，参与完成了14篇博客，在软件工程课程上投入了很大的精力，也有不少收获。
罗杰、任健老师的软件工程课程相对于其他平行班来说，任务量很大。一个学期的课程安排非常紧凑，前期有博客和调研，接着是结对编程的三个阶段、团队项目的两个阶段，中间还经历了一次转会。而其他平行班的同学，只有团队项目的开发，我想凡是认真完成罗杰、任健老师的软件工程课程作业的同学，都会”收获满满“吧。
在前期撰写博客、调研的过程中，我阅读了大量文章(
结对编程阶段，经历了痛苦的三个阶段。老实说，我认为这一阶段在软工开发中有点不合时宜。一方面我对结对编程这种形式我也很难认同（前文已经提及），而另一方面结对编程布置的任务给我的感觉更像是OO的课程作业。私以为软件工程课程的核心思想是敏捷开发，要求在较短时间内开发出一个最小可行产品出来，而结对编程作业的形式沿袭了OO课程，以AK为导向，布置的作业也与OO的风格很像。以AK为导向的课程作业不可避免要求同学们追求细枝末节上的完美，但课程作业又有不少纰漏，这导致同学们在对需求文档咬文嚼字上以及测试极端数据上需要花费大量的时间。而这与敏捷开发的思想是有冲突的。在这一阶段，我的最大收获或许是如何快速开发一个程序吧（但这一收获我在OO已经学到了）。
团队项目阶段是我收获最多的阶段。通过与团队成员长达两个月的合作，我们完成了一个尚有缺点、但总体完成度很高的项目！而开发过程中十几次的例会、十几篇博客、宣传文案、宣传视频也都是很有意义的产物！在爬虫方面我学习到了很多有用的知识和技术，更重要的是通过参与整个项目的开发，我对软工开发的流程有了整体的认知和宏观的把握，这对我以后的软件开发来说是非常宝贵的经验。这个项目，凝结了团队所有成员的心血，也凝结了我的心血，我可以很自豪地将它写进我的简历啦。通过两个月的团队项目开发，我结识了五位小伙伴，收获了宝贵的友谊。回顾当初的团队自我介绍，现在来看我在这个团队中许下的期许都得到了满足。
