最近总感觉时间利用率不高，可能是作业太多，也可能是自己太懒。老师给出的文章，都没能认真地读一读，只能领略下大致意思。无奈作业就要提交了，只好先把到目前为止我的一些感受和见解写出来吧，日后一定会将那些文章补回。
一、“没有银弹”
这个问题很有趣。我们早就在脑子里形成了一个印象——计算机这个领域发展总是很快的，无论是CPU的性能，或是存储的容量，亦或是我们接触的那些应用程序的功能，都是日新月异。摩尔定律也被验证了几十年，而且还将继续。但是，假如以软件开发的视角去看待，就完全是另一幅景象了。
“没有银弹”这个观点，可以表述为：没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
这让我想到汽车工业，福特当初提出使用“流水线”进行装配，结果是汽车生产获得了“数量级上的进步”；之后随着机械自动化的发展，汽车生产又获得了“数量级上的进步”……那么，软件工程与之相比，又有什么不同呢？首先可以看到，软件生产和汽车生产的性质不一样。汽车生产中，只需要给流水线上每一位工人进行相应的、针对性的培训，每人只负责一小部分，就把工程的复杂度降低了。这样的生产有两个特点：独立性和可重复性。软件的开发可不是这样，软件不是批量生产的，也不是简单的组装形成的。汽车的复杂性在于组合成千上万个零件并且不发生差错，而软件的复杂性，在于其概念上的错综复杂的联系，比如团队各成员之间的沟通，接口的统一，易变的需求等等，这不是靠简单的流水线就能解决的。此外，尽管人们发明了这样那样的开发工具，但软件开发是不可能自动化的，因为软件不是可重复的产品。
二、“大泥球”
我们团队的项目是“学霸网站”，我们维护的项目是经过了之前两个团队开发之后的版本，一些基本的模块还是比较有条理的，但是从宏观或微观的角度去观察，大泥球无处不在。举些例子吧。
宏观上：
1. 在两处地方定义了实体型，我猜测是上一届与前一届项目规划的冲突
2. Solution的框架问题。CodingCook项目与其他平行项目存在包含的联系。（我们花了好大功夫才弄清CodingCook原来是一个团队的名字）
要解决这些问题，最有效的办法是在一开始就建立好项目规范。
微观上：
1. 涉及用户Sql查询的那些方法，到处是Ctrl+C, Ctrl+V的痕迹
2. 邮件管理的那些代码真正做到了“低内聚，高耦合”
如何解决：由于是残留的代码，我们只能在充分理解并且估计好代价的前提下，由小及大进行重构。如果代价过高或价值不大，放弃更改。
三、Cathedral and the Bazaar
很显然，我们是前者。
四、瀑布模型 & 敏捷开发
瀑布模型是一种按部就班的执行，前一个阶段完成了，才能进行下一阶段。这种做法最大的局限性是，最终产品直到最后才出现，如果需求有变，推倒重来的代价会非常高。
对于此，人们提出了敏捷开发方法，即以需求为主导，让产品原型在一开始就存在，在团队的密切的交流、配合之下，逐步完善各个部分。
我们用到的敏捷思想：
1. 通过尽早的、持续的交付有价值的软件来使客户满意。我们做的是网站，不可能等待100%完美之后再发布，而是在不断的迭代中添加特性。
2. 即使到了开发的后期，也欢迎改变需求。实际上任何时候更改需求，我们都能够做出响应。
3. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。在成员对某个模块有疑问时，直接找负责那个模块的成员，后者会进行详细讲解。
……