个人阅读作业+总结
助教推荐的那些文章都是软件工程上的经典文章，阅读后感受到软件工程本身的深度，之前学习的软件工程都只是皮毛之中的皮毛而已。随着软件规模的越来越庞大，软件工程已经成为了软件开发中的必备知识。在软件工程中有很多前人的思考和经历在其中，细细品读下来还是十分有趣、有用的。
No Silver Bullet - Essence and Accidents of Software Engineering - Brooks
所有的软件在构建过程中都会遇到根本性的任务：组成抽象软件实体的复杂概念，防不胜防的意外以及在一定的时间和空间限制下，从抽象的软件概念到具体的编程语言乃至机器语言的编码过程。作者提到几乎大部分高效的软件生产性的获得需要人为的想一些方法将意外的任务尽可能减少。他将软件比喻成西方神话中可怕的狼人，将一劳永逸的解决方案比喻成为唯一对狼人有效的银弹，并在文中叙述软件工程中并没有这样的一个“银弹”，能让人高效管理软件工程而不出半点差错。但他也提出了一些方法，虽然不能达到“银弹”的级别，但多多少少对软件的管理有较大的帮助：
- 积极探索巨大的市场以避免重新制造可以买到的轮子；
- 将快速的原型作为迭代计划中的一部分来满足软件的要求；
- 增量开发，对于软件的新功能、测试等等需求做增量开发，向系统中添加新的过程和函数。
- 物尽其用，善用人才。
big ball of mud
虽然高度关注高级软件架构模式，但事实上标准的软件架构实际上很少被讨论。一个大球泥是一个随便的，即使是随意的，结构化的系统。在实际开发中，我们往往为了追求更多的功能不加设计的添加代码使得软件整个结构越来越臃肿最终导致成为一个完美的大泥球，使得在上面开发或者维护的成本极其高，任谁也不想也不能在上面进行有效的开发。
- 大教堂模型中，每个软件版本都提供了源代码，但在两个发行版之间开发的代码仅限于一组独立的软件开发人员。以GNU Emacs和GCC为例。
- 集市模型，在该代码开发了互联网鉴于公众。Raymond 称Linux内核项目的领导者Linus Torvalds是这个过程的发明者。雷蒙德还提供了他自己实现这个模型的Fetchmail项目的传闻。
在我们的开发中，目前使用的开发过程更合适的模型描述是大教堂模型。开发软件过程中并没有使用互联网进行“集市”一般的开发，一般都是自己或者几个人固定进行开发。
Worse?Better?
有了正确的事情，设计师同样关心简单性，正确性，一致性和完整性。随着越来越好，设计人员几乎完全关注实现的简单性和性能，并且只在正确性，一致性和完整性方面工作，只是为了完成工作，为了简单起见而牺牲了其他任何品质。然而，这个论点是，使用越差越好的程序设计和实现的程序可以比正确的版本更快地写出来，可以运行在更广泛的计算机上，容易携带，如果足够好，将被接受得更快，最终将得到改善，并且一般来说，比右派方案表现出更好的生存特征。更糟糕的是程序就像病毒一样迅速传播，很快普及。随着时间的推移，如果他们成功了，
他们会得到改善。
具体来想我认为作者提出的更加糟糕的软件指的就是软件首先不论质量怎样需要尽可能快速的实现需求并发布，并进行快速的迭代更新以达到最后的好的质量。这样可以在市场上占有先机更容易获得成功。而正确的就进入市场晚可能获取成功需要的努力就更大。
敏捷！
- 敏捷方法是适应性的而不是预测性的。 工程方法倾向于在很长一段时间内详细规划软件过程的大部分内容，直到事情发生变化，这种方法运行良好。 所以他们的本性就是抵制变化。 敏捷方法，但是，欢迎改变。 他们试图成为适应和改变的过程，甚至改变自己。
- 敏捷方法是以人为本而不是以过程为导向的。 工程方法的目标是定义一个恰当地使用它的流程。 敏捷方法断言，没有一个过程能够弥补开发团队的技能，所以一个过程的作用是支持开发团队的工作。
我们在实际开发过程中其实使用到了敏捷的一些思想，比如快速迭代，在每一轮迭代之间收集用户反馈以达到一个方向的修正；是事情驱动的，刚开始做完初步的设计后随着事情的变化快速修改设计并再开发。
