第二次的阅读作业，主要是关于软件工程中的一些方法以及软件工程中的一些问题。这次的阅读作业，压力感觉有点大，大部分的文章都是英语的，不是很能够看懂，只能够就着自己的这点水平来谈一下看了这几篇文章的想法吧。
既然名字里面已经加入了一个工程，那么就不可能是计算机诞生早期的时候那样，只是一些技术牛人的玩具了。这个时候，所面临问题的复杂度，增长的数量级就不是简单的线性了。在《No Silver Bullet: Essence and Accidents of Software Engineering》这篇文章中，Frederick P. Brooks, Jr.提出了，软件工程中我们现在所面临的软件工程中的问题，没有一个Silver Bullet，不仅现在没有，以后也不会有。我们知道，在计算机硬件方面，存在着一个摩尔定律，最开始的版本的内容是：当价格不变时，集成电路上可容纳的晶体管的数量每18个月翻一翻，后来这个定律也扩展到了其它的硬件上面，有点方面可能没有这么快的增长速度，但是，都是在增长，但是，在软件方面，却始终无法跟上这样的速度，为什么会这样呢？是由随着软件系统发展同时具有的complexity,comformity,changeability和invisibility决定的。这些问题本质上我们是无法屏蔽的。所以也就必然决定了软件工程中具有的问题。软件工程发展的过程中，我们不能够从软件的本质上找到一些方法，但是在某些accident下，也会促进软件工程的快速发展，比如high-level languages,time-sharing和unified programming environments。虽然说软件所具有的一些本质上的特点决定了不存在这样的silver bullet。但是，通过不断的实践与改进，我们的方法也在慢慢地改变着，这些也为软件工程的发展定会起到很好的作用，比如:ada and other high-level language advances,object-orientd programming...
基于软件开发具有的特性，人们提出了很多方法，其中，有一种是Dr. Winston W. Royce的论文《MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS》。这篇论文中提到的方法，现在我们叫做“瀑布模型”。这个开发过程通过设计一系列阶段顺序展开，从系统需求分析开始直到产品发布和维护，每个阶段产生循环反馈。对于这个模型，我么一开始可以想到，因为软件开发的过程比较复杂，那么其中就必然可能会产生各种各样的问题，如果能够有一个恰当的回去的过程，那么我们是否可以修正已经出现的问题呢？这个模型或许提供了一种解决方案，我们在每一阶段都能够返回前面的阶段，这样就可以解决我们已经发现的问题了。但是我们必须要考虑开发过程中的每一部分，每个过程之间的衔接会做到这么的紧密吗？如果各个周期之间的反馈非常少的话，那么是不是就意味着项目进行得非常不错，问题非常少呢？我看不一定，同时，往往在软件开发指出是很难确定项目的需求的，如果项目的需求发生了改变，这个模型是否能够轻松的应付？这也不能够得到解决。
Big Ball of Mud，意思就是没有清晰的结构的系统，为什么会造成这样的因素，《Big Ball of Mud》这篇文章中详细地介绍了为什么会产生这样的情况，同时也为我们提供了一些能够化解这个泥球的问题。我觉得，在软件项目的开发过程中，是很容易造成这样的问题的。就拿我们组这次的项目来说，其实就是一个大泥球。现在已经结束了alpha版本的编码工作，我自己觉得做得就像shit一样，对于这个项目，可能我们在一些方面对于问题的理解是不到位的。也就造成了现在的我觉得的问题。因为我总觉得有一些几个团队之间的合作体现得太少了，从而让人感觉其中很多很多模块具有交集，同时在这个alpha版本中，一些应该有的功能也不能够完成出来。对于，这个泥球，还是需要必须注意的，很有可能，它就简单的累积得越来越大。最终甚至到了一种无解的地步。说到底，还是需要做好软件开发中的每一步。当然也就必然要伴随其中的一些监督，不可能只是挺coder说自己做好了某个某个部分。
《The Cathedral and the Bazaar》，这也是一个现在争论的问题。代表了两种不同的free software开发模型。其中：
The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC are presented as examples. The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.
对于这两种模型，就我自己而言，我是比较支持第一种的。这里也同时说《有人负责，才有质量：写给在集市中迷失的一代》。这两篇文章都是和The Cathedral 和The Bazaar有关的，让更多的人加入到软件的开发与维护的过程中，这是一种非常好的想法，因为这样能够给一个软件提供更多的想法，更多的视角。也可能会让这个软件能够更加的成功，更加地被人们接受，但是我们必须要考虑的就是，每个人都会有自己的想法，如果更多人都加入到了里面，或许会让这样的软件具有更多的功能，在其中的某个方面具有更好的效果。但是呢，当把所有的模块都整合到一块的时候，还有睡能够说为这样软件负责。即使有人想负责，但是又是他能够决定的吗？更多的人加入到其中，带来改进的同时，也让整个软件变得冗余（当然这个都是在软件原有的一些功能特性的基础上说的）。对于我们现在开发的这个项目来说，现在这个阶段，应该是属于cathedral，在这个时候，我们还是集中在非常重要的功能上面，如果做到了以后，在以后其他同学的软件工程课上不断地采用这个原型，然后大家往里面不断地加入自己的想法，那么也就成了Bazaar了。
最后一篇文章是《Agile Method》，这是Martin Fowler写的关于敏捷方法的文章，敏捷方法是现在广泛关注的一种比较流行的方法。我们这学期的软件工程也是采用这样的方法。要说这种方法好，我觉得主要还是这个方法能够做好很好的过程管控，并且能够做到以人为本。在敏捷开发的过程中，团队成员之间能够做到很好的紧密合作和沟通，这种沟通，基本上是面对面的沟通。同时还有可以工作的软件优先于文档，客户协作优先于合同谈判，能够随时应对变化。这些特点我都是特别喜欢的。我觉得这样是能够让开发人员能够更多的精力集中到软件的开发过程中。让测试人员能够更加专注地集中到测试的工作中。这些都是好的方向。敏捷之道，最终也会打造出一支精良的团队来。
软件工程中所面对的问题规模越来越大，但是实际上其中的有些部分是冗余的，需要能够做到减少这样的问题，要能够合理高效地做好其中的开发。就现在的一个基本情况而言，学计算机这个方向的人越来越多，很多人看上这个方向很热，很火，于是便纷纷地加入到里面来。但是实际上，我觉得很多时候是造成了这个专业的一个水准的降低，更多的copy，甚至不假思索的copy，只是在不断的降低这个行业的质量。我还是觉得cathedral很好，毕竟这样的团队是精英的，加入到其中的也会对软件的质量做出自己的保证。
软件这个东西，为啥有的人就能够做得艺术品一样，而有的人做的就是一坨**呢？