一开始看到阅读作业的时候我感觉老师给的时间还是很充裕的，但是在阅读的过程中我还是感觉不是很充分，其中一个很重要的原因就是由于自己的英语水平有限，在阅读的过程中需要经常性的去查单词，造成阅读中的一些中断，以至于思维不是很连续。但是还好，由于时间较充分且我开始的较早，这一个问题还是被自己克服了，没有造成太大的影响。
首先我先说一说自己对于这些文章的理解吧。
第一篇文章是No Silver Bullet: Essence and Accidents of Software Engineering。在这篇文章中，文章的第一句就告诉了我们什么是银弹：只有银弹才能够杀死狼人，所以银弹又被引申为最有效解决问题的方法。那么，软件工程是否有捷径能够让软件的花销像计算机硬件那样可控的减少呢？作者认为软件开发中没有银弹。或者说，作者认为十年内（1986年起），不会有任何单一突破使得程序设计的生产力有数量级的增长。原因是软件开发中的两大困难：本源性困难和偶然性困难。本源性困难，来源于现代系统软件的复杂性，一致性，易变性和不可见性。偶然性困难从字面上就很好理解了。作者认为前人曾有很大突破，但大多是在偶然性问题上的突破。本源性的难题有着天生的局限性。但是在某种程度上，我并不能完全认同作者的观点。软件工程这一概念的出现，是程序设计的生产力巨大发展的体现。这种开发模式在最初必然是难以想象的。同样的，我们现在所熟悉的软件开发模式，是不是存在着这样的一个银弹，就像软件工程相对于旧的软件开发模式一样，会对软件开发产生革命性的改变？问题的产生同时就在暗示人们解决问题的方法，或许我们会有一种新的软件开发模式或方法也未可知。所谓的天生的局限性或许是因为我们理解的浅薄或错误。积极的态度十分重要。文章最后说了一些解决方法，但大多是管理上的。
紧接着的下一篇文章，作者又想要阐述有银弹这一观点。。。查单词和上一篇文章的观点让我现在有一点混乱。。。等我整理一下再写。。。现在我需要整理一下我快要崩裂的世界观和人生观。。原谅我。。
下一篇，大泥鳅。。不，大泥球的故事（这几个字在搜狗太难打了。。）什么是大泥球？杂乱的，满眼的，面条式的代码，随意的结构化的软件体系结构。（面条式代码这几个字一下子让我回到了面向对象编程的课上。。老师无数次强调要避免面条式编程）从上述的几个形容词我们可以很明确的看出来，大泥球代码结构散漫，这很明显是要避免的，但是由于软件工程的一些特点和一些普遍的状况，结构散漫常常发生。程序员之间的相互了解，个人水平的不同，对人物理解的差异(好可怕。。。）经验的缺乏等等等等都会导致问题的产生。但同时，我认为大泥球是可以避免的。良好的管理和沟通，良好的架构，开发时期的及时沟通以及专业的训练都会有一定的帮助。这篇文章很长，至少对于我来说比较难看懂。对于问题的理解可能会有一些不太恰当的地方，有时间我想还要再读几遍。
关于大教堂和市集，两种自由软件开发模式，大教堂的软件版本由其开发团队拥有，市集模式则是在互联网上完全公开。相信提到这个很多人和我一样都会想到linux。文章中也提到了这个例子。我想用windows和linux来对比一下。其实linux和windows都是很成功的产品，但是同时linux在某些方面确确实实要比windows做的好一些。但同时我们也可以看到iOS和Android之间的对比。Android开放使得某些方面比IOS更加困难，很多方面质量也难以保证。两中方法孰优孰劣，难以定论。一种理想的方法是集两家所长，但很难做到。
这次的阅读对比真的很多。。。下一篇，在集市中迷失的一代。额。。想法和上面的差不多，不再赘述了。看了这么多脑子快不够用了。。
worse is better。。哲学意味好重。。什么是好的设计原则？简单，一致，正确，完整。下面具体解释一下。
简单性：在实现和接口中，设计必须简单。接口的简单性比实现更重要。
正确性：在所有可观察的方面，设计都必须正确。一丝的错误都是不允许的。
一致性：设计不能不一致。为了避免不一致性，可以稍微减少一些简单性和完整性。一致性和正确性同样重要。
完整性：实际上，设计必须覆盖许多重要的情况。应该覆盖可能出现所有情况。简单性不可以过度地削弱完整性。
他又提到了“更坏是更好”的设计原则：

简单性：在实现和接口中，设计必须简单。相对于接口而言，实现的简单性更为重要。简单性是设计中最重要的注意事项。
正确性：在所有可观察的方面，设计都必须正确。正确性的重要程度仅次于简单性。
一致性：设计不能过于不一致。在某些情况下，为了实现简单性可以牺牲一致性，但放弃设计中处理非常见情况的那些部分比引入实现复杂性或不一致性更好。
完整性：实际上，设计必须覆盖许多重要的情况。应该覆盖可能出现所有情况。为保证其它质量，可以牺牲完整性。实际上，只要危害到实现简单性，就必须牺牲完整性。如果保证了简单性，可以牺牲一致性以实现完整性；尤其是在接口的一致性没有价值的情况下。
以上部分由于自己理解问题查阅了一些资料。
个人的理解，理论在实际应用中总要有一些妥协来迎合实际的情况。关于简单性和正确性的问题，个人坚持正确性更加重要。或许有因为自己接触软件工程时间较短的原因。
瀑布模型，借一下文章中的图

瀑布模型的特点就是通过设计一系列阶段顺序来开始一个项目，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
但同时我注意到，在瀑布模型中，每个阶段之间反馈很少，并且在项目的后期才能够看到我们所作出的结果。同时，时间上安排的比较死。
敏捷开发强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重作为软件开发中人的作用。而极限编程作为敏捷开发方法的一种，它是一种全新的、生机勃勃的软件开发方式。它的的出众之处在于兼顾了质量的两个方面，即满足客户期望的同时，降低缺陷的数量，同时这种方法颠覆了复杂性不断增加的循环。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
由于各种大作业的到来，最后几篇文章读的比较粗略，思考的也比较表面。有机会还是要继续研究一下。
下面说一说在软件开发中的心得吧。个人项目来说，虽然最后效率一般，但是还是做出来了。敏捷开发的一些思路在这次的开发中我也有所运用。比如说我把一个应用的功能进行分解按照模块来实现。同时，相比于后面的pair work和team work，我的感受是个人项目的操作要相对简单一些（相对于一些简单的开发）。时间上，进度上，由于只有一个人在安排与实现上会更好控制一些。但是思路较窄，效率相对也较低。
pairwork是我在编程中第一次尝试多人合作。不得不说问题很大。首先我们两个之间相互并不了解，其次是进度的控制上由于监督的缺乏最后失控了。导致结果很失败。但是这也给了我们一个深刻的教训。也让我们对软件开发有了不一样的认识，最重要的是体会到了规划的重要性以及沟通的重要性。
team work木前还没有完成，但是在开发过程中我已经有了很深的体会。首先。。沟通！！文档！！ 注释！！！看别人的代码好痛苦。。。其次，PM很重要。团队的沟通，进度安排之类的真的是很重要的一节。在开发过程汇总，我们目前采取的是敏捷开发的模式，但是就我们目前的交流，我好像已经看到了一条大大的泥鳅。。哦不，一个大泥团。。。我希望我们能够尽快解决这个问题。。

第二次阅读作业