Silver Bullet：

中心思想就是软件工程这游戏真难玩。

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

作者观点悲观却也抱有希望，列举了一系列他认为潜在的银弹，这些东西的出现已经对软件工程的复杂性有了一定的缓解作用，而且还可能进一步发挥他们的功效。比如模块化编程、面向对象编程、人工智能、专家系统、自动编程、可视化设计、程序验证、环境和工具、工作站。

         模块化编程、面向对象编程、可视化设计这些都是这学期软件工程开发过程中我有切身体会的，将要做的任务抽象化的过程，就是要把一个个实体抽象出来分成不同的模块之间分别管理，模块之间尽量做到低耦合，高聚合，还有就是做前端设计的时候xml的使用，visual studio里拖动toolbox里的控件开发c#的图形界面，或者在Eclipse里拖动控件开发java的图形界面，这些是图形界面开发，大大地便利了图形界面的开发。

      当然，这些都不能从根本上简化程序设计的复杂性，这不仅仅是开发的整个过程中都需要对需求分析进行必要的修正，同时遇到了对象或者模块之间的难以调和的矛盾的时候也很影响开发进度；同时单元测试的用例设计也是比较头疼的问题，需要考虑到不同的情况，还有尽量的覆盖代码的各个分支，最主要的是我们无法拿到广大用户使用的反馈，而软件工程最大的复杂性在于具体性，在于具体实现和具体用户的使用，这些具体的因素又是不确定的，是多样化的。这又涉及到软件维护的一系列问题，整体上来说就是虽然有希望，但是软件开发的整个过程会非常艰难，目前本质性的问题仍然无法解决。

There Is a Silver Bullet:

         这篇的作者相对来说观点相对乐观。

上一篇文章一直把焦点集中在生产力，也就是软件每单位的输入成本能得到多少输出效果。作者则更多的把重点放在品质上来讨论问题。他认为软件工程问题的终极的解决方案是基于复用和互换的软件工业革命，这点我比较赞同，现今的大多数的软件开发都是在山寨的基础上进行微创新，当然独立创新的成功例子也数不胜数，但是相对与复用前人的代码来说，这样的成本高而且最终结果也并不一定能够表现更好。

作者还说面向对象应将注意力从构建对象转移到研究对象本身，从而更大的开发每个对象的潜能，脱离面向过程思想的桎梏。

Big Ball of Mud:

大泥球实际上就是指一堆结构杂乱无章的代码，就像我们刚学c语言时候写的面条程序。大泥球产生的原因可能是由于编写的是一次性代码；也可能由于用户需求的不断改变，程序员在不断修改程序的时候将原有程序变得更为复杂，将原本设计良好的架构拆散，使程序变成一个大泥球。

因此，为了避免程序最后变成一堆混杂的代码，应该在编码前期尽可能将需求分析透彻额，搭好整个框架，在修改代码时也尽可能的考虑整体架构，遇到不得不拆散某些架构的时候也不能手软，要把需要推倒重做的地方推倒重做。除此之外，想要从根本上解决大泥球的问题，还是要有一些切实可行的方法。比如开发中步骤的先后顺序，制定计划，写scrum meeting，画燃尽图，让开发者充分明确自身的任务，实时了解当前的进度，同时团队内部需要多沟通，需要PM进行合理时间规划和任务分配。整个开发过程中都应该时刻把程序的总体设计架构逻辑放在首位，避免大泥球的产生，造福未来需求变更后的修改与二次开发。

在我们的团队项目中，大泥球的征兆并不明显，倒是有不少的小泥球。因为我们做的是修改上一届学长的爬虫并添加和完善功能，而学长们的程序总体架构还是不错的，但是每个分开的模块本身会有部分的程序逻辑有问题或者零碎的几个模块之间耦合性略高，所有整个开发的最开始便是修正学长程序本身存在的一些bug以及完善或者修改其程序内部的一些逻辑，降低模块之间的耦合度，同时有了这些经验，在我们接下来的开发中我们也一路避免着大泥球的产生，添加的模块也和现有的模块保持着低耦合、高聚合的性质。

The Cathedral and the Bazaar:

这篇文章讨论的是cathedral和bazaar两种软件开发模式，即大教堂模式和市集模式。

大教堂模式指的是源码在软件发型后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的，例如linux下著名的编译器gcc。市集模式指的是源码在开发过程中即放在因特网上供人检视及开发，例如linux核心的过程。

大教堂模式的软件开发让程序修改自身bug的时间大幅增加，因为只有少数的开发者可以看到源码，参与修改工作。市集模式则相反，大家都可以看到源码并对开发中的软件提出意见，这无疑便利了软件的开发和测试，开发者能轻易地收集到不少的用户反馈，使得更加以用户为中心，满足用户的需求。

我们的团队项目目前是以大教堂的模式进行着开发，因为进行市集模式的话，对开发者本身的素质也有要求，假如自己开发的软件本身质量十分上乘，自然会有很多人给你献言献策，同时自己也有能力满足用户的一系列需求，就行python语言或者linux内核的编写那样；而我们团队是在维护学长的程序，直接把源码公开在网上的话得到的回应也并不多，而且得到的回应也可能并非是专业人士的意见，盲目听取的话反而会南辕北辙，并不一定会比团队内部进行会议协商和测试修改等工作取得更好的效果。而我们的代码只在团队成员内部不同模块由不同的人进行管控，使得开发时间有所延长。

lost in catB：

这篇文章就是作者在批判性的讨论了市集模式下开发的缺点。一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着，粘贴着。作者如是说。代码频繁的被重用但是没有经过适当的修改，使得重用部分有各种冗余也可能有缺陷，并不是最适合工程的代码，仅仅靠拿来主义写出的代码质量只可能越来越差。

         除此之外，作者提出了大教堂模式的优点：少数几个人对某个模块负责的时候，质量这个词才有意义，市集模式下开源软件可能变得一团糟，而大教堂模式更加规范更加安全保险，团队内部负责并且沟通，同时也可以在软件发布之后征求用户反馈在下一版进行必要的优化。

　　而我们团队开发时候正是利用了大教堂的模式的优点，每个开发成员各自负责各自的模块，并且大家都有一定的专业能力和学习能力，团队之间进行必要的交流与规范制定，不会出现市集模式那样的惨状。

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

MySQL的数据库特性绝对不如PostgreSQL/Oracle，但是市场占有率遥遥领先；MacOSX操作系统的优秀毋庸置疑，但是Windows是绝对的霸主；baidu的搜索引擎被google甩了几条街，但是国内基本没有人用google(误)。

这篇文章作者主要讨论的是实现简单和程序正确性的优先级的选择，总体来看，简单性是设计中最重要的；正确性的重要性仅次于简单性；然后就是设计的完整性。

Managing the Development of Large Software Systems：

本文主要介绍了瀑布模型：

　　瀑布模型将软件生命周期分成了六个阶段：制定计划，需求分析，软件设计，程序编写，软件测试和运行维护。它规定了软件开发的顺序自上而下、相互衔接的固定次序，如果有信息未被覆盖或者发现了问题则返回上一阶段查找问题并进行适当的修改。

优点是：为项目提供了按阶段划分的检查点，当前一阶段完成后，您只需要去关注后续阶段；在增量开发的过程中，一般需要做单元测试，单元测试又需要做回归测试，而瀑布模型的循环反馈的工作就等于是做了测试的工作，更加保证程序的正确性。

缺点是：各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；每个阶段的测试工作也给程序员带来压力，上游的程序员必须尽早完成任务和测试，从而可能产生质量低下的代码；由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险；最大的缺点是不适应用户需求的变化，不适合经常会变化用户需求的开发。

The New  Methodology：

在本文中，作者注主要介绍和讨论了敏捷开发与工程化方法。主要提到的有XP（极限编程）、scrum、水晶系列开发方法（crystal）、相关环境驱动测试（Context Driven Testing）、精悍开发（Lean Development）、Rational Unified Process等。

我们团队在开发中应用了scrum meeting的方法，每天都有scrum meeting的发布，并且绘制燃尽图来表示我们团队当前的项目进度；同时我们的团队项目应用了其中的一部分方法，包括经常交付、反思改进、渗透式交流等；在团队内部，使用最具有效果并且富有效率的传递信息的方法：面对面的交谈；开发者和测试人员能够保持一个长期的、恒定的开发速度，团队PM会持续的督促开发者按时完成自己的工作。

Why Software Development Methodologies Suck:

       文章中主要讨论了一些软件工程方法论不起太大作用的原因以及提升软件价值的两种方法：划小开发周期以及提升反馈效率。

      而软件开发方法论之所以不起太大作用，一是由于迅速变化的需求使得方法论无法适用于全部的情况；二是测试数据的选取往往也是不具备代表性或者是缺乏说服力的，即使选取的测试数据很多；最后就是开发人员的学习能力和开发能力参差不齐，合作时候的投入程度也不相同。

      评论中有很多人对作者的观点表示赞同。我也赞同作者的观点，因为方法论并不是普适性的，遇到具体情况需要具体分析，比如在项目人员的选择上，多数时候根本轮不到技术人员说话，谋略和策略的产生主要是由大权力的管理层来完成的。

心得总结：

开发过程中的注释一定要写，而且一定要写明白；我们负责修改学长的代码，而学长的代码本身的注释又十分少，对我们的代码阅读造成了一定的障碍，考虑到我们的代码可能还会给下一届的学弟们继续维护修改，所有我们要把注释写的全面、清晰、正确，方便后边的开发维护人员的工作。

需求分析要透彻，明确在现有的代码基础上如何进行最适合的改动才能满足需求，涉及到整体代码架构修改的地方先进行团队成员间的讨论，然后在进行大刀阔斧的修改，这样可以尽量避免整个工程代码呈碎片式的增长，不让手中的程序成为一个大泥球。

　　在团队协作方面，最重要的是面对面的沟通，在开发过程中PM一定要时常保持开发者和测试人员以及开发者之间的交流。PM时刻要督促整改团队保持一个长期恒定的开发速度，从而更快更稳的进行开发。

个人阅读作业2