阅读作业2-刘昕

 

 

 

阅读作业2 10061145 刘昕

这次作业我们阅读了大量关于软件开发、瀑布模型、敏捷开发的文章。虽然目前没有接触什么太多的代码工作，但是通过每次小组内的交流和同组员的一起讨论，对文章中的许许多多问题也有一些自己的感受。
瀑布模型对我来说像是一个流水线，一部分人负责一个流程，一个流程完了进行到另一个流程。其将软件生命周期分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护六个阶段。这样的流水线式的软件生产就像是工厂里组装汽车等货物一样。在管理上和人员调动上有其自己的优势。但是做一个软件不像是流水线上的汽车，而像是顾客花费高金聘请的师傅人工打造的高档车。瀑布模型的开发模式和顾客的联系只有在最后的阶段。而从前面出现的问题客户不仅会无能为力而且会随着流程的进展让问题滚雪球，越滚越大。从而在客户提出意见返工的时候，又要回到最开头进行修改。虽然瀑布模型能有很高的效率和质量，但是如果不能在满足客户的需求上一步到位，那反而会成为一种死板的耗费人力物力的开发模式。
不过瀑布模型中对文档的严格要求对我来说是一个很不错的特性。文档在软件开发中是衔接前后阶段的唯一依据，具有着十分重要的地位。而在现实工作中，我们将会接到许多软件的维护和更新工作，其所需求的也是基于旧有的软件。这时候一个好的文档会为我们的工作带来很多的便利，提高效率。
不过常常看到工作的学长们抱怨客户的需求时刻都在变化，我想在这种情况下，流程相对死板的瀑布模型是否还有其用武之地？

极限编程貌似真的走了另一个“极端”，和客户的频繁交流势必能做出最适合客户需求的软件。不过或许对开发人员来说是一个更为痛苦的过程。时刻应对变化，同时可能随着不停更换需求导致一个“完美”软件在不断的更改需求下千疮百孔。其写出的代码的质量与瀑布模型所写出的相比，或许会在质量上有所欠缺。不过同时我想也是对程序可拓展性的一个考验。很好的锻炼了程序员的能力，对我们学生来说应该是不错的锻炼机会。

文章中对于敏捷开发的部分看不太懂。根据在CSDN上查阅的资料。敏捷开发应该是一种时刻变化，以人为本，设计周密，与客户协作的软件开发模式。重点还是开发好程序，不过貌似集结了瀑布模型和极限编程的优势，以达到最适合这个时代的软件开发模式。这方面的开发模式接触的太少，我只是觉得构想的很好，希望能在今后的学习工作中逐渐尝试这种开发模式，真正的体会到其优势。

“没有银弹”是一篇很不错的文章。虽然从来都不觉得软件开发是一件简单的工作，但是却总是坚信着船到桥头自然直的开发方法。在编程中边写边学习新知识，总是会有柳暗花明又一村的感觉。看完之后觉得要正视软件开发，对于人本身存在的问题绝对不是报以侥幸的心理就可以蒙混过关的。而是要综合各种方法活学活用以解决不同的情况。这意味着我们的学习不仅仅是这几年的学习生活，而是不断的在工作中去学习、去尝试、去掌握更多的方法。以不变应万变，而这不变的是灵活掌握各种方法，并学习新方法的办法。这或许是我们解决所有问题的唯一银弹。

大泥球这篇文章看的不太明白，虽然逐渐的在同学的交流中，这些问题正在一个个的浮现，不过总觉得这不会出现在自己的实际代码中是我最头疼的事情。像是软件开发者总会认为自己的代码是完美的。我们或许纵然就是那些大泥球代码的创造者，我们也不一定会承认。作为软件开发团队中负责测试的人员，我觉得这种事情应该让我们去判定，判定一个软件到底是不是”大泥球“代码。

大泥球的出现和后面的集市与教堂的文章又有几分类似。在作者的语气中，我隐含的感觉到了作者在批判UNIX在众多良莠不齐的编码者的合作下已经成为了拖泥带水的超大大泥球。虽然作者的用意是批驳集市类的软件开发方法，但是一个人集”百家之成“而写的东拼西凑的大泥球应该也算是这种集市下的产物。这方面我觉得集市开发思维并没有错，问题应当归结在集市的管理者身上。总的管理者有权选择选用谁的代码，改用谁的代码，而非自由贸易，谁写的代码都能上的局面。就好比我们正常的软件开发中虽然不是从头到尾一个人在工作，但是大家在确定了设计方案后，PM通过适当的管理可以将软件的质量控制在一个比较高的水平上。如果”集市“下有一个拥有足够凝聚力和鉴别能力的优秀管理者，能及时向集市的许多商家反馈他们所写”商品“的意见和鼓励。或许会能更好的掌控”集市“。
对于一个集体开发的项目，大泥球或者集市的现象背后都是对敏捷开发的迫切需要。不过也是如我之前所感觉的一样。听起来很好，但是还是不知道应该具体如何去做。这应当在我将来的学习生活中自行去寻找答案吧。