个人阅读作业Week17
一、软件工程M1/M2总结
1.M1阶段个人总结
我们开发的项目是北航社团平台，主要是为了促进社团和学生之间相互信息的交流，为社团的管理和运营提供便利。相比于M2的收获而言，M1阶段中自己收获最大的就是对于网站后台搭建相关的知识和前后端交互的整个流程。在整个项目的开发中，我一直负责后端开发的，后端开发使用rails框架进行迭代开发，前后端之间通过API实现各自逻辑的分离。由于自己之前对网站方面的东西属于零基础，所以从ruby的语法，rails的MVC机制到Http请求的格式都是自己一点点通过查阅资料来学起的，在实现的过程中也遇到了各种各样的问题，最后一路走来，真的是对网站后台的搭建有了比较深刻的体会和一些经验。至于团队管理方面，我觉得我们一轮做的不是太好，团队管理工具仅仅使用了TFS这一种，后台的代码是由三个人一起负责编写的，我们并没有使用像github这样的源代码管理工具，完全是三个人各自写各自的，最后粘到一处。并且对于文档的编写和bug的记录也没有着重的重视，感觉这一部分是我们一轮迭代存在的很大的一部分不足。最后是成员之间的合作和冲突，主要是在后台一些API的设计和数据库的设计上，有时会存在一些分歧，而且又各持己见不愿让步，这种情况往往很令人沮丧，不过最终还是达成了统一的意见，感觉还是要相互理解和接受吧，你如果想说服别人认同你的观点，你必须先要学会倾听别人的想法，不要一味的否定他人的意见或想法，我们的团队应该是充满了讨论和不同的想法，但是这绝不仅仅是争吵，你必须要学会现听取别人的意见，这样的团队才会是高效而且向着正确的方向发展的。
2.M2阶段个人总结
M2阶段相比于M1阶段来说，主要是将一轮的一些功能进行完善，并且新增了站内信、评论、通知等内容。由于有了一轮的知识积累和实践经验，后端在代码的实现方面效率还不错，没有遇到什么棘手的问题。所以二轮阶段对于新的知识的获取方面并没有多少。我认为二轮阶段，自己收获最大的就是对团队管理和代码质量管理。由于一轮迭代的教训，我们在二轮迭代着重加强了团队管理和代码质量管理。在团队管理上我们使用github进行源代码的管理，并对文档和bug进行记录管理。每个人各自在自己的帐号编写代码，之后push到远程，由于大家可能会修改相同的文件，push的代码可能需要手动合并冲突，由于一开始冲突合并没有处理好，导致master分支上的代码合并后出现了错误，并且难以修改。后来采取大家各自在自己的分支上进行编写，当确认编写无误后再提交master分支，并且有一个总负责人负责对master分支的冲突合并。还有文档的编写，二轮编写的最重要的文档就是二轮API说明，该文档在整个组内是共享的，并且随时更新修改，保证对前端的支持。至于代码质量管理，我们进行了单元测试，黑盒测试，兼容性测试，并着重进行了压力测试，对于一个代码量上千行的项目而言，测试的重要性不言而喻，在二轮迭代的过程中，我充分体会到了这些测试的必要，对主要的测试种类有了详细的理解和掌握。个人收获的最后一点，就是抗压能力的增强，二轮迭代的时间和数据库，编译考试以及编译课设，数据库课设相重叠，到后期整个人都不好了，每晚刷夜的日子持续了好长时间，自己大学期间所有的刷夜都贡献给了大三上学期了，感觉越是时间紧张越要注重时间的规划和管理，由于前期进度的缓慢，导致最后几天的高强度，导致项目最终没有达到最理想的目标，我想这一失败的经历，也是对以后一定要重视时间管理和规划的教训吧。
经历了M1,M2的迭代开发过程，切切实实地把一个软件迭代开发应经历的各个阶段深深的实践和体会了一番，收获就不多说了。最后，我想最令我难忘的就是窝窝头这个团结友爱的大家庭吧，我们团队中的每个人都尽心尽力的去完成自己的任务，没有人故意不干活或者偷工减料，尤其是最后冲刺阶段，大家每晚通宵工作，前后端轮流作业，保证整个对接过程顺利的进行。我想一个好的软件产生的一个很重要的因素就是要有一个相互团结的开发团队，很幸运自己能在窝窝头团队和大家一起奋斗，写出令我们骄傲的产品。
二、阅读《构建之法》相关问题的理解和分析
1.《构建之法》阅读作业链接：
http://www.cnblogs.com/ericxuc/p/4830857.html
2.问题的理解：
- 关于满足需求和软件设计之间的关系：
一开始，在对北航社团平台进行需求分析，我们详细分析了社团在管理和发布活动的种种需求，如与用户的通信，收缴团费，社团创意商品的展示，为此我们设计了社团钱包，社团商城等。但是由于实现难度过大，开发时间较短，这些设计都被割除了。我们在一轮二轮迭代过程中，主要实现了社团和用户最主要需求的设计，如活动的发布和报名参加活动以及社员的管理。
在我看来，实现所有的需求是没有必要的，这既增加了实现难度，同时获得的效果的性价比不高。所以在软件设计时，应该去关心那些最主要的需求，把这一块作为重点去实现。至于那些次要的需求，可以在该轮迭代中不去考虑。另外，可以利用迭代开发的优点，将整个需求的设计分散到不同时段的迭代中。
- 关于团队开发模式的效率：
以迭代为核心的敏捷开发模式相比于瀑布模式效率更高，主要是敏捷开发能够主动接受需求变更，具有更好好的灵活性和可扩展性。我们的团队项目分为两轮迭代，每轮迭代发布一个新的版本，在迭代的过程中我们可以对之前的需求进行一些修改，对之前一些没有想好的设计进行完善。这些内容如果在一开始就全部做好，比较苦难，很多内容都是在之前的迭代过程中发现的。比如在一轮迭代时我们主要完成了活动发布和报名的功能，但之后发现作为一个社团平台，社员管理这一需求对于社团来言是十分重要的，所以我们在二轮迭代中注重加强了社团管理这一部分。
- 关于PM所需能力的重要程度排名：
PM的能力包括观察、理解和快速学习能力，分析管理能力，一定的专业能力，自省能力。我觉的作为一个PM最为重要的能力是分析管理能力，拿一轮迭代来说，一开始PM给大家建立好TFS后，要求每天自觉点TFS，并生成燃尽图。这样的无监督的管理，带来的结果就是，大家基本上因为忙别的事情，而把TFS忘记点了，或者是即使点了TFS，任务的完成情况也不知道如何，到最后发布的时候才发现进度太缓慢，只能连续冲刺好几个晚上以完成软件的发布。我觉得作为一个团队，一定要有一个人去监督每个人做什么事情，掌控整个项目的进度，PM对于这有着不可推卸的责任，如果仅以自觉去要求自己的项目成员，结果一定是不理想甚至是失败的。
如果编写的软件不能让用户满意，处理的方法有什么：
用户的需求是必须要满足的，我们不能去强行让用户的需求改变。就比如我们Aloha阶段发布的产品的用户反馈中，有些用户就反映活动报名后怎么不能退出啊，社团可不可以有导出名单的功能等，对于这些反馈我们都一一的记录了下来，并且添加到下一轮迭代开发的任务中去。
- 关于极限编程的利弊：
极限编程的优点就是效率比较高，代码编写和代码复审同时进行，可以在保证效率的同时保证代码的质量。缺点就是，极限编程如果你想达到好的效果对结对编程的两个人要求是比较高的。首先两个人必须合得来，相处融洽，还有就是两个人的技术水平最好达到一定的程度或者水平相近，不然极限编程并不会通告多少效率，甚至还不如你自己去写程序呢！
3.不理解的问题
- 开发成本和利益之间的关系：
因为团队项目的开发并不是一个盈利性的产品，没有什么利益可言。开发成本主要就是自己的课余时间，感觉这一部分的体验不是特别深刻。
三、软件工程论文和博客再体会
- 大泥球问题
二轮后端采用github管理源代码，整个后端代码，controller层代码量2200行，model层只有700行。可想而知，我们把大量的逻辑封装到了controller层中，而且存在大量的冗余。其实rails一开始希望的是我们能够把主要的逻辑封装到model层，使controller层尽可能的简洁，这样可以提高代码复用率，使程序结构更加清晰。但是，由于缺乏经验，我们在写代码的时候就直接在controll层中去写，需要什么API就对应写个方法，然后找一下和这个API功能相似的代码拷贝过来。这样使得程序的非常的冗长，而且可能会将原来存在的问题又复制到别处去了。这些大泥球，使我们在于前端做拼接的时候效率极低，比如前端测试一个API，发现不对，让我去后端看一下，我发现是别人写的API有问题，打算帮他修改下，可是阅读他的代码，我发现他的一些写法和自己的完全不一样，甚至非常复杂和麻烦，改起来非常费劲。我觉得在以后，一定要改变很多不良代码的习惯，重视代码的重用，把那些经常会使用的方法封装到模型（类）的内部，使外层的代码结构清晰简洁。
- Worse is Better，简单压倒一切
我们在二轮时设计过很多新的功能比如 论坛，社团钱包，商城，社团推荐，但是因为开发时间不足以及所需的学习成本比较高，这些设计最后都被去掉了。相反，我们注重去实现了通知系统和社团管理系统，只是我们权衡用户需求和设计复杂性的结果。我们将目光聚焦于用户最主要的需求，那就是和社团之间的一种信息的交流，所以之前提过的那些论坛，商城等设计并不是用户最为需要的，即使花费了很多精力去实现了这些功能，用户体验的提升也不是很大。
- 敏捷开发
在整个项目的开发阶段我们团队每周都会进行一次scrum meeting，冲刺阶段每天都会进行scrum meeting。这样的做法对团队成员的进度有着很好的监督作用，当别人说自己的任务已经全部完成了，而你却什么都没做，你会有什么感觉？另外scrum上都会讨论一些问题，讨论的结果是不断修正我们之前的一些设计和想法，使团队的开发向着正确的方向发展。
四、实践中的收获
需求
主要了解了获取用户需求的方法，并用NABC去分析
设计
设计阶段最重要的就是设计API接口，形成API文档。但是最重要的是，如果你后期做了一些修改，一定要同时修改发布的API文档，这是前后端之间永恒的坑啊！！！
实现
主要学习了rails各种组件的使用，和MVC机制的原理
测试
主要使用了单元测试，黑盒测试，兼容性测试，压力测试。其中压力测试和兼容性测试作为我们软件出口的条件。
发布
发布一定得是一个正确的版本，经过了各种测试，发布不要趁早，如果为了时间，发布了一个有问题的版本，对于用户的推广无疑是灾难性的。一定要确保没有重大缺陷，再发布。
维护
要及时处理用户反馈的BUG
