软工阅读博客第二弹

关于“银子弹”的传说：

         当我们编程的时候总是会遇到这个问题，那个问题，比如效率低下，功能欠缺等等等等，这个时候总会有人想，是否有个“万金油”似的解决方案，能够一劳永逸？然而，这是不现实的。这么多年来，有太多太多的失败例子，从一开始就吹嘘着它们的优势，如4GLS，又如CASE，可是事实证明，它们都无法达到革命性的突破，要不就是效果不明显，要不就是有一定的局限。我以为，作为一个成熟的开发人员，并不应该迷信所谓的“银子弹”，应该脚踏实地，将问题挨个解决，而非妄想一步登天。切记，一口吃不成胖子！

 

我理解的“瀑布模型”：

         定义：该模型将软件开发周期分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

       在一个纯瀑布模型中，以上各阶段之间既不连续也不重叠，每一个阶段的结果都是一个文档，这样可以帮助开发者及早发现问题，并且在每一个阶段都无需再考虑欠一个阶段的内容，全心投入，使得开发更加稳定，提高开发效率。

       当然，这样的开发也有其局限性。由于其中规中矩的运作，使得项目开发缺乏灵活性。当用户需求改变时，整个过程都需要修改，难以回溯。然而，作为一个开发团队，开发的产品功能应由自己设计，而非单单由用户指定（若是如此，相信其它团队也能胜任），因此在开发过程中功能的增设应是常有的事，这就使得这一模型逐渐被“迭代模型”取代。该模型仅适合于技术力量较弱，缺乏开发经验的团队，或者是一些很复杂的问题（有一个正确的总线指引就不易走上岔道）。

 

如何对待“大泥球”：

       我对于大泥球的理解是，在开发过程中，由于没有做好前期的设计，导致在程序运行时出现Bug，于是开发者为了尽快解决这一Bug，就会查找出错点，然好仅对那一段程序进行修改，直到该Bug消除。在以前搞OI时经常会有这样的事，为了赶时间嘛，所以当发现有错时赶紧去修改那个错，试图尽快AC，然而，大多数时候都是徒劳的。就像设计一条衣服，先把每个部分做出来——袖子，领子，主体，口袋，扣子。然后将它们组合起来，最后发现，袖子和主体没有完全缝合，扣子不对成，口袋有洞，甚至主体有缺陷。于是，我们将袖子和主体的缝合处重叠一下，勉强缝合，扣子调整一下位置，再补张布上去……这样打补丁，试图使得最终的衣服，不求好看，至少能穿，然而，最后的结果是你或许能套上去，但是遇到一些突发情况，如要去打球时，衣服就可能“喀嚓”一声，四分五裂。真正的问题在于最初的设计！现在的设计尚未发现“大泥球”，也有可能是因为分工，互相都不知道各自的程序中是否有些“小泥巴”。对于这种情况，我的建议是重新设计一番。因为打补丁是一个无底洞，有时你补了这边，另一边可能就出错了。

 

“大教堂与集市”

       这是两种自由开发软件的模式，它们都是基于代码“开源”这一条件。我们团队应该现在的项目属于“大教堂”模式吧（毕竟是在上一个清华团队的源代码基础上改进功能及界面）……

 

Losts  in  CatB

         关于这一问题，我持之前的观点，仅仅依靠集市的市民们的自觉是无法建立一个社会的，没有一定的制度、秩序，光靠补丁是无法将一件衣服完善的。1+1<1的情况屡见不鲜，2种迥异的风格不仅使得程序的可读性大大降低，甚至会由于之间的冲突导致程序无法运行。因此，过度的迷信集市是无法成功的，需要一座教堂为市民们引导方向。

 

敏捷开发

         我们团队要采用的敏捷开发做法有如下几种：

（1）       scrum meeting ：例会可以让大家互相了解各自进度及困难

（2）       迭代：第一个阶段的“阿尔法”版本即将出世，而“贝塔”版的设计即将提上日程

（3）       优先实现主要功能：其它的一些想法根据任务进程再决定是否实现