第二次阅读作业
话说这次的英文好多，看的头痛………（英文水平确实有待提高，只有吃了苦头才会醒悟）
先说说大泥球。对于大泥球我认为不只是设计模式上的问题，甚至可以说我认为基本和设计模式无关。
Despite the emergence of development methods that encourage and facilitate well-factored code, and the growth of the Software Craftsmanship movement, the Big Ball of Mud remains the most popular design for software, including greenfield development that has the full benefit of hindsight regarding the bad design approaches of the past.
毕竟软件工程不是一门刚出现的新型学科，它的理论已经包含了极为丰富而复杂的内容，而且已经在实践中取得了巨大的成功。然而我们的big ball of mud并没有随着理论的发展而消失，反而有愈加壮大的趋势。我认为倒是和程序猿的责任心和技术水平有很大关联。
像这样的代码：
return new class()->a()->b()->c()………….（可以写很多）这样的代码可以说能用，实际上最后软件的效果也没有什么影响，但是无论是IT技术水平多低下的人（哪怕想我这样的菜鸟）都不会对这种代码有好感，即使它写了注释并且可读性不错。
如果程序员没啥责任心，软件只是做到能用就好，那么我想大泥球就不可避免了。因为大泥球的产生有利因素太多了，像需求的不断变化，代码重用什么的。这些都会导致大泥球出现几率大大增加，如果程序猿再仅仅以“能用”为最高原则，那么那些破碎而臃肿的代码将在用户需求的更改和代码重用的过程中越滚越大。
至于程序猿技术水品的问题，我想不用解释了。我们组的谭传奇说他在写c++大作业时写了一个ball of mud，我用的是我相对更熟悉的c#，并没有遇见太多的问题，但是我对自己c++水平还是有所了解的，如果我用c++写，那么结果也差不多吧。
当然也有人把ball of mud和敏捷开发联系起来，我认为有道理但是显得偏颇。关于敏捷开发一会再说。
在说说瀑布模型。开发了一段时间我们的Absolute Defence游戏，感觉上虽然从理论上说我们是瀑布模型，但是实际上还是更像敏捷开发。瀑布模型是一个有非常严格流程的模型（个人感觉更加官僚一些），从设计到编码到测试最后发布，环环相扣。当然这都建立在团队中每个人的基本水平都不错且能快速融入团队中工作。我个人感觉毕竟是学生，团队里水平参差不齐，像dev里我认为我的水平就是很差的。我们更倾向于不断讨论学习（比如这个cocos2d引擎如何使用）。
而且现在的主流观点是瀑布模型的作用在不断变小，甚至逐渐退出历史舞台。我个人理解的原因很简单，这个模型太过死板，不能面对现在软件工程的新发展。比如不断变化的用户需求，软件商业化使得软件设计不只是程序猿的事，用户才是我们的上帝。而且瀑布模型在开发到最后才能看到成品，这样前期没有发现的问题会在最后集中爆发，导致极大的危害，甚至可能导致工程本身的失败。就好像设计一栋大楼，一共20层，盖到17，18层才发现5，6层的设计有问题，可想而知后果多么可怕。所以为了克服这个缺点，敏捷开发，迭代模型，极限开发（XP）等都应运而生。我们的项目我认为就有这样的风险，当然，这是个小项目，即使出现问题也不可能导致项目彻底失败，但是可以由此推想瀑布模型越来越不受待见的原因吧。
顺便吐槽一下，关于瀑布模型老师给了个youtubue链接地址，话说youtube是啥，可以吃吗？
再说说集市和教堂。那篇文章的作者绝非空穴来风，从文章中可以很明显的看出他有很长时间的开发经验和对开源开发的理解。他的很多观点都是结合具体的实例（就是他手中的FreeBSD）来阐释的，的确很有说服力。但是我认为有些观点也是不可忽视的，比如如下的评论：
个人认为这篇文章比较片面。今天Linux在整体OS市场上已经击败了windows, 大量各种open source软件都取得巨大的成功。web service取代software license成为重要的商业模式这个预言也获得了印证。libtool成为主宰恰是一直有人对它们负责。二进制兼容在unix商业时代就没有成功，不能怪到开源上去。 (58分钟前)
有旗帜鲜明反对的，也有中肯的评价：
或可对比读一读这篇“敏捷的酒后问答”：http://t.cn/hdrXFY 一味地肯定开源，和一味地肯定商业，maybe是上坡和下坡，走的是一条路，是时候该转弯了 (今天 08:34)
当然还有很多挺本文的评论，不在一一摘取。我的观点是，大教堂有大教堂的优雅和美观，集市有集市的便宜和便利，就现阶段在这么多开源软件很成功的情况下把整个开源捧上天或者一闷棍打死都是不切实际的。任何新生事物必然伴随巨大的漏洞，同时也会有旺盛的生命力，不能因为他的漏洞而摒弃它，也不因为他的生命力而对他顶礼膜拜。我们既在使用windows这样优雅的教堂，也会使用那些基于开源的google服务集市。当然在《大教堂和集市》中，作者的观点就比较极端，认为开源可以解决几乎一切问题，但是不能忽视的是开源的劣势也会随着IT技术参差不齐的人的加入而大大凸显。
最后说说敏捷开发吧。在老师的要求下，我们也尝试了10天的敏捷开发，感觉上的确体会到了敏捷开发的优点，每天的讨论逼迫我们不断学习，不能偷懒，加快了项目的进度。但是我认为这只是学习开发模式，根本的目的在于让我们明白自身技术的重要性。我们不只是要明白如何使用敏捷开发，而且要在学习和使用过程中了解到我们的劣势。至少通过10天的敏捷开发，我觉得我的编程水平还很待提高。当然，我们不能为了敏捷而敏捷，那就是揠苗助长。所以说不管什么开发模式，都是以开发人员的技术为基础的。只有基本技术上去了，优秀的开发模式和开发模型才能大显神通。否则不管是不是敏捷，结果都是big ball of mud。当然，在以后我们走上社会后，我们回过头来看今天的学习，可能我们的体会会更深一些。
