这次个人阅读作业是要阅读几篇很长的英文论文，对于英文能力水平不是很强的我来说完全读完这些文章会有很大的困难，所以我阅读了一些中文翻译，以及其他人对于这些文章的点评及看法，从中得到了许多知识及想法。下面是我对这次作业的总结。
一、阅读材料笔记
1. No Silver Bullet: Essence and Accidents of Software Engineering：
这篇文章首先是介绍了软件工程要面临的固有的不可避免的问题，主要是复杂性（complexity），软件整合（conformity），可变性（changeability）和不可见性（invisibility）。
紧接着文章介绍了过去软件开发解决事故性困难的方法，首先是高级语言带来的方便性，高级语言给软件开发者带来的便捷式显而易见的，软件开发者不用再去关心低层的实现而只要在一个抽象的（相对与计算机）但更接近人类思维的层面上去设计软件；其次就是分时，只要分时的频率足够大，在人类分辨能力之上，那么就能取到很好的效果；最后是统一的编程环境，统一的编程环境是的软件开发者都使用统一格式，这样便于软件工作者之间的交流。那能否找到解决软件生产率“怪物”的银弹呢，作者就此展开了讨论。
最后作者讲了下寻找银弹的前途。主要有买VS重建的讨论，其中成本是主要考虑的因素；要求完善和快速成型是软件设计的基础工作，一开始就要设计好；人是软件开发中最重要的决定因素，拥有强大的设计者将使软件开发效率提高好多，作者给出了培养Great designers的明显的步骤。
2. There Is a Silver Bullet – Brad J Cox
Brad J Cox认为这个银弹就是——复杂结构的内部封装，使组件简单易用。Brad J Cox讲解了面向对象技术在软件工程中的应用，将软件封装起来使得开发者可以对其有更好的管理能力，更重要的是用户们可以很方便的使用，用户可以减少那些他所不擅长和需要管理的东西，将复杂软件对用户简单化。因而这被视为一Silver Bullet。
3. big ball of mud
定义：
大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。
缺点：
无法使得系统内的信息得到更好的控制和共享，使得信息失去了应有的价值。大泥球般的系统的整体结构没有得到很好的界定，也就使得大泥球越发的复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。
产生的原因：
首先，程序员在编写程序或是系统时遇到问题后的解决方法，往往不是合适的或者最优的解法，而是方便修改的，变动最小的，这就为以后的系统架构的混乱甚至整个系统的奔溃埋下了隐患。其次，用户的需求或者编程的要求是在不断地变化的，任何一个已有的系统都随之会产生重大的变化，使得系统越来越复杂化，维护也越来越昂贵，另外编写人员的变动等等因素都会导致系统的退化，一步步变为大泥球。
所以，可以将其产生的原因归结为：一次性代码，碎片式增长，缺少前期设计，应对需求和架构变化过晚，程序员的经验，技巧，眼界的限制。
避免或者修改大泥球的方法：
首先，程序员或者设计师为了在预算中并按时交付高质量的软件，就需要关注软件的特性和功能，然后集中在架构和性能，使得软件设计初步就避免产生小的问题或者方向的偏差。其次，程序员在编写软件时要及时的解决出现的小问题或者原型概念等等，这样不会使得问题堆积导致后期的无法修改。另外，应当及时处理用户需求的变化，由于需求往往会随着时间的推移而变化，所以应当逐步的解决，并且鼓励和积极面对变化而不是掩盖问题。另外，要保持一直工作的状态，不断地维护需求和系统。但不应当进行一次彻底的检查，这样很可能会破坏系统。当然，软件系统也是在变化的，但是不同的部分会以不同的速度变化，所以应当使得它们的变化率一致。最坏的结果就是代码已经下降到了无法修复甚至理解的地步，那么就扔掉，重新开始。
4. CatB – Cathedral and the Bazaar
作者先简单说一下什么是大教堂，什么是市集，然后就开始以他开发了一个fetchmail为例子，说明市集是怎么运作的。
简单说来，市集，一般是针对已有的软件进行改进。一般来说，原来这个软件有原作者，有一个固定的使用人群（都是那些开源爱好者）和一些开发维护者。如果这个软件走到尽头，一般都是开发者没有了兴趣和动力。然后可能有另外的人接手，然后根据用户群提出的想法，进行扩展和改进。一般开发中采用“早发布，常发布”的原则，例如作者开发fetch就有二三百个志愿者作为测试人群。市集的测试人员好处是多，而且素质高，能反馈一些高质量的bug汇报，甚至提出修改方案或者补丁。
5. Lost in CatB.
这篇文章中提到了彼得定律：所谓彼得定律，就是说在一个根据人的业绩、成就和价值来提拔人的组织中，最终会把一些人提拔到他们并不胜任的位置上。这个定律经常被通俗地说成“把员工提拔到他们不胜任的职位”。
问中讲述了许多时候设计人员只是把别人的代码粘贴过来，这中间形成了许多链接的依赖关系，导致最终的产品运行起来要寻找很多很多不同的依赖文件，而软件开发是要使软件简洁并且高效，这样的结果违背了初衷。
6. Worse is Better – Richard Gabriel
坏点的更好，强调简单压倒一切，为了简单性，其他方便都可以做出牺牲，包含以下几点：
简单性：设计必须简单，这既是对实现的要求，也是对接口的要求。实现的简单要比接口的简单更加重要。简单是设计中需要第一重视的因素。
正确性：设计在任何值得注意的方面都要求正确。为了简单性，正确性可以做轻微的让步。
一致性：设计不能过度不兼容一致。为了简单，一致性可以在某些方面做些牺牲，但与其允许设计中的这些处理不常见情况的部分去增加实现的复杂性和不一致性，不如丢掉它们。
完整性：设计必须覆盖到实际应用的各种重要场景。所有可预料到的情况都应该覆盖到。为了保证其它几种特征的品质，完整性可以作出牺牲。事实上，一旦简单性受到危害，完整性必须做出牺牲。一致性可以为实现的完整性作出牺牲；最不重要的是接口上的一致性。
7. MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS
瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。
8. Agile Method – by Martin Fowler
敏捷开发方法相对于传统的软件开发方法的一个明显的不同就是敏捷开发是与代码为主的，强调代码是文档的主要部分。相对于传统的软件开发方法，敏捷开发方法有以下的特点：
（1）敏捷开发方法是适应性比预见性更重要；
（2）敏捷开发是以人为本而不是以项目为本。
敏捷开发方法之所以提出适应性比预见性更重要是因为需求的变化往往是不可预见的，因此强调软件开发要有很好的适应性，预见性显得不是那么重要；作者在文中 提出的解决的方法是迭代（Iterations），利用迭代控制不可预见的过程。敏捷开发中提出把人放在首要位置，但是可能会遇到一些问题，但是作者给出 了相应的解决方法，作者提出了程序员要对自己设计的模块负责，描述了管理以人文本的项目的方法，并且提到了商业领导的职责是什么。
二、心得体会
看了这么多的文章之后才了解到软件开发中会有这么多的知识和学问。我在上学期学了面向对象编程思想之后，自己做了几个小项目，很多时候都是网上找到的代码进行拼凑，出现过大泥球的情况，但是后来我通过不断细心的调试最终解决了这些问题。因为工程量不是很大，也出现过直接把之前所有的代码扔进回收站，自己重新新建一个工程重新写的情况。
我之前软件开发的时候基本是我自己一个人在写代码，让其他的组员或者别的人给我提一些意见，没有经历过几个人在一起团队开发。在做冯如杯的时候我基本就是用一大堆代码拼凑起来，最后导致依赖的库很多，软件运行的效率非常的低。
在此次的团队开发中，我们团队选择了我的一个创新的想法，并开始做这个项目。团队中我算是编程能力最强的了，也基本上得靠我这个项目才能进行下去了。在这过程中我学到了许多的新的知识，比如说MVC框架以及服务器端开发的许多思想。我完成了我们项目所需服务器端的代码，目前我正在进行客户端的开发以及调试。
通过阅读这些文章，我又学到了许多团队开发中可以运用的知识。希望今后在项目中可以学到更多！