第二次阅读作业

No Silver Bullet - Essence and Accidents of Software Engineering：

 　  银弹能杀死狼人。如果我没记错的话，在漫画中柯南对黑暗组织而言就是一颗银弹。生活中是不是真的有银弹我还是不太确定。假如有，银弹就是

一点弱点也没有么？如果有，能抓住银弹弱点的又被称为什么？

　　在《No Silver Bullet》中，强调了由于软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。所以我觉得这篇文章不是在陈述没有银弹这个事实，而是希望我们在完成软件工程的时候不需要银弹。我们应该组织好开发团队，选择最合适的开发模式。其实人人都是银弹就做到了No Silver Bullet。

　　真正好的项目，需要便捷的开发技术，但没有一种技术能彻底的舍弃了人的存在。我们不能忘记的重要事实是，软件是为了方便人类而被创造的。

 

 Managing the development of large software systems: concepts and techniques

这是后来大家说的 “瀑布模型”，它有什么特点?

　　根据原文，完整的瀑布开发模式应该是这样的：

 

　　

　　瀑布模型有以下特点：
　　为项目提供了按阶段划分的检查点；当前一阶段完成后，只需要去关注后续阶段。这个特点决定了瀑布模型的适用范围：不适用于经常改动需求的项目；可在迭代模型中应用瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
　　但是瀑布模型还有以下特点：
　　在项目各个阶段之间极少有反馈；只有在项目生命周期的后期才能看到结果；通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 

　　瀑布模型对很多类型的项目而言依然是有效的，如果正确使用，可以节省大量的时间和金钱。对于我们的项目而言，是否使用这一模型主要取决于是否能理解客户的需求以及在项目的进程中这些需求的变化程度，对于经常变化的项目而言，瀑布模型毫无价值。

　　在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 

　　其实不管是瀑布模型还是什么别的模型，都是被有意简化，以帮助我们解决真实生活中遇到的问题。

big ball of mud

你的项目有一个大泥球么? 有什么解决办法？ 

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

　　其实很多软件都是靠着大泥球完成的。我觉得大泥球之所以有这么强的生命力，肯定有他的可取之处。比如虽然肉体上的工作量大，但是思想上的工作量小；比如他的逻辑简单，易于快速构造。同时弊端也是显而易见的。在现实生活中很多时候无论花费多少时间试图去找出完美的软件结构,客户总是引入一个变化破坏这个结构,不存在完美结构,只存在那些试图平衡当前的代价和收益的结构。有时候,程序员把原因归咎于客户,责怪他们总是改变需求。但是这不是他们的错误，他们只是在思考一种最合理、有效的方式为自己的工作服务。

　　但是，客户连源代码都看不到，这种怨念却是没道理的。当我们接收时间管理助手的时候感觉就是一个大泥团。没有注释，没有文档，很难看懂一段代码对应哪块功能。但是还是得慢慢的看，理解。我们的解决办法是每人负责一小块，将大泥球分成小泥球，然后再解决这个小泥球，这项相对容易些。但这样也会出现一些问题。如果我的“小泥球”里的一些东西牵扯到别人的”小泥球“，那么我就很难做下去。所以加强组员的沟通对解决大泥球也很重要。 

CatB – Cathedral and the Bazaar

你的团队是用什么方式建造软件?

Lost in CatB.

这些情况在你的团队中出现过么?

 　　所谓的大教堂模式（The Cathedral model）：源代码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。
　　 市集模式（The Bazaar model）：源代码在本模式也是公开的，不过却是放在互联网上供人检视及开发。

　　根据我对阅读材料的理解，我们团队的开发模式应该是Cathedral模式。好像与Cathedral and the Bazaar 的倾向相左。

　　大教堂模式的优点是团队内比较凝聚，可以集中到一个点。而我们做的项目相对比较小，适合团队集中解决。

 　　在《A Generation Lost in the Bazaar》中，作者却报以不同的观点，警醒我们不要在市集模式中迷失。他认为，Raymond在其书中称颂的集市模式导致的悲哀的现实：“一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着，粘贴着。”

　　这确实一个问题，但出现这个问题的原因不是模式不够完善，而是程序员自己的原则性不够强，如果每个程序员对自己所用的代码都了然于胸，不可能出现这种情况。

Agile Method – by Martin Fowler

你的团队在开发中用了那些敏捷的思想和做法?

 

　　先总结一下原文章里的一些我觉得有意义的观点：

　　在所有敏捷开发方法中，XP（Extreme Programming）是最引人注目的，它适用于需求快速变动背景下的中小规模的开发团队。极限编程弱化针对未来需求的设计，非常注重当前的简化。因此，极限编程适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求，极限编程在平衡短期和长期利益之间做了巧妙的选择。极限编程的特点：

　　1.极限编程方法从整体团体的开发小型的系统等方面解决了这些问题。

　　2.极限编程使用了发布计划的方法。使得开发人员能对前一阶段的开发成果进行评估，更好地把握后面工期的任务安排

　　3.极限编程方法尤为强调面对面的沟通，通过现场客户、站立会议、结对编程等方式来保证沟通的有效。
　　我们团队在开发时间管理助手的时候有采用极限编程方式，比如会采用类似Pairwork的方式集中解决一个问题。还有在做团队项目的时候每天更新Daily Scrum以加深组员之间的了解等都符合敏捷开发模式。