看了几篇与软件工程的瀑布、大泥球、教堂、集市和银弹等概念相关的经典文章，简单的谈一下自己的一些理解。
一、银弹
从自然法则上来说，我不相信银弹不会出现。或许银弹的发现会是软件工程发展的分水岭，只是不知道会不会到来，什么时候会到来。
这篇文章存在也不是一年两年了，而文章所提出的问题却还是没有得到根本性的改变。在做了这几次简单的只算得上编程而称不上软件项目的作业后，感触尤为深刻。
作者首先提出一个问题：软件开发技术的落后是由于存在软硬件发展的不协调和畸形。软件的发展远跟不上硬件。一开始看这个问题的时候，是存有质疑的。苹果一面世，就有大量的优秀的软件硬性地或间接地植入系统，在前不久苹果开发者大会（2014年6月2日）上，苹果马不停蹄的上马Swift编程语言，用于搭建寄语苹果平台的应用程序。这速度不算慢吧。但是后来想想，又不是那么回事。
软件的诞生往往是落后于硬件的。有幸在isense登陆中国之前就见识到了这个可以附在ipad上使用的3D扫描仪。其开发公司 3D Systems公司在推出这款扫描仪的同时也配备了很多软件，但是也只是公司自己说的而已，用起来却并不如此，扫描并不稳定，成像并不精确，图像处理完全属于初级阶段。当然这些问题可能会包含硬件本身的一些问题看，但是从用户体验上来看，这很大一部分要归咎于其软件系统及配套的各种软件功能。在软硬件畸形这个问题上，体现最明显的就是这种具有开创性的硬件的发展了。
复杂度，一致性，可变性和不可见性是现代软件系统中无法规避的内在特性，正因为说是特性，就意味着这是现代软件系统天生的残缺。
如果把软件当做一个实体，那我也想不到它可以扩展出多少个子实体了，而每个实体之间的联系，每个实体本身的属性又都是异常复杂的。一个老师所谓的谈不上软件项目的程序作业——电梯调度，其中的各种状态之间的转换就让人晕头转向，常常是顾此而失彼，要想得到一个能够较为理想的程序实现需要做大量的论证工作。而且大多数情况都不是最优的。在这次结对编程项目中，也正因为是复杂度的存在，使得与同伴在交流的时候出现许多分歧和不理解，尤其是最开始的设计阶段，完全不能十分清楚地理解对方的程序，不一样的代码风格造成了项目初期的低效率发展，直到慢慢融合才使得效率开始提高起来。
而软件的一致性和可变性也是一个十分令人头疼的事情。没有一款软件在推出以后就永远保持它最初的样子，总会有alpha版，beta版，beta.1版等等。或许只有同时用过Python2.x和Python3.x的程序员才能明白有的时候软件项目就是一个充满了分岔路的羊肠小道，而可变性就在于你走得越远，分岔路愈多，而过多的选择并不是好事。Ubuntu的各个版本则说明，对软件的任何再设计，都会直接影响接口实现问题。
增量开发，作者在这篇文章中谈到是银弹的希望。我没有足够的见识和实践能力去判别这个问题的答案，只是就我们这次团队项目谈谈自己的看法。
一个MOOC的项目，要在Android客户端实现，而基础是Mac版的MOOC 实现。不知道我的理解是否正确，这可不可以算得上是一个横向的增量开发。头痛的是编译环境和实现过程截然不同，令人好受的是这不是一个开创性的课题。现在还只是Alpha阶段，只能想办法帮助原先的项目适应新的家庭环境，这其实是一个关于软件系统多样性的问题，而Beta版就要实现他的自我保护和自我更新能力的发展。
当然希望我们团队在最开始设计这个项目的运行轨迹的时候就是正确的。
二、大泥球
大泥球，在软件项目中指的就是一堆杂乱无章的代码。可读性差，可移植性差，可增生性也差，封装效果不好。这样的代码会大大地降低测试人员的效率，更不利于程序的修改和更新，往往会形成牵一发而动全身的后果，一处修改就可能影响到整个程序的实现。
为什么会出现大泥球呢？文章作者指出，一次性代码最有可能形成大泥球。由于是一次性代码，开发者或项目负责人不需要对项目以后的发展进行过多的考虑，只需要实现它现在的功能就行了。但是往往是这种不负责的态度影响了程序结构的合理化设计。要想解决这个问题，就要求项目组的每一位成员养成好的项目开发习惯。在一开始就明确清晰的程序结构，提出合理的算法，为代码的移植和增发做好最充足的准备。
三、The Cathedral and the Bazaar
在90年代末，Eric S. Raymond发表了《大教堂和集市（The Cathedral and the Bazaar）》，说服网景开放源代码。大教堂和集市是开源的两种形式，前者是在软件发行后在公布源代码，而后者是在代码编写和测试的过程中就公开。
开源对于我来说是一个熟悉却陌生的词，因为经常听到看到所以熟悉，但是却从来没有参与过一个开源项目。其实我们这次团队项目也算是一个大教堂形式的开源项目。学长将他所开发完成的项目完全开放给我们，让我们在此基础上完成从Mac到Android的移植。
而我们现在在做的也是一个教堂式的开源，项目进度和项目细节只限于老师，助教和团队成员。我个人其实是比较喜欢这种方式的，或许会缺少一些其它的或许有用的声音，但好处是可以让我们更加专注于自己的项目。而且我也不希望自己的代码莫名其妙地就被别人给改了。换个说法就是集市式是一个完全市场化的软件开源方式，他完全不受各种行为规范的的制约，而项目工程是一项工程，它需要的恰恰是一些可以量化，可以规范化的可操作方式。
（未完待续）