No Silver Bullet: Essence and Accidents of Software Engineering

在欧洲中世纪的传说中，有一种叫“人狼”的妖怪，就是人面狼身。它们会讲人话，专在月圆之夜去袭击人类。而且传说中对“人狼”用一般的枪弹是不起作用的，普通子弹都伤不到也打不死它，只有一种用银子作成的特殊子弹才能把它杀死。Brooks在他最著名的随笔文章《No Silver Bullet》里引用了这个典故 ，说明在软件开发过程里是没有万能的终杀性武器的，只有各种方法综合运用，才是解决之道。而各种声称如何如何神奇的理论或方法，都不是能杀死“软件危机”这头人狼的银弹。他当时大胆声称并预言方法学家们10年之内绝找不到什么极好的的神奇银弹。

现代软件四个无法回避的本质问题：复杂性，一致性，可变性和不可见性。复杂性指的是软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的；不可见性指的是尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难；统一性指的是在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难；易变性指的是软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。

在过去，软件工程领域的几大突破：高级语言、分时系统和统一编程环境。

这些突破部分解决了一些问题，但是大型软件开发的困难度依旧很大。作者列举了一些可能成为“银弹”的技术，比如模块化编程、面向对象编程、人工智能、专家系统、自动编程、可视化设计、程序验证、环境和工具、工作站。

上学期我们学习了面向对象课程，初步接触了软件开发，了解现实抽象到代码中的过程。编程时，要注意抽象各个实体间的联系，减少代码量。而且大型软件工程要多人进行，各个类之间的交互要设计好，成员之间的代码要能结合起来。对于可视化编程，像VS和Eclipse都支持灵活的编程方式，可以拖动组件，也可以自己在代码中设定组件。

但是，这些都不能从根本上简化程序设计的复杂性，目前本质性的问题仍然无法解决。这学期体会了团队编程，感觉对于工程进度很难把握，各个成员技术实力和分配到的任务难度较难协调，导致部分成员的工作时间不同。

There Is a Silver Bullet

本篇作者对于软件开持乐观态度，认为软体危机是必然会面临的的困境，但并非是无法克服的。

当全球经济进入资讯时代，市场对资讯殷切需求而产生的经济诱因，将促成人们社会中的文化改变。加上目前遭遇的软体困境：成本过高、品质不良、以及人们无力去改善它们。使得人们对软体的看法和思维产生巨大的变迁，人们开始看重面向对象编程。在新环境中，软体的价值体系、权力结构、以及软体师与消费者关系重新定位；彻底从过去重视程式的撰写过程转而重视组件价值、拥有、及买卖系统等基本文化要素、而导致软体产业的革命。把组件的复杂封装起来，对使用者而言，调组件再也不复杂了。使用者无需了解内部构造，只需要使用相应组件即可。人们不再受困于组件内程式撰写的复杂，而专注在组件本身的使用、价值和买卖上。同时作者作了更远的展望：非文字的编程，可以使每个计算机的使用者都成为编程者。

Big Ball of Mud

大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑。引用吴际老师的话就是一个“面条程序”。产生大泥球的原因可能是程序员在编写代码时，而是为了代码完成的效率，编写一次性程序， 没有考虑整体的模块化。或者在编写过程中不断更新新的功能，导致煤球越滚越大。在学习面向对象编程以前，我就是在编写泥球。整个代码只有一个主程序。对于简单功能的程序来说，没什么。但是对于一些功能比较复杂的软件工程程序，如果没有对代码进行很好的整体设计，会造成功能混乱，调试效率低，测试效率低等缺点。泥球使得系统内的信息难以得到更好的控制和共享，使得信息失去了应有的价值。大泥球般的系统的整体结构没有得到很好的界定，也就使得大泥球越发的复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。

对于这次的软件工程团队作业，我深有体会。学长的代码基本上符合面向对象的要求，但是个别类如DownloadFile类，这个类的run方法实现了网站访问，本地文件下载以及数据库更新这三个核心功能，导致代码过长，而且难以维护。我们在修改时会尽量修改代码结构，减小煤球。

The Cathedral and the Bazaar

本书讨论两种不同的自由软件开发模式︰

大教堂模式︰原始码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。 

市集模式︰原始码在本模式也是公开的，不过却是放在因特网上供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。

这篇文章的要义是让够多人看到原始码，错误将无所遁形。

         虽然书上这么说，但是我们这次软件工程开发是按照大教堂模式的，因为每个团队都有自己的项目，很少有人会关注其他团队，而且我们组实现的是网络爬虫，核心功能比较单一，而且实现方式也较单一，没必要放在网上供其他人员开发。而且对于一个小的应用软件，一个小的团队更便于交流。

A Generation Lost inthe Bazaar

本文批判了滥用集市模式的人们，代码不加修改的重用，编写代码时不去探究代码精髓，直接简单引用，造成了代码质量越来越差

         我在本次软件工程负责处理爬取内容的柱状图动态显示。一开始我只是简单引用了网上的现有代码，发现效果不是很好。柱状图的显示范围不符合实际。部分冗余数据应该去除，而且柱状图的显示窗口不能调节大小和

显示位置。于是我仔细学习力JFreeChart的相关函数，对原有代码进行了修改，使得代码符合我们团队的要求。

The Rise of "Worst is Better"  & Is Worse Really Better?

作者提出了普遍认为是“好”的设计原则：

1. 简单性：在实现和接口中，设计必须简单。接口的简单性比实现更重要。
2. 正确性：在所有可观察的方面，设计都必须正确。一丝的错误都是不允许的。
3. 一致性：设计不能不一致。为了避免不一致性，可以稍微减少一些简单性和完整性。一致性和正确性同样重要。
4. 完整性：实际上，设计必须覆盖许多重要的情况。应该覆盖可能出现所有情况。简单性不可以过度地削弱完整性。

他又提到了“更坏是更好”的设计原则：

1. 简单性：在实现和接口中，设计必须简单。相对于接口而言，实现的简单性更为重要。简单性是设计中最重要的注意事项。
2. 正确性：在所有可观察的方面，设计都必须正确。正确性的重要程度仅次于简单性。
3. 一致性：设计不能过于不一致。在某些情况下，为了实现简单性可以牺牲一致性，但放弃设计中处理非常见情况的那些部分比引入实现复杂性或不一致性更好。
4. 完整性：实际上，设计必须覆盖许多重要的情况。应该覆盖可能出现所有情况。为保证其它质量，可以牺牲完整性。实际上，只要危害到实现简单性，就必须牺牲完整性。如果保证了简单性，可以牺牲一致性以实现完整性；尤其是在接口的一致性没有价值的情况下。

Unix和C在设计上，充分考虑了实际环境，而放弃了一些一致性和完整性，保证了简单性。这点让C和Unix在历史的选择中胜出。C++也是如此。作者以此为例证认为实现简单的优先级更高。

但是在第二篇文章中作者对之前的观点进行了反思，实现简单也可能造成结构的混乱。

Managing the Development of Large Software Systems

         这篇文章主要是介绍了“瀑布模型”。作者总结了自己在软件开发中的经验，提出了一个软件项目的开发架构，开发过程是通过设计一系列阶段顺序展开的。

瀑布模型主要分为下面三个阶段：

1.定义期：“分析重于设计，设计重于编码”，因为差错产生的越早，后面纠正差错所花的成本越高。

2. 开发期：该阶段实现系统的详细设计和具体应用程序的开发。需要系统设计人员和软件开发人员的大量工作，同时，用户必须有效地参与设计过程。

3.维护期：维护是系统生命周期的最后一个阶段，也是持续时间最长、付出代价最大的阶段。前面各阶段的细致工作，其中一个目的就是为了提高系统的可维护性，降低维护的代价。

我们的团队项目主要是在学长代码的基础上进行的，所以我们可以省去定义期。但是由于学长已经基本实现了爬虫的基本功能，所以我们在设计期就花了好长时间思考该增加什么样的功能。我们的开发是边开发，边维护，所以我们将开发期和维护期合并在一起了。

The New  Methodology

         当前，传统的软件工程方法越来越难以适应迅速变化的需求。近年来出现了一类新的轻量级的软件开发方法，它们被统称为敏捷型软件开发方法。在所有敏捷开发方法中，XP 是最引人注目的。

早期的时候，多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改”。软件行业中最初的一场运动是要改变这种情况，而引入了“正规方法” （methodology〕的概念。这些（正规）方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践 － 因此我把它们称为工程方法（engineering methodologies）。工程方法已存在了很长时间了，但是没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。而敏捷型方法（agile methodologies）的发展是对这些工程方法的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。

我们团队在开发中保持两天一次scrum meeting的习惯，这样有助于团队成员及时完成任务，便于PM管理项目。而且我们的开发人员的寝室都很近，我们可以及时交流，主要是面对面交流，这样有助于我们及时改正程序出现的问题，也便于协调成员间的任务进度。

Why Software Development Methodologies Suck

本文主要讨论了工程方法论和敏捷方法的选择上。我比较赞同作者的观点，对于不同的软件要根据实际情况指定编程方法。盲目套用是不会成功的。

大作业心得总结

1. 团队交流：团队成员要经常交流，互相了解各自任务进度，而且能起到相互督促的作用。
2. 代码编写：写出的代码要尽可能的可移植，做到汇总代码时不需要对版本有太多修改就能成功移植。而且对于自己编写的可能与其他类交互的代码要清楚注释，便于他人阅读。
3. 任务进度：PM要常与团队成员交流，及时了解任务进度；同时做好和学长的交流以便于一些问题的解决。
4. 需求分析：我们要多查资料，因为我们是在学长的基础上修改的代码，学长已经基本实现了爬取功能，我们要改进，就应该多了解爬虫的功能以及类型，便于对功能的扩展。

个人阅读作业2