个人阅读作业2

　一、sliver bullet

　查了资料才知道silver bullet的意义。银色子弹（英文：Silver Bullet），或者称“银弹”“银质子弹”，指由纯银质或镀银的子弹。在欧洲民间传说及19世纪以来哥特小说风潮的影响下，银色子弹往往被描绘成具有驱 魔功效的武器，是针对狼人等超自然怪物的特效武器。后来也被比喻为具有极端有效性的解决方法，作为杀手锏、最强杀招、王牌等的代称。后来银色子弹常被用做 致命武器的代言词。被比喻为具有极端有效性的解决方法，作为杀手锏 、最强杀招、王牌等的代称。《no silver bullet》是Fred Brooks在1987年所发表的一篇关于软件工程的经典论文。该论述中强调真正的银弹并不存在，而所谓的没有银弹则是指没有任何一项技术或方法可以能让 软件工程的生产力在十年内提高十倍。

　　在该论述当中，讨论到了次要和必要复杂度的差异。所谓次要复杂度是指由人们本身所产生的 问题，而这类型的问题是可以被解决的。譬如说，撰写和最佳化组合语 言的复杂度就是属于次要的，它可以借由高阶程序语言如Java来取代。必要复杂度则是从软件本身要解决的问题衍生而来，并无法被移除。如果软件需要提供三 十个不同的功能，那么这三十个功能都是必要的，这些功能都必须被实作出来。软件工程面临的问题在于我们已经清除了大部分的次要复杂度，而剩余的（主要复杂 度）都无法改变。这就让我想到了此次软工大作业，我们总是在寻求捷径，希望能够简洁方便而且高效的完成作业，不至于耗费太多的经历以及时间，但是过度的寻 求捷径的结果就是我们发现寻求过程才是真正的浪费时间，最终还是把完成的方法定位在自己探索实现上，联想到“no sliver bullet”，恰恰如此，当捷径被发觉的到达一定程度后就没有什么利器可以让我们一蹴而就了，这时候需要的是我们脚踏实地，持之钻研。后来也奇怪，当我 们放弃寻求开始依靠自身的时候我们发现其实有些东西做起来并不难，使我们把他想的太复杂了，其实探索的精神和抛弃拐杖的独立就是我们的sliver bullet!

当然“there is a sliver bullet”的混合动力汽车和生物燃料是另一说了~

　二、big ball of  mud

　　大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。big ball of mud的出现会使得系统内的信息不能得到更好的控制和共享，使信息失去了应有的价值。大泥球般的系统的整体结构没有得到很好的界定，也就使得大泥球越发的 复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。而大泥球产生的原因往往是程序员不合适的解法以及用 户多变的需求。结合此次作业我们在这方面就做的比较好，在动工之前我们开会详细讨论了程序设计的框架以及分工还有代码接口以及编写方面的许多标准，我们从 软件的性能和特性出发集中架构和性能设计，使得软件的初步设计就避免了产生晓得问题或者方向的误差。在个人负责的代码设计阶段也都尽可能应用了优化方法， 减少了许多冗余。

　三、Cathedral and the bazaar

　　《Cathedral and the bazaar》是一本很有趣的书，从“大教堂与集市”的书名就看的出来，你要是以为它真的是在讲教堂与集市那你就大错特错了，其实它是一本软件工程方法论。本书讨论了两种不同的自由软件开发模式：

　　The Cathedral model：原始码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队控管的。

　　The Bazaar model：原始码在本模式也是公开的，不过确实放在因特网上供人检视及开发。

　　我们此次作业的开发模式应该是属于The Cathedral model。

   四、瀑布模型特点

　　总结如下:

　　优点：（1）为项目提供了按阶段划分的检查点。

　　　　　（2）当前一阶段完成后，只需要关注后一阶段。

　　　　　（3）可在迭代模型中应用瀑布模型。

　　 缺点：（1）在项目各个阶段之间极少有反馈。

　　　　　 （2）只有在项目生命周期的后期才能看到结果。

　　　　　 （3）通过过多的强制完成日期和里程碑跟踪各个项目阶段。

   五、Agile Method

　　文章中很多观点很有意思，其中极限编程很实用。先介绍一下极限编程的特点：

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

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

　　（3）极限编程方法尤为强调面对面的沟通，通过现场客户、站立会议‘结对编程等方式来保证沟通的有效。

　　我们团队在开发note应用的时候有采用极限编程的方式，比如会采用类似pairwork的方式集中解决一个问题，还有在做团队项目的时候每天更新diary scrum以加深组员之间的了解等。

　六、软件工程方法论

　　围绕软件工程开发和方法论，总有很多教条式的口水仗。但有两条常用的法则可以帮我们选择好的实验：划小开发周期以及提升反馈效率。