一、软件工程M1/M2总结

1、M1阶段总结：

　　我们团队的软件工程开发是按照前后端来分别开发的，我是负责后端的。我们的项目是做一个北航的社团平台，是一个网站。在后端我们使用的是ruby on rails。一开始对于ruby是没有什么经验的，因为之前没有过什么接触，之前只是接触过Python。刚开始的时候，我有去图书馆借书，不过后来发现书中的内容已经有些旧了，稍微有点过时了。后来在网上找了一些教程，以及一个叫做《Web开发敏捷之道_应用Rails进行敏捷Web开发》的PDF，然后才慢慢开始熟悉。我比较喜欢从整体去了解，然后再开始关注细节，所以在M1阶段我的开发进度是比较慢的，之前一直在学习整个工程构建，然后各个层次之间的关系等。之后就对于rails的体系有了一定的理解，然后才效率高了起来。在M1我们的进度总体上是很顺利的，没有遇到什么大的问题，整体项目的进程和我们的预想和安排基本一致。在第一轮，我们的整体项目是按照API文档来实现的，项目PM先拿出了一份简版的API文档设计，然后后端和前端分别按照API文档的设计开始实现。然后在我们都熟悉了这样的开发模式以后，设计API文档的工作就交给了后端补充，在一轮，我记得我大概是实现了设计到用户状态信息验证的部分API，以及活动名单等API的实现。总体而言，在一轮的收获，我觉得主要是这些吧：首先，单单从技术上来说，我学习并了解了ruby语言和rails，了解了什么是BS架构程序，什么是web开发。另外，我觉得我对于软件工程的敏捷开发有了一点点的理解吧，因为rails很方便地提供了一种敏捷开发的方式。不过我们的开发实际上不能完全算是敏捷开发，就是不能说我们是完全做到随时跟随需求改变程序然后就很快拿出来demo那种，我们的开发和敏捷开发是有一定区别的。不过对于rails的理解，对于我对敏捷开发的理解有许多帮助。

2、M2阶段总结：

在M2阶段，可能所有人都会提到就是任务量时间的安排吧。我当然也不例外...因为在M2阶段，说实话真的和M1比起来，学习到的知识上的东西并不是很多，主要的都是在学习如何应对各种各样的压力，各种各样的事情接踵而来，如何在这些事情权衡。对于软工来说，我觉得就是学习了如何在各种事情打断，对于你的节奏不连贯的情况下，调整自己的节奏来面对这种随时会被打断的情况。在M2的开始时候，我实际上是有转过去前端来帮忙，我自己也是希望能够学习了解更多的知识。在第一轮的时候我们就发现实际上前端压力远比后端大，所以第二轮的时候我们是认为应该对于前端更重视的，所以当时我们的设想就是从后端拿一个人去前端。然后刚好我有想学习前端的想法，我就转去前端了。在M2开发阶段，我们的第一周是用来学习第二轮用到的各种新的东西的。在我们最开始的设计中，M2开发中，前端会学习使用Vue.js和React的，后端是需要学习一下learncloud，还有对于rails服务器的模式的调整。然后我在这一周的时间是需要去了解前端开发的基本知识的，当时我一直在看html5，css等，当时的感觉就是，实在是太杂了。感觉看了那么多收获也不是很大，然后那两个框架我也看的不是很明白。那一周对我来说，收获是比较小的，也没有取得什么成果。然后这周过去我们正式开始准备开发以后，当时我们经过讨论，发现我们所面临的问题和我们之前的设想差的很远。因为在十二月，我们开发软工的这两周，需要面对数据库大作业，数据库答辩，数学建模大作业，编译实验等。这些东西全都挤在十二月，直接和我们的软工开发是凑在一起的。然后我们当时汇报之前一周的学习状况的时候，大家状况都不是很好，所以我们经过讨论还是沿用了第一轮的开发方式，就是还是按照原来的方式实现。然后我也就转回了后端，还是继续实现后端的功能。然后就正式开始开发，前两天我主要负责后端数据库的设计和API文档的设计。哦对了在第二轮我们相比于第一轮，还引入了github的成分。在M2阶段，我们的文档是以markdown然后发送到github项目的wiki中的。当然代码同步等等。然后当时那一周的开发还算比较连续，然后就开始断断续续了，尤其是编译的第一次测试，然后还有就是数据库大作业到了不能再拖的时候...软工当时的进度真的是断续的特别厉害，前端负责开发的一些同学实在是没办法继续下去，就是我们的PM还在继续开发前端的用户界面。当时那段时间过的比较艰苦，好吧其实一直到今天答辩之前，这一整段的时间我们过的都十分艰苦......软工的开发都是掺杂在这些考试和大作业deadline中的。中间也不知道刷过多少夜了。总的说起来，在M2轮的话，技术上的收获，可能就是对于github的使用了吧。对于git的clone，commit，branch操作，还有就是当时使用的时候造成了很大困扰的merge，这些都有了一定的了解。不过我还是觉得，这轮开发，最大的收获，还是在面对压力上的。就是这种苦熬的感觉，在面对各种事情接踵而来，感觉没有一个时候是头的感觉，但是还是得继续坚持的感觉，我觉得这种坚持对我来说是一个很有意义的经历。

二、《构建之法》阅读作业以及相关问题分析：

1、《构建之法》阅读作业链接：

http://www.cnblogs.com/wk1216123/p/4831004.html

2、理解的问题

关于代码维护的重要性：

当时的那个，说代码维护不重要，然后还不如推翻了重写的，是来自我们上个学期的一门课叫做oo，然后当时我们就是因为被各种注释和规范折磨的特别厉害，然后在一个论坛还是什么地方看到的，然后当时在对于代码注释和规范十分厌倦的时候，对于那个观点是比较支持的。不过经过这么多的开发，显然这个问题也没有什么好回答的，显然代码维护是十分重要的，代码的注释和规范对于一个项目的开发效率，尤其是多人合作的项目，影响当然是很大的。

关于团队中想法不统一造成效率低的问题：

其实说实话，现在再回头看当时的那些问题，很多都不是什么问题。好多都感觉可能是当时为了想出问题而想出的问题吧...就拿这个来说，团队中想法不统一是肯定存在的，不过我个人觉得这种情况是积极的。因为想法不统一，就说明大家对于问题都有自己的思考，这是一方面；另一方面，将这些想法都考虑清楚，然后再统一想法然后开始，对于整个项目的理解会有很大的帮助，然后也会利于少犯错误等等。当然，在一个团队中，每个成员都是要学会理解互相的，不能说性格很强，然后就持着自己的想法死不放手这样，还是要学会权衡和接受吧。

怎么样的软件是一个好的软件：

在现在看来，经过这段时间的开发，我觉得一个好的软件是会有这样的一些特点：功能强大，效率高，代价小。这三个我觉得都是很重要的，一个真正好的软件是肯定需要权衡各种因素，使得这三个都在一个很良好的位置上。然后如果再区分的话，个人会觉得功能会更重要一点。

3、仍然不理解的问题

关于如何衡量开发成本和收益的问题：

这个问题我觉得，我觉得主要问题在于，现在所学习的知识还是不够吧。个人觉得在有了一定开发经验的情况下，应该以比较妥当地判断出来开发成本吧。不过对于收益而言，就完全不是很明白了。我觉得还是得接触更多的知识才能解决这个问题吧。

关于客户要求如果是错误的，是否还是第一位的：

这个问题我不是很明白。我个人觉得，可能比较合适的做法是，尽量去和用户解释，然后说明情况，然后如果实在不行，还是得按照客户的要求来吧。不过我并不是很了解，因为我没有足够知识来理解客户要求的重要性到底到了什么地步。

三、8篇论文博客阅读作业及相关体会：

链接：http://www.cnblogs.com/wk1216123/p/4962653.html

　　对于银弹问题，我的理解和之前还是差不多吧，不过可能稍微有一点点的变动。我之前一直单方面地认为附加性问题的影响是要大于本质性问题的，不过后来我觉得本质问题和附加性问题，这两个之间是需要在一定程度上考量的。对于大量程序而言，就是不处于科研前沿的程序，就是只是平时的应用或者是平时这些普通应用而言，我觉得附加性问题的影响是要大于本质性问题的。但是对于科研前沿的问题，比如人工智能等等，在这些领域中，本质性问题当然是最难以解决的方面。所以，这两个概念，是要结合起来看的。我觉得在论文里面，作者所指出的情况，应当是指的是科研前沿而言的吧，所以站在作者角度，是会有这么个东西影响很大的，那就是本质性问题。

　　大泥球问题，在经过了软工两轮的开发，对于这个问题的理解和体会还是比较深的。在我们的项目中，大泥球问题是存在的，尤其在第一轮的代码中，一些大泥球问题延续了下来。一个最简单的例子，当时我们对于rails的render理解的不是很清楚，当时我们的理解是render和普通函数的return是一个意思，但是实际上这两个东西是完全不同的。render是一个方法，是去渲染一个返回的表单或者是其他成分，可以是页面等，然后实际上不是return。对于一个API是不可以渲染多次的，然后我们当时就将render理解成了return，然后就会可能导致多次渲染的问题。然后这个问题在第二轮的时候才被发现，当时我们在测试的时候发现一些API出现了两次渲染的问题，然后经过研究才发现了这个问题。但是这个错误已经随着一轮代码的四处拷贝复制等，已经到处都是了。然后改的很费劲。这只是一个简单的例子。我觉得对于大泥球问题，一方面我们需要提升自己的知识水平，对于很多错误需要能够识别，然后我们需要改变很多不良的代码习惯，就是要多考虑代码重用的问题。我在二轮的时候有注意这个，然后将很多我觉得会重复的方法都写成了代码块在一个主类中，然后在分类中就可以直接调用代码块达到目的。

　　关于大教堂问题，我觉得这个的话，我们还是会选择大教堂模式的。就拿我们现在的项目来说，我们中间有做实名认证功能，然后这个功能是在教务的支持下完成的。我们是通过token来控制调用另外的API实现的。如果这个token泄露了，那么教务的数据就会泄露了。而这个token是作为代码的一部分的，是不可以公开的。所以实际上，我们是不可能使用市集模式的。不过当然，市集模式和大教堂模式的区别本质当然不是指保密性，不过我觉得保密性实际上是我们应该考虑的部分。

关于开源，在我们的项目中是没有使用任何的开源项目或者别的开发框架的（就是指比如开发论坛，关注这样系统的框架等）我们当时的考虑就是，一方面我们希望能够自己手动来写，这样可以提升我们的能力。另一方面，如果使用了框架，项目就会受到框架的制约，对于项目的兼容，响应效率等，然后对于一个项目的上限，和今后开发都会有影响的。

　　关于简洁最好的话，没有太多特别的体会......

　　关于瀑布模型，我觉得其实在我们这个开发中并不是很合适的。因为很多情况下我们需要随时修改我们的设计，所以如果是瀑布模型的话，之前错了我们还要倒退回去，我觉得就不是很合适了

　　关于敏捷开发，比如我们的API文档是随时随着需求的变化而变化的，然后我们后端的实现就需要随着API文档的变化而变化。

　　软件工程的方法，我觉得是需要我们去体会的。对于软件工程的方法有了足够的了解，自然会起到一个引导的作用。