标签：
在关于Silver Bullet的讨论中，我比较倾向于它是不存在的，即我支持软件设计的内在复杂度无可避免。因为即使运用了OO的设计理念，一个软件的各种可能的状态仍然是很难穷尽的，程序的各个部分之间的关系也仍然是非线性，软件的结构还是很难用可视化的方法表示出来。我同意这些事软件设计过程中内在的不可避免的复杂度，这是概念上就存在的，不是技术进步可以解决的。
我认为这几个问题是紧密相关的。大泥球指的是设计结构糟糕，到处补丁，缝缝补补的软件。这种问题也很容易出现，往往在软件构思的初期，因为没有预料到实现后期可能会添加的功能，从而导致后来补充的功能没有很好的融合进原先的系统中。
在我们的项目中，我们团队只有PM是有工程开发经验的，剩下的人基本的技术都是现学的。我是参与前端工作的，所以在实现前端的过程中，我觉得前端代码结构比较混乱。我是负责html,css代码的，其他两个同学是负责js代码的。首先，我的html,css代码，没有结构化。很麻烦的一点就是，如果我每个页面的相同部分的字体换一下，就需要重复n次修改。其次，js代码也是加在html文件夹里，看起来结构很混乱。
而这时候，一个软件团队通常有两种做法：
1.重新设计，力求软件的正确性。
2.尝试用一些非常规但是可能简单有效的办法修复漏洞（quick and dirty）。
这第一种做法，通常就是the Cathedral了，即强调每次发布软件时，源代码的正确和完整。
而这第二种做法，就是the Bazaar。它通常强调发布软件的每一个中间版本，无论源代码的正确或完整与否。The Cathedral的哲学很容易理解：发布的东西当然是要先经过内部的一直认同，是精细打磨后的产品。The Bazaar也有自己的哲学：当软件的源代码经过很多人过目之后，任何bug都会变得显而易见。The Bazaar的经典例子就有GNU Emacs等开源项目。当然关于这两种风格的争议不断。把所有版本都开源可以让代码变得更加丰富，不拘一格，但是同时加大了管理难度。而只把完善的代码公开或者不公开代码方便了代码库的管理，但软件的进化速度不会有the Bazaar系统那么快。而这两种系统的选择，则可以可看成是is worse better的哲学的体现。说worse is better的，实际上是说代码的简单和方便程度要比它的正确和完整性更加重要，在这种思想的指导下，更加灵活但不容易控制的开源项目自然成了首选。反过来，如果一个团队更加强调正确性和完整性，那么他们必然要对自己的代码有严格的控制，就不可能每一个中间版本都发布。在我看来，最好的做法是这两种大体风格的综合，即充分利用开源的优势，但同时加强对代码的管理，让软件尽量往好的设计进化，避免又多又杂的大泥球出现。
此模型由硬件的开发过程演化而来，然而在实际开发过程中，很多过程并不遵循瀑布模型，因为有时候尽管经过了上一个步骤，下一个步骤却出现问题，需要返回原来的步骤重新开始。
与传统的机械工程和建筑工程等先设计再建造的模式不同，软件工程的敏捷开发并不提倡先设计，因为软件设计的正确性经常是不能被证明的。敏捷开发将写代码视为设计，而提出建造过程其实是又编译器等自动完成的理念。它希望用较少的设计的文档，来完成正确完整的设计。这样既不会拘于设计文档的形式主义，又能使开发的软件结构较为清晰。
无论是敏捷开发还是瀑布模式，软件工程方法论的意义从来就不在于形式。敏捷开发强调用较少的文档做出较为清晰正确的设计，但其实它的精髓是让软件开发这个过程的反应速度很快，遇到问题可以迅速调整，而不是只会遵循文档的条条框框。因为软件开发是一个需要创新性人才的过程，所以任何方法论，如果没有落实到让程序员迅速得到好的反馈，让他们可以迅速调整自己，那都只是空洞的形式。
标签：
原文地址：http://www.cnblogs.com/pikali/p/4963511.html
