阅读作业+总结
大泥球
软件是一个复杂的工程，而在之前没有经过细致的考虑以及好的架构设计，会使得代码杂乱无章，需要修补的地方也会比较多，最后代码越多也就越乱，之后便形成了大泥球。
我们工程项目一开始是有这种趋势，就是在刚开始的时候没有做足够的计划，代码复用的比较多，经常改一点代码，其它部分的也要修改，不过后面通过一些工具进行分块管理就没有出现这样的情况了。
教堂与集市
1、什么是大教堂？什么是集市？
- 教堂：每个软件版本都提供了源代码，但在两个发行版之间开发的代码仅限于一组独立的软件开发人员进行开发管理。
- 集市：整个过程都是公开的。
2、你的团队是用什么方式建造软件？
大教堂方式
3、这些情况在你的团队中出现过么？
没出现过，虽然在软件开发的过程中会用到各种各样的开源代码，也会有依赖，但是没有出现混乱的情况。
Worse?Better?
在现如今这种快节奏盛行的时代，worse is better成为了可能，快捷、传播快及适用广等这些特点让这些worse软件更快的被接纳。我觉得不能说worse is better或是the right thing哪一个更好更对，个人觉得这只是一个相应的取舍问题。有的时候可能简单快捷比正确性更重要，但有时候正确性更重要，感觉是对于不同领域方面来说，所看重的东西不一样，需要权衡好，因此，这两者都应该在各自相适应的方面得到运用。
瀑布与敏捷
1、你的团队在开发中用了那些敏捷的思想和做法？
接受变通：整个团队项目中，或多或少总有些意外的情况，比如突然增多的其他课程作业等，都影响着我们的进度。但对于这些意外，我们都会进行讨论给出相应的应对方法。
交流：团队比较小，大家也都在学校，交流起来也比较方便，有问题随时沟通。
迭代：不管是α阶段还是β阶段，每一个大的阶段里也会有相应的小阶段，每一个阶段里会有相应的产品，不断更新迭代。
2、这是后来大家说的 “瀑布模型”，它有什么特点？
- 划分相应的基本块
- 前一个阶段完成后,下一个阶段才往下做
- 任何阶段如果发生错误,立即回到前面发生错误得阶段,进行修正工做
- 每一阶段完成后,皆会有严谨的文件产生
- 使用者只有在调查,需求分析及测试三个阶段参与
软件工程的方法论
软件工程发展至今有不少的方法，比如敏捷开发瀑布模式等，然而对于不同的方法有很多的争议。在《Why Software Development Methodologies Suck 》中作者提到由于软件开发的固有特性很难衡量，作者也提出两条常用的法则：划小开发周期以及提升反馈效率。个人认为对于软件工程的不同方法很难衡量其是否真正帮助了你开发，不确定的因素很多，而最后的评判结果只是最后软件发布的效果。对于方法来说，我认为它只是单纯的告诉你这样做是可能帮助你，但是是否成功还有其他诸多因素，一个软件的开发并不单纯的想是解一道数学题，按部就班就能得到自己想要的结果，往往还有其他的不确定因素，因此，方法应该借鉴有时也要变通，实践才能检验。所以个人觉得文中作者提到的两条法则是很有用的，如果最后只能依靠结果来判断好坏，那就应该尽早发布得到反馈，再依据反馈修改。