个人阅读作业2

1.No Silver Bullet: Essence and Accidents of Software Engineering

　　IBM大型电脑之父Fred Brooks发表的一篇论文。Brooks认为软体专家所找到的各种方法皆舍本逐末，解决不了软体的根本困难——即概念性结构(conceptual structure)的复杂，无法达到概念的一致性，软体自然不亲切不好用！  

　　对于软件工程项目，看似简单明了的东西也有可能变成一个落后进度、超出预算、存在大量问题的怪物，而我们在寻找银弹，寻求一种可以快速解决问题的方式，可以降低成本，快速提高生产力的尚方宝剑。而该论述中强调真正的银弹并不存在，在10年内无法找到解决软体危机的尚方宝剑。

　　作者在文中将软体的困难分为概念上的根本困难与表达上的困难，也列举了些曾经的银弹，并提出了针对概念上根本问题的方法。

　　概念上的根本困难是从软件本身要解决的问题衍生而来，构建抽象软件的复杂概念结构，并无法被移除。表达上的困难是人们本身产生的，构建程序上的困难，可以被解决，如利用高级语言，面对对象思想编程。而软件工程面临的问题在于我们已经清除了大部分的次要问题，而剩余的主要问题都无法改变。

　　软件开发人员为客户所承担的最重要的职能是不断重复地抽取和细化产品的需求。事实上，客户不知道他们自己需要什么。他们通常不知道哪些问题是必须回答的。现在的技术中最有希望的，并且解决了软件的根本而非次要问题的技术，是开发作为迭代需求过程的一部分——快速原型化系统的方法和工具。

　　最后作者还提到了如何提高软件行业核心——设计人员。

　　的确，在软件开发时，会遇到许多小问题及需求，看似简单，但是在真正去实现时候会发现困难无比。这是由于现实世界与计算机世界的转换困难。这也正是我们设计者需要重点考虑的地方，只要概念模型能构建起来，如何去实现是比较容易去解决的问题。

2.There Is a Silver Bullet – Brad J Cox

　　这篇文章看标题就知道是和第一篇相对的。OO大师Brad Cox针对Brooks的观点而发表的文章。说明他找到了尚方宝剑——复杂结构的内部封装，使组件简单易用。Cox 针对Brooks所提的软体困境所在，Cox从新的观点来阐释之，而得到乐观的结论。

　　软体组件类似于硬体的晶片(IC)一般，把组件的复杂封装起来，对使用者而言，调组件再也不复杂了。因之，建立软体晶片市场，让人们不再受困于组件内程式撰写的复杂，而专注在组件本身的使用、价值和买卖上，软体的复杂和困难就自然烟消云散了。因此，文化和思维的变迁将是一把尚方宝剑，能克服软体的困境；而且这种变迁是即将来临的，并非海市蜃楼！    

3.big ball of mud

　　大泥球，意大利面条式代码，代码的杂乱无章，随意堆砌拼凑，会产生不少错误或代码缺陷。程序员总是在方便修改的地方写入一些一次性代码来修复bug，虽然方便快捷，但是这样会为后续程序的修改产生其他bug隐患，当系统越来越复杂，这样的隐患累计起来就能形成大泥球了。

　　避免大泥球是需要我们去注意的地方，程序员和设计师应先关注软件的特点和功能，然后再关注构架和展现，设计初步避免产生小的问题或者方向的偏差。编写软件时要及时的解决出现的小问题或者原型概念，及时处理用户需求的变化。

　　目前暂时没发现大泥球，也有可能是项目规模较小，小细节的问题暂时没被发现，但我们团队开发人员都有一定的编程规范，在必要的地方也写明注释，模块接口一致，保持封装，保持代码整洁，尽可能减少大泥球的出现。

4.CatB – Cathedral and the Bazaar

 　　The Cathedral and the Bazaar，“大教堂”和"市集"指两种自由软件开发模式，即它们都是源码公开的。其区别是大教堂模式的每个软件版本由一个团队掌控，市集模式则是完全在互联网上公开源码。

　　我们团队 负责学霸pipeline项目的开发，是大教堂式开发。将源代码掌握在熟悉的几个开发人员手中，对于这样的小项目，效率较高，并能在短时间内获得较好的进展。

5.Lost in CatB.

　　市集式开发提供了更广阔的平台但同时也引入了更多的良莠不齐，质量难以保证。就像我们在市集买的一些东西，用那么一两次就坏掉。商家对此也不会负责。就像Brooks提到的Quality happens only when someone is responsible for it。这也正是作者说提到的市集式开发弊端。

6.Worse is Better – Richard Gabriel

　　quality does not necessarily increase with functionality 质量不一定会随功能而增加，更少的功能可以获得更好的实用性和可用性，软件的能力有限，但是简单可用，能更加吸引用户和市场。

　　简单的设计、实现和接口，且设计要正确、一致、全面。

7.Managing the development of large software systems: concepts and techniques

　　瀑布模型，项目开发架构，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈。

　　定义阶段，可行性研究和需求分析；开发阶段，设计、编程、测试；维护阶段，运行维护。

　　用工作的顺序将问题简化了，将功能实现与设计分开，方便分工协作，将软件项目生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。当前一阶段完成后，您只需要去关注后续阶段。

8.Agile Method – by Martin Fowler

　　讲的是敏捷方法， Extreme Programming，scrum等都用在我们的项目上。敏捷开发给予我们项目轻量化的优势，提高开发效率和响应能力。

　　没有正确的方法，优秀的团队和先进的技术并不能保证项目的成功。虽然brooks指出人们至今尚未找到能够制服软件危机的本质问题的银弹，但引入了软件工程的思想，把其它工程技术研究和开发领域中行之有效的知识和方法运用到软件开发工作中来，提出了按工程化的原则和方法组织软件开发工作的解决思路和具体方法。软件工程在一定程度上缓解了“软件危机” 。