一轮迭代总结

一轮迭代总结

所在团队：窝窝头（团队博客地址http://www.cnblogs.com/wowotoubuaa）

开发项目：web端的北航社团服务网站（网站地址http://www.buaaclubs.com/）

团队人员：江昊（PM）、杨墨犁（前端开发人员）、王若愚（前端开发人员）、付帅（前端开发人员）、王春阳（后端开发人员）、徐丞（后端开发人员）、王开（后端开发人员）。

　　我们团队项目一轮迭代历时一个月，开发出了网站项目的v1.0版本。这一个月的开发时间，算是让我有些体验到了什么是团队开发软件，这与以前自己随便写一个几百行的小程序是完全不同的概念。现在一轮迭代结束，就此结合一些软件工程中的理论，对整个过程进行一个反思。

一、开发流程：敏捷开发流程。

　　课程要求我们采用敏捷开发流程，要有scrum meeting、burning down 图这些东西。我也从老师给的资料当中了解到了另一种开发过程，即所谓的瀑布模型。下面先说说我理解的二者的区别。

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护六个几本阶段，这六个阶段并不是一个线性的关系，他们相互构成一个环形的形状，每一个新的循环意味着下一轮迭代工作的开始。对于瀑布模型而言，软件的开发过程是严格按照上述给定的六个顺序一一向下执行的，并且，为了保证早期的工作中的错误不至于影响后期的工作，在每一阶段的结束都要进行严格的审查和测试，如果发现大的缺陷，就要修改这一阶段甚至上一阶段的工作直至合格为止。这样做的好处是每一阶段开始时都可以假定之前的工作都已圆满完成，但缺点是在每一阶段都会产生大量的冗长的文档，并且团队很有可能会在一个并不是那么重要的功能的设计实现上纠缠不清而大大拖慢了项目的进程。这里引用Richard Gabriel的一句经典名言：“worse is better”。他的意思是一般意义上衡量软件好坏的标准是简单性、一致性、正确性和完整性，但并非是要求每一个软件项目的开发都要严格地按照这个标准来执行。软件本质的作用是满足用户的需求，可能我们花了很大的精力去实现一个用户几乎不会用到的功能，从而延缓了项目开发进度和发布时间。为什么不考虑搁置一些不常用的功能，或者容许在某个阶段出现的一些小bug，尽快发布软件的测试版本，让用户试用软件，给出更明确的改进建议呢？这种折衷的方法也许会比教条式的瀑布模型更灵活。

　　再来说说敏捷开发流程。敏捷开发流程在形式上讲有product backlog、sprint backlog、sprint、scrum meeting、burning down 这样一大堆的东西，但我理解的敏捷开发的本质是边干边改、充分交流、制定短期计划、与时俱进。一个项目的用户需求难以做到在开发过程中不发生改变，因此，团队先针对已经分析出的用户的主要的设计需求进行设计和实现，同时密切关注市场和用户需求，随时进行计划调整，计划也不制定得太长，往往就是一个迭代周期制定一份计划。在团队内部，各个模块负责人之间遇到问题随时交流，同时每个版本发布后耐心听取用户的改进意见，修改自己的软件目标。听起来很高大上的样子，我所知道的MIUI系统就是几乎每周都会有微更新，同时所有的小米粉丝一起来对系统提出意见，这个系统就越做越好，可以算作敏捷开发的一个成功案例吧。

　　总结起来，瀑布开发流程更强调计划性，而敏捷开发流程更强调变化性。我们小组的人员不算多，采用敏捷开发流程似乎更为合理。即便如此，我们在开发过程中还是遇到了不少问题。

　　网页的前后端用的技术完全不同，前端主要使用css布局和javascript实现动态展示，而后端主要使用ruby on rails 和 mysql来实现数据管理，二者之间通过http协议进行传输。由于我们小组的成员之前都没有web开发的经验，所以出现的情况就是前端对后端一窍不通，后端对前端的也如此。好在PM有一些开发经验，但是一些技术细节他也不甚了解。因此，前后端交互的API文档就几乎成了我们唯一能够参考的手册。但是这个手册说实话还是不甚详细，每个接口没有给出交互样例，具体传来的XML格式的文件怎么解析也没有一个统一的标准，怎么办？只能一遍一遍地QQ上交流或者直接去对方宿舍问。我中间有一段时间为此还比较抱怨因为API设计不规范花去了不少调试修改代码的时间。其实我觉得，虽然敏捷开发流程鼓励团队成员交流，但是这并不代表我们不需要一点规范，就比如我可以随便取一个谁也看不懂的变量名来写程序，这样无形之中给其他的团队成员增加了负担。

　　另外一点，关于burning down 图的问题我们也是做得比较形式化。在起初我们对整个项目一无所知的时候，要让我们清楚地知道有哪些具体任务来完成无疑是十分困难的。因此，我们设计的分配给每个人的任务也是非常的抽象和概念化的东西，所以我们每天做完了自己的一些开发工作后发现不知道该更新哪些任务。但是我们每周都有一次团队例会，会总结上周的任务完成情况，同时前后端交流技术难题，然后规定本周的任务目标，现在看来都是保质保量地完成了任务，我觉得在二轮迭代的时候，这个情况会有所改善。

　　综合起来，我觉得敏捷开发流程和瀑布开发流程各有优缺点，不妨把二者结合互补，根据自己的具体情况来进行选择。

二、关于开源框架的使用问题

　　后端的情况我不甚清楚，在前端的开发过程中，我们早期自己利用HTML和CSS画出来的界面要多丑有多丑，完全上不了台面，后来PM说可以利用一个开源的semantic UI 框架来设计，我们于是推翻之前的布局，直接利用现成的框架来构建界面，的确好看得多。还有一点，由于我们需要建立用户数据库，因此要涉及到md5加密的问题，这个也是直接从网上找到一份javascript代码直接copy过来使用的。

　　这样看来，如果没有这些开源框架，我们无疑要在很多技术难关上花费大量的时间。以我现在的看法，我觉得开放模式（集市模式）比起封闭模式（大教堂模式），更适应当今软件工程发展的需要。Poul-Henning Kamp的吐槽也不是没有道理：如果一个软件的维护者是一群散乱没有组织的程序员，他们各自不需要为这个软件负责，可以随意修改，那么这个软件到了后面就没有一个统一的规范。想起google刚刚发布andriod意图与ios一拼高低的时候，也是想借助大众的力量来提高andriod的开发周期，然而到了现在，基于andriod定制的ROM五花八门，导致andriod应用的开发者不得不为适配工作花去大量的时间。

　　我现今只是开放模式下代码的使用者，并没有从事代码维护更新的工作，Poul-Henning Kamp提出的缺点我没有遇到过，我关心的就是我得到的源码能否正确地实现其给出的接口，至于其内部结构，我不去关心。我想像我这样的人应该不在少数，他们对开源框架的需求是很大的，这种模式对整个行业都是很有益处的。

　　关于Poul-Henning Kamp的吐槽问题，我觉得不妨由一个公司专门来管理代码，代码开放，所有人都可以进行复制修改，但是要上传到公司的源码服务器并在下一个版本得以发布，必须进过严格的代码审核，满足公司制定的代码规范才可以通过。这样就可以解决无人对代码负责的问题。

三、一轮迭代后发现的问题

　　一轮迭代结束后，我们软件的规模大约是4700行代码量。我负责前端一部分代码实现，在读代码的过程中发现一个重大的问题就是代码结构化很差，有些可以用循环实现布局的东西非要展开来写，而且js代码散乱在各个地方，不停地用ctrl + F 搜索代码，这给开发过程带来了极大的难度。而且，一个结构化不明晰的代码带来的危害就是“大泥球效应”，代码越来越不规范，维护工作量越来越大。

　　为什么会这样的情况？我觉得问题在于我们编程时仅仅考虑局部的功能实现，而没有考虑全局的软件架构问题。就我们的网页开发项目来说，我们要实现十多个API，我的做法就是依次挨个实现，在原来的代码上小修小补，然后不断调试修改查看效果，直到功能被实现，就着手下一个功能。在这个过程中我会遇到的问题是：在实现后面的功能时，发现前面实现的功能代码中有部分代码可以拿出来重用，但我懒得再把他们封装成一个函数，直接复制粘贴过来完事，心想反正功能做出来就行。这样导致我最后读代码发现如果进行精简，可以缩短百分之四十的代码量。而简洁明了的代码会大大减轻调试负担。

　　为此，我觉得在我们二轮迭代启动之前，有必要整理一下代码，把独立的js代码封装成一个文件，每个文件专注于自己的功能。

四、整体总结感想

　　结合整个一轮迭代的开发，我对Frederick P. Brooks, Jr. 所讲的软件开发的困难有了一定的理解，现在结合项目开发过程谈谈看法。 

　　《No Silver Bullet》这篇文章首先是介绍了软件工程要面临的固有的不可避免的问题，主要是复杂性（complexity），软件整合（conformity），可变性（changeability）和不可见性（invisibility）。我们开发的这个web软件有一些必要功能和一些可选功能，开发过程上前后端完全分离。这样给我们带来的难度主要是软件整合和可变性方面的。不仅前端和后端之间的软件整合有困难，前端各个页面之间的跳转和数据共享也是一大难题。而由于在开发过程中需要根据实际情况砍去和加上一些功能，这也给开发带来了难度。

　　除了这些困难，PM给我们提供了一些好的web开发工具，比如dreamweaver8、filezilla，这些可视化的开发工具避免我们去学一些命令，可以把精力专注在与项目有关的开发上，这也算是一个“银弹”吧。

　　要说软件工程方法论究竟有什么作用？我回想我们一个月的开发过程，这些方法论无形之中渗透到我们每一次开会，设计每一个界面，写每一行代码当中。可能这些概念性的东西对我们这些实战经验较少的本科生来说还是理解得不是很透彻，但是我们的确从这些方法论所衍生出来的具体方法的操作上或收获经验、或吸取教训，这对我们成为一个优秀的程序猿还是很有帮助的。