第二次阅读作业

　　相比第一次的阅读作业只需要阅读教材，这一次的阅读作业的阅读量明显要更多了。

　　十分可惜的是，瀑布模型的那个网页我一直都打不开，所以只能用百度和维基查了一下。显然，瀑布模型是一个便于分工合作的模型，瀑布模型使得每一个阶段都按部就班的完成，不易出现问题，但是这种模型并不能够满足用户需求的变化，如果用户的需求一直在变化，那么瀑布模型就显得毫无价值。

　　对于这一次的阅读任务，给我感觉最深的便是big ball of mud这篇文章，“大泥球”指的是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。“大泥球”实际上存在于很多的程序和系统中，而这些程序大多都是一次性完成的，为了使软件不出现问题而产生的大泥球。由于客户的需求变化很快，所以好多代码都由于工期短导致出现“大泥球”。如何解决好这样的“大泥球”是一个难题，这要求一个团队中有一个详实的计划，要求团队中每一名成员对自己的代码负责，开发人员的素质是解决问题的关键。

有人负责，才有质量：写给在集市中迷失的一代

　　正如标题上所说的，有人负责才有质量，如果每一段代码都是开发人员用尽全部智慧编写的，那是不是可以让代码变得更美？是不是可以让程序中的“大泥球”消失无踪？