个人阅读作业7

一、No Silver Bullet - Essence and Accidents of Software Engineering-Brooks

　　这篇文章名字叫做没有银弹，首先讲了什么叫做银弹，也就是所谓的绝招，同时他也提出了十年之内没有银弹的说法。这并不是说在软件开发的过程中没有技巧捷径，而是说没有能够万能的、适用于所有项目的银弹。原作发表于1986年，虽然我觉得而其中十年无银弹的预言虽然在后来已经不再适用，不过这篇文章中所讲的道理还是很有意义的。

　　比如说现在的敏捷开发，这在10年前几乎就是不可能的，10年之内软件工程的突破超过一个数量级绰绰有余，难道这说明我们还是应该寻找银弹？不，不是这样的，我们工作的依旧应该是踏踏实实解决问题，我们并不否认会有某一项技术为我们带来巨大的突破，我们其实也很希望有这样的技术诞生，不过我们我们不能为了寻找银弹而寻找银弹。相反，那些所谓的“银弹”也许就在不经意间被发现。

　　文章还提出了现代软件系统的本质性难点。首先是Complexity，软件实体的复杂性也许远远超出我们的想象，尤其是现在软件的规模在不断的扩大，复杂性也在不断的增加，这种抽象的，认为的智能活动是很考验人的思维的；然后是conformity，这在我们上个月的迭代中得到了充分的体现，前端和后端一起讨论指定合适的API接口，这不仅使我们的结构变的清晰，也便于我们的实现和测试，增加了我们的工作效率。然后提到了changeability，软件一定是会随着使用人群需求以及使用环境等等因素的影响而改变的，所以一个软件的维护周期也往往长于软件的开发周期。最后的是Invisibility，软件与显示中的实体相比还是太抽象了，即使加上各种文档说明，往往也没有办法完整的讲一个软件的结构表达清楚，这也造成了开发上的困难，人们之间有的时候沟通会变得很困难。这四点是软件开发的本质性困难，无论我们怎样减小这些困难给我们带来的印象，这些困难依旧会存在。

　　之后还讲到了三个解决了次要苦难的突破，高级语言，分时和统一的开发环境，这三种技术为我们带来的便利改善了我们的开发过程。接着文章还提出了几个未来可能是“银弹”的技术，这里就不再赘述。

　　其实我觉得，这篇文章是具有时间局限性的，很多看法在现在已经不在正确了，事实上人们也没有停止搜寻银弹。最后，我想说，其实大家都想找到银弹，每一个人都想发现或发明什么具有划时代意义的产物，在历史上留自己的名字，不过这一定是建立在不断努力改进的基础之上的，只要我们不断改进，我们就已经在银弹的路上了。

二、There Is a Silver Bullet – Brad J Cox

　　这篇叫做There is a silver bullet。看这篇文章之前，我先看了一眼发表时间，December 06，2004。虽然已经过了上一篇文章所说的10年，但是其中所讲的技术确实是在之前所产生的。

　　这篇文章介绍了面向对象技术，The Copernican Revolution，工业革命和可重用的软件组件。我在博客里不想过多的讲这些技术的细节，我只谈谈我的看法和感受。其中，让我产生共鸣最深的是可重用的软件组件这个“银弹”，我觉得这和我之前看见的一个的“科技黑箱”的概念比较像。你在使用某些组件的时候不需要完全了解使用这个组件是怎么来的，就像你在使用遥控器控制电视额时候，你并不需要知道这个遥控器是怎么做出来的。这种模式的好处是大大简化了我们的开发难度，组件的重用也减少了我们的开发量，也加快了开发的速度。不过我觉得，有的时候，对底层的不了解可能会导致在出现问题的时候无法从根本上解决问题。我大学同学的高中同学有个在北大某鸟培训过，代码写的看起来是挺不错的。在我大二上的时候只能写几百行程序的时候，那些人却已经可以写的很多很多了，给他们一个问题让他们解决，他们就知道代码应该这么写，但是却不知道为什么这么写，而且他们甚至连数据结构读不知道是什么，我真的怀疑他们在遇到底层问题到底应该怎样处理的。

　　所以，我认为了解一些底层还是很必要的，也就是我们所上的基础课，“银弹”很有可能就隐藏在这其中，当我们在不断享受的“科技黑箱”为我们带来的便利的时候，那些问题也随着被隐藏起来了，这也是一个巨大的隐患，我们一定要注意。

三、big ball of mud

　　大泥球，是指杂乱的，随意拼接的大堆代码，这些代码写成之后虽然能顾实现功能，但是非常不便于修改，也不便于他人的阅读和调用。

　　在这次迭代中，我们确实出现了大泥球，我们也想在第二轮迭代中改进这些。我在我们小组当中是实现前端代码的，我就来谈谈谈我们前段出现的大泥球吧，我们代码中出现大泥球最主要的原因还是需求的不断变化以及我们没有制定好完备的代码标准。当我们发现少了一块功能的时候，我就为了方便，直接在html代码里加了一块js的代码。发现又少了一个功能，我就又加了一块js代码，大泥球就这样产生了。还有一个就是在dom操作的时候，复杂繁琐的操作，一旦写好了就不想改了，想要改动与之相关的元素的时候就接着加getelement..等等，导致代码越来越臃肿。

　　总结一下，造成大泥球主要还是有这些原因

　　1.需求的不断变化(前端也是很累的...总改)

　　2.一次性的代码，没有考虑到某些代码是可以重用的

　　3.缺少前期具体的分析和设计，这也是最容易出现问题的环节，我们总是想到哪写到哪，这确实是一个很不好的习惯

　　4.复制粘贴..，这真的是一个老生常谈的问题了，我觉得除了需要的就是完全一样的代码的时候需要ctrl+cv，照着原代码重新手打一遍的效果绝对比直接复制粘贴要好，粘贴的时候往往会粘进来不需要的代码，在重新手打的时候可以将这些泥球去掉，重新手打这本身也是一个学习的过程。

四、CatB – Cathedral and the Bazaar 你的团队是用什么方式建造软件？

　　我们团队还是用的是大教堂的方式建造的软件，我们没有将代码公之于众(前端html代码不算，直接右键源代码不谢...这个我们现在还没有写的很深，所以大部分前端的实现都是直接写在页面中的)。

　　我们这样做我觉得是由于以下几点：

　　1.我们软件的规模比较小，我们自己解决就可以了，没有必要放在互联网上大家来检查

　　2.我们所做的是我们北航的社团平台，其中也有大量关于我们自己的数据，我们不想让这些东西有泄露出去的危险

　　3.虽然我们的项目不会只存活与软件工程这门课期间，课结束了我们依然会做下去。不过在课还没有结束之前，我们还是想更多的锻炼我们自己的能力。

五、Lost in CatB.

　　阅读了《有人负责，才有质量: 写给在集市中迷失的一代》，文中所说的确实基本都是事实，也都有理有据，接下来谈谈我的看法。

　　确实，现在互联网创业的大形势下，集市的开发方式已经很火很火了，集市也给我带来了很大的成果。不过集市的局限性也依旧很明显，就像文中所提的弊端一样，也和我在写上面的“科技黑箱”的弊端一样，这些都是联系在一起的。

　　文章下面的评论也都很有道理。比如说“一味地肯定开源，和一味地肯定商业，maybe是上坡和下坡，走的是一条路，是时候该转弯了”。集市和大教堂都有自己的优点，linux和windows以及osx都是当今世界上最好的操作系统。我们不能够轻易的否定谁和肯定谁。

　　再结合一下自身经历，我在开发的过程中不可避免的用到开源的东西，比如百度的Ueditor，这样的富文本编辑器以目前的我是不可能在一个月之内写出来的。但是我们的项目值得一提的一点就是我们除了sementic-ui之外所有的东西都是手工实现的，我们没有用什么现成的框架，虽然多耗费了不少时间，但是我们也学到了很多东西。

六、Worse is Better – Richard Gabriel

　　观点叫做更坏就是更好，我倒是觉得改成越简单就是越好。Gabriel的设计理念没有追求什么完美的设计，更加注重的而是简单性，正确性，一致性和完整性这些最基本的东西。过分追求设计很有可能会导致失败，而那些简单而又实用的东西往往会取得胜利。

　　阅读文章的时候也让我认识了Gabriel这个人本身，经营着一家不太好的lisp公司，不过要不是他的公司与其他公司相比处在worse的地位，他也不会得出worse is better这个结论吧，这本身也是一种更好的体现。

　　就像lisp语言本身一样，作为函数式程序设计语言，在如今什么都是面向对象的时代看似面向语言的语言是失败了，但是并不妨碍lisp以第二古老的高级语言继续存活下去，他也依旧是高智商科学家在编写高复杂度的程序时所用的语言。可以说，lisp现在的失败，恰恰是因为太成功了，超过当前这个时代了，现在最高级的语言也只是接近1958年代的lisp而已。

七、Managing the development of large software systems: concepts and techniques

　　瀑布模型的核心思想是按照工序化简问题，将开发分为各个阶段，当发现为解决好的问题时返回上一阶段解决就可以了。

　　但是瀑布模型只适用于用户需求比较稳定，只要不断维护的项目当中。但当用户需求不断变化的时候，这种模型就不再使用，我们总不可能总回滚到之前的阶段吧...

八、Agile Method – by Martin Fowler

　　我们用到了设计和施工分离这一思想，我们在施工之前设计好需要做些什么，在这些设计实现之后继续下一部分的设计。我们还用了迭代这一思想，分两轮迭代来实现项目。同时，我们的pm的管理模式也贯彻里敏捷的思想，他没有做所有的工作，他在我们遇到困难的时候给我们必要的指导，而且他还规划我们的项目，把我们会遇到的变化以及困难提前告诉给我们。

九、最后的文章

　　我觉得软件工程的方法论还是很重要的，虽然在我们目前的小项目中体现的可能不是很明显，但当项目的规模很大的时候，想当然的个管理模式显然不能将整个庞大的项目管理的井井有条，而软件工程方法论的优势就在这个时候体现出来了。无论是效率还是质量，都一定会得到很大的提升，这一切都是建立在管理的基础之上的，软件工程不仅指导了我们开发的方式和流程，也告诉了我们什么样的项目适合什么样的管理模式，这也是很重要的