阅读作业 第二弹

首先关于“瀑布模型”，感慨微多，特别想说一下。首先是和这个模型无关的，是有关阅读选材的，老师绝大多数的阅读材料都是英文的，而且篇幅也不算短（当然，相对于之前书来说不能说多），这稍稍影响了不少同学的阅读兴趣，至少我没怎么啃过全英文的文章，虽然慢慢看也可以看，不过都是极为低效的，常常是看了这一句就忘了上一句，无法看到全文（我承认，我的错。。。），所以，我不奢望老师能放上主要是中文的材料，只是希望能够多一点选择，比如这个“瀑布模型”的选材就极为合适，视频材料更易于接受，且更加容易让人理解、更容易激发大家的学习兴趣，这个视频就做的比较有意思了，而且一点也不晦涩难懂。然后就是关于这个模型本身的看法了，正面的特性就是该模型将软件开发过程程式化了，将功能的实现与设计分开，便于分工协作。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。这样或许开发人员能够思路更加清晰，合作更加顺利。不过，关于负面的，正如视频中所反映的现象，该模式大概是误解了原作者的本意，它的流行带来了各种各样的问题。就我个人短暂的开发经历来看，在该模型中，我们在实际写代码之前就要写成对的各种文档、画UML图等等。然后等到真正开始写代码的时候就完全抛下这些设计，直接开始写，一方面是实际写的时候发现完全不是那么一回事，另一方面是需求总是改的太快。。。其实这个架构模式真的并非那么好，比如测试环节完全放在程序编写后，但是这并不算高明的设计，这样对后期的压力太大，而且返回改动也大。我觉得很多人都要好好这个视频材料，那也许会对效率的提高有所帮助。

然后还有哪个catB和 lost in catB，这两个对应的问题放在一起看确实很有意思。在大教堂模式和集市模式的选择中，《大教堂与市集》让大部份的开放源代码及自由软件的开发计划采用市集模式，甚至原来采用大教堂模式的 GNU Emacs 及 GCC 也是如此。其实我个人也一直觉的集市模式比较好（虽然以前不知道这样一个名词），觉得这种模式利于好的想法涌现，有各路大神以及爱好者贡献自己的一份力，这样会有比较有意思的作品诞生。而另一篇文章则对大家迷失在集市中进行反思，他认为这种模式使得代码变得冗余臃肿，不断的复制粘贴。类似.COM时代的泡沫中，大家在集市模式中的心态变为了“对付过去就行”，这样使得代码质量下降。在大教堂和集市的选择上，我果然还是倾向与集市模式，我不喜欢如同帝国一般存在的，总觉的这样没有什么生命力，总有倒下的一日，相反，集市模式虽然有些糟糕的作品，但是这百花齐放的环境下也会有非常好的作品产生。不过，倒是希望能有更加折衷一点的解决方案，比如能在市场模式中加入一些监管，及时将那些比较糟的和比较旧的清出集市之中。

关于那个“大泥球”，确实是个比较常见的问题。我也是经常写代码写着写着就乱了，觉的整体架构实在太乱了。大泥球的问题确实挥之不去。我觉得应该增强前期设计，好好考虑要做什么怎么做的问题，设计一个比较好的架构，然后能及时应变需求变化，这样的话，或许可以减少大泥球的产生。其实，我还想大概也是因为我的个人工程经验太少，有些时候自乱阵脚，越搞越糟。