阅读作业2

读了老师布置的阅读作业⋯⋯觉得自己英语水平真的是弱爆了

对一些文章的理解有待提高，说一下自己对几篇相对理解比较深的文章的看法

 Managing the development of large software systems: concepts and techniques

这篇文章里虽然并没有提出瀑布模型这一概念，但其中的思想就是瀑布模型，瀑布模型的特点就是通过设计一系列阶段顺序来开始一个项目，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

这种模型的优点显而易见，可以对每个阶段设置时间检查点，而且每一个阶段都只需要对前后两个阶段负责，但是也有一些缺点，比如不会适应用户需求的变化，就像我们第一次的个人项目，需求改了几回，如果用瀑布模型，就必须从第一个阶段开始改，一直到软件需求，需求分析，设计，编码，测试，运维。

CatB – Cathedral and the Bazaar & Lost in CatB.

这两篇阅读材料都是在讲大教堂与集市这两种不同模式的利弊。大教堂模特点是源代码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的，而集市则正好相反，其源代码在本模式也是公开的，不过却是放在互联网上供人检视及开发。很明显，集市更利于一个项目的除错，其开源的方式使得更多的人能够加入到项目的开发并提供意见，而大教堂只能靠一个专属团队来维护开发这个项目，感觉就像IOS一样。我们小组的项目应该是大教堂模式，在软件的3.0版，我们团队进行改进和维护。

在第二篇文章里，作者给我们从另一方面敲响了警钟，并不是一个项目越是开源越好，这样会使得很多良莠不齐的程序员混在一起进行开发，反而使项目变得脓包，是人们不禁怀念起那些大教堂模式下严谨优雅的项目来，就是说不要太高估农民修建市集的能力，但也不要像中世纪的教会，完全掌握着圣经的解释权，辩证的寻找一种平衡才是关键。

big ball of mud

直译“大泥球”，指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。我觉得这样的代码在现在随处可见，自己就写过不少“大泥球”，再比如我们团队所开发的软件里可能也有很多。当然，我觉得在敏捷开发里，尤其是我们这些水平不高的人在做项目时是不可避免的，因为缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长这些因素都会导致这一问题，只有提高了自己的水平，才能真正把敏捷开发做到极致。

Agile Method – by Martin Fowler

敏捷开发强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重作为软件开发中人的作用。而极限编程作为敏捷开发方法的一种，它是一种全新的、生机勃勃的软件开发方式。它的的出众之处在于兼顾了质量的两个方面，即满足客户期望的同时，降低缺陷的数量，同时这种方法颠覆了复杂性不断增加的循环。

敏捷开发是我们团队项目一开始就要确定的开发模式，比如我们每日的daily scrum，遇到问题在一起即使解决，这种沟通和反馈觉得都是敏捷开发的一种体现吧⋯⋯