[阅读作业]关于软件开发过程与方法

我们的项目已经开始了一段时间了,项目从无到有,作为项目的PM+dev，我也有许多感受。通过阅读一些关于软件开发过程和方法的文章，我学到了很多关于项目管理的知识。我认为我们与真正的软件开发人员有很大的不同，软件开发过程与方法也应该因人而异。

首先先简要说一下那些文章所介绍的内容。第一篇文章——no silver bullet（http://www.cs.umd.edu/class/spring2003/cmsc838p/General/NoSilverBullet.html），介绍了软件工程领域与其他领域有什么不同、为什么有这些不同：随着软件规模的增长，开发量不是线性增长而是指数增长，这让它不同于大多数的工程；软件领域没有什么规律可言，一切几乎都要通过实践领悟，这让它不同于大多数基础学科；软件的变化速度十分快，这让它不同于建筑等设计领域。随后该文章针对这些不同介绍了应该采取怎样的解决方法，如面向对象模型、敏捷开发等。

第二篇文章（http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf）介绍了一个非常典型的软件开发模型--瀑布模型，软件开发的各个部分像流水线一样被串在一起，人们依据这个流程图进行分工、安排任务、依次工作，与此相反的是不考虑各个工作的前后依赖关系。但是，瀑布模型听起来很美，但是往往不现实，于是我们有了敏捷开发。我们在整体上使用了瀑布模型，又在具体工作上借鉴了一些敏捷开发的方法。

然而，就算严格按照上面两篇文章所介绍的软件工程的原则去做，也不可能避免“大泥球”（ http://www.laputan.org/mud/）的存在。这主要是由于软件开发的特点而来的——复杂、更新速度快、高复用性而低耦合性，以及人类的懒惰。这样的泥球会随着需求的变化、组员的失误和能力上的缺失而越滚越大，直到把它扔掉重新来一遍。这样的泥球消失当且仅当软件开发人员有无穷的时间、无限的精力和无限的薪水，可以以一种艺术家的眼光对软件精益求精，尽可能的完善软件，而这在工程领域是极少出现的。

第四篇文章（http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar）指出了两种开源软件的类型——“教堂”和“菜市场”。一种是局限在少数权威人士之间的部分开源，一个是完全公开，人多力量大。这就像社会主义和资本主义谁更好一样，只有时间才能证明。

之后的第五篇文章（http://www.ituring.com.cn/article/9363）则讨论了上一篇文章，批判了菜市场的自由，肯定了教堂模型的开源。在现阶段，我也这么认为，并且现阶段的工业界也是这样：质量参差不齐的开源软件只能得到少数专业人士的青睐，大多数人选择了质量有所保障的框架或平台。如我们的项目采用的cocos2d-x框架，与微软的XNA框架对比，可以明显的发现后者的文档更加全面，架构更加合理。可能是由于互联网热潮导致目前的软件人员能力上的参差不齐，但是当未来软件开发到达了稳定期，人们之间的差距越来越小时，两者谁更好就不一定了。但是，在未来我认为菜市场会笑到最后，因为菜市场永远是最容易把握先机的，而教堂模型更容易保守、自大、腐败。只要有一个合理的规则，让菜市场井然有序，菜市场的前途不可限量。

最后一篇（http://martinfowler.com/articles/newMethodology.html）是关于敏捷开发的文章，其实我觉得敏捷开发没有传说中的那么神，它所描述的都是很显然的道理：沟通、简单、反馈、勇气、谦逊，多么美好的词汇！多么抽象的内容，正如斯巴达一样。我们都希望我们的开发变得敏捷，但是，事实总会告诉我们这有多难。事实上，敏捷开发确实是件很简单的事情。这在我们团队的合作上就可以体会：我与黄杨两个PM总会因为架构上的问题而争论不休（沟通）；我们通过把游戏拆分成几个耦合性弱的部分，建立好各自的程序框架和UML图分配给大家（简单）；我们每周都要开例会，统计所有组员的进展和安排并解决问题（反馈）；因为缺少C++和cocos2d-x经验，我一开始设计的架构正如屎一样（谦逊），直到现在也依然在对其进行改进和重构（勇气）。敏捷开发中最重要的原则中，一是保持高效率的工作，这要求所有人都要尽可能的做自己最有效率的工作。这其实对PM来讲是一个考验，如何分配任务、如何根据情况动态的对各个组员的任务进行变化，这对于之前没有合作经验的我们来说是一个问题。二是避免过度设计。过度设计会浪费很多时间，在重构上增大工作量，并且对未来的可伸缩性也影响不大，正确的做法是做出可实现当前需求的简单可依赖的可伸缩的代码。而这需要架构师大量的经验。

具体到我们的项目中来，我认为上面几篇文章中介绍的方法都不适合我们的实践。主要原因有两点：一是我们的能力都不够强，都没有很多软件开发的经验。这导致我们无法设计出高质量的框架，无法编写出高质量的代码。这样，许多已有的经验与理论在我们身上就要发生变化，我们只好勤能补拙。可是，更可怕的是第二点：我们只是学生，没有工资，没有合同，没有长期以来的合作，也没有足够的时间。没有工资和合同，组员们的动力就不会有在企业中的员工们那样大；合作很少，也就缺乏彼此的了解；不是全职员工，本来时间就少，再加上我们的能力有所欠缺，导致组员对项目的抵抗心理越来越强，更加不利于项目的发展。通过对组员们的观察，我深深的感受到了这一点。因此，所谓敏捷开发、极限编程等等方法，或许根本不适合我们。

那我们到底适合什么样的做法呢？我认为，若真要学习真正的软件工程，就要在真正的企业中得到锻炼。而且，若要得到真正的锻炼，那么首先基本功要扎实，实践要足够。所以，我认为应该在大四上软件工程课，并以在企业中实习的方式进行。当然，我们的项目依然有很重要的意义。它让我们提前感受到了软件工程的重要性，学习到了软件工程的一些方法，也大幅提升了我们的代码能力。