个人博客作业Week7（阅读文章，心得体会）

　　Alpha阶段结束了，内心可以说是五味杂陈。不是说我们的产品拿不上台面那般差劲，复杂的心绪主要来源于和别的队的比较，别的队才刚刚发布没多久访问量和注册量就破百了，并且还发起了找bug送红包的活动。可能是觉得付出了相同的努力，却没办法换回相同的效果，看来还是得审视自己的问题。

　　本周的个人作业是阅读关于软件开发本质和开发方法的博客/文章，结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。借这个机会找一下我们的不足吧。

　　阅读材料目录：http://www.cnblogs.com/jiel/p/4892734.html

银弹 / Silver Bullet

　　（阅读材料：http://www.cs.umd.edu/class/spring2003/cmsc838p/General/NoSilverBullet.html  &  http://www.drdobbs.com/there-is-a-silver-bullet/184407534/）

　　《没有银弹：软件工程的本质性与附属性工作》（英语：No Silver Bullet — Essence and Accidents of Software Engineering）是IBM大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文，原先是在1986年都柏林IFIP研讨会的一篇受邀论文，隔年电机电子工程师学会《Computer》也转载了这篇文章，他们用了几张《伦敦狼人》(The Werewolf of London)之类的电影剧照来当作说明，还加上了一段〈终结狼人〉的附注，用来引出非银弹（silver bullet）则不能成功的（现代）传说。该论述中强调由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。（摘自：维基百科）

　　其实我还没有太明白这部分，关于这颗“银弹”到底有没有，还需待我细读。

瀑布模型 / Waterfall Model

　　（阅读材料：http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf）

　　瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。（摘自：百度百科）

　　可以看一下上面这张图，“瀑布模型”的意思也就理解了。从软件的计划开始，完成每个层次之后就可以进行下一个层次，这样依次执行，发现问题之后返回上一个层次解决问题，有点像“回溯算法”。瀑布模型强调的就是一个软件项目的开发应该是按照阶段一步一步来实现的，不能越级也不能同时进行，因为这些层次是相互依赖的，从基础到高级，如果基础没有打好，“高楼”就会出现问题。所以没有按照这样“瀑布式”的开发模式进行开发，那么这样的工程是不可能一帆风顺的，并且是会出现很多问题的。

　　我们的团队在这个方面似乎有些欠缺。特别是在UI的设计中，我们把原来的UI没有经过重新设计就直接进行新的“拆拆补补”了，所以Alpha现在的样子不能说是Material Design的风格，虽然界面外表看起来还可以，但是内里很杂乱。这就是我们没有在发现问题之后返回设计层次进行修改在继续开发的结果。这一方面，我们会在下一次会议中重点讨论的。

大泥球 / Big Ball of Mud

　　（阅读材料：http://www.laputan.org/mud/）

　　所谓大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。

　　这个解释还是比较容易理解的，不像上面那么复杂难懂。从个人的观点来说，我认为“大泥球”在所有的工程中都会存在，至少是出现过，所以大泥球的出现应该是十分正常的。

　　之所以说大泥球在每个工程中都会存在，是因为任何一个工程无论是在开发初期的设计，还是开发过程中都不能做到和预期结果百分百的相匹配，更别说因为需求的变化也随之变化的预期结果了。我们总是期待工程能够十分顺利的进行，其实不然，面对“浩瀚”的代码海洋，即使是最有条理的人也不能永远对这些代码保持理智，所以接连不断的bug就会出现。修复了旧的bug，新的bug就会出现，这时我们说的大泥球就会越来越多。

　　于是就不得不说我们的工程了。我们自己对Alpha版本也不是很满意的，就在发布前夕，我们都还在不断地修复bug，同样也出现旧的bug修复完整新的bug出现的情况，不过好在Alpha版本顺利发布了。说我们的程序中没有大泥球那是不可能的，这些大泥球的正是代码碎片式的修补造成的。然而，面对这些大泥球，在时间的压力下，我们也只能睁一只眼闭一只眼。

　　由于大泥球的危害不仅限于代码阅读和理解方面，它的潜在影响会在后期的工作中逐渐显现出来，所以我们在Beta版本中会特别注意这方面，我们没有办法阻止大泥球的产生，只能在后期的工作中不断地消除它们。

大教堂与市集 / The Cathedral and the Bazaar

　　（阅读材料：http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar）

　　《大教堂与市集》（The Cathedral and the Bazaar）是埃里克·斯蒂芬·雷蒙（Eric Steven Raymond）所撰写的软件工程方法论。以Linux的核心开发过程以及作者自己主持开发的开放原始码软件──Fetchmail为讨论案例。文章在1997年5月27日发表，并在1999年出版成书。本书讨论两种不同的自由软件开发模式︰大教堂模式（The Cathedral model）和市集模式（The Bazaar model）。（摘自：豆瓣）

　　大教堂模式，指的是源码是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。市集模式，指的是源码是公开的，不过却是放在因特网上供人检视及开发。

　　我们这样理解会更形象：大教堂是每个人都可以去的，进去参观和瞻仰，你可发现富丽堂皇内部的瑕疵，但是你却不能自己去擅自修复，只能由这座大教堂的拥有者来进行修复，所以有的人说大教堂拉长了bug修复时间；同样的，市集也是每个人都可以去的，但是市集里没有这么多规矩，你可以随时对自己不满意的地方提出改善的意见，因为这是众人的市集，也是众人共同创造的市集。

　　在我看来，大教堂模式只适用于小规模的工程开发，因为这样的工程不需要太多外界的意见和建议，内部团队就可以完成所有的需求；相对的，市集模式就需要应用于涉及范围更广的工程开发之中，因为只有一己之力不太可能面面俱到，所以要借助大众的力量。无论是大教堂模式还是市集模式，都有自己的优点和缺陷，只是在不同的开发背景下各有各的突出。

　　我们的工程开发类似一个大教堂模式，很小的一个工程，不需要太多人的介入，团队内部就可以自己解决，唯一一点和这两个模式不同的是我们没有开源，没有把代码公之于众，也导致许多bug隐藏着还未被发现。

Lost In CatB

　　（阅读材料：http://queue.acm.org/detail.cfm?id=2349257）

　　这篇文章主要讲的就是软件对于软件包的依赖性在增多，同时软件的复用性在降低。现在的开源项目太多了，随手可得还不要钱，中国人最高兴……这么好的资源素材放在你面前，你不要？

　　我们不能否认各种软件包给工程带来了或多或少的便捷，但是这种便捷也只是短暂的。市场的需求是不断变化的，随着这些变化，之前已有的各种软件包、开源软件等等都会渐渐失去其独特性，过度依赖软件包会让降低程序的扩展性，到最后只能推翻重做。

　　就拿我们的App做例子，我们的工程中也使用了许多包，像百度的地图和其他开源的代码包，我们之所以这么做，是因为为了完成特定的功能，在较短的时间内只能使用别的软件包。好在我们并没有完全依赖于这些包，不过还是要在Beta版本时多谨慎一些。

软件工程的方法论到底有多少用处?

　　（阅读材料：http://agile.dzone.com/articles/jez-humble-why-software  &  http://continuousdelivery.com/2012/08/why-software-development-methodologies-suck/）

　　有些人提到“方法论”就头大，比如我。我们真的需要学习软件工程的方法论吗？

　　你可能会这么问：“我们学了那么多年的哲学，什么时候有用到过？”有，我们一直都在和方法论打交道。软件从零发展到现在，从简单的计算器到现在层出不穷的各类软件，软件工程的复杂度也在不断的提高，需要更精准、更全面的科学的方法论来支撑。我们总认为做工程就是靠自己的知识和经验来，却总不愿意承认当我们面对困难走投无路时，站在科学的方法论上审视全局，才能找到最终的解决方案。也只有运用科学的方法论才能在软件工程开发中有的放矢、有条不紊地进行工作。

　　所以，如果要问软件工程的方法论到底有什么用？有多少用处？你可以尝试着使用这些方法论来做一些对比。