设计与开发的五条原则–六年真谛

如果需求不明确，应该采用原型模型，需求变化太大，应该采用演化模型。

恕我愚钝，能不能请您说说楼主的哪条感悟在什么时候不符合了您的什么国情？

在软件开发中，需求变更大在任何地方都是非常常见的。

当然不是。模式、重构、分层都是可以让你的程序变得更简单。当然，模式、分层会增加程序的indirection. 但它最终应该让你的程序结构更清晰，模块和模块之间的关系更简单。如果你的模式，分层没有给你带来这些好处，你就应该考虑一下是否有必要用这些模式和分层了。

再增加一条吧，写完这篇文章后觉得必须加进去的一条：

第五条： 一定需要且只需要数页简单明了的设计说明书。

这个设计说明最好不用word，最好是放在源代码下的html或者txt格式。简单粗线条的UML最适宜用在这种地方。判断一个开发人员的设计素质如何，打开源代码，看看有没有这个文档以及这个文档的水平，就知道了。

不是所有问题在一开始就能完全清楚的，XP推崇的是隐喻，说白了也就是知道问题的主要关键以及方向，而不是一开始去弄清它。等你完全弄清楚后，新问题又来了。所以此条作为原则不适合， 对待问题的关键是知道如何解构问题。
对于软件设计，尤其是复杂的软件设计，不是很容易详细区分哪些先干，哪些后干的。当然了，清楚事情的优先级是必要的，不过，这个应该是二维关系，而不是简单的前后续关系。
还好，这是规则，要是原则就会撞死许多人了。 对于设计者确定其设计已经达到了完美的标准是不能再减少任何东西“这句话最经典的反驳就是最烂的设计也是什么不能减去，你要一个苹果，它给你一大篮水果。其实真正优秀的设计是可以简单并且容易的增加东西（也就是扩展）。设计模式也好，其他也好，追求的就是重用性。KISS的目的是要程序不要将简单问题复杂化，而并非意思要将复杂问题简单化。如果纯粹一个KISS的概念，一个类，一个方法最好了，完成功能了，讲究什么重用啊，大不了再拷贝。
这个是赞同的，因为程序员的”懒“促进了进步，促进了重用。


  简单明了的设计说明书是好事，不过什么放在源代码下的html和txt最好，就有些牵强了。楼主还有本事用txt画UML？至于后续说判断一个开发人员素质如何的方式，呵呵，那apache, spring, jboss, sun等所有的开发人员都比较低劣，因为几乎没发现他们这样做。

并不是说一开始就要完全将问题定义清楚，定义清楚以后再干活，而是说在当前条件下，要尽可能地明白问题。



KISS 确实首先强调的当然包括不要将简单问题复杂化。不过你后面举的这个例子就是过了，与KISS没关系。所谓的追求重用性，跟KISS并不矛盾， 遵循KISS原则，则恰恰可以帮助许多总是想着重用的人们端正态度，不要去臆测重用需求，只着眼于有确实根据的需求或衍生需求。



放在源代码下是是词不达意，应该说是说跟源代码放在一起，通常是一起放在版本控制系统下的。 txt 格式当然不能画 UML，不过UML文件你可以放在同一目录下的了。 在文字上细究那当然无可奈何

无论是 apache, spring, jboss, sun， 他们也是有设计文档的。当然设计的内容也许放在 Wiki 上，也许在在其他的地方。不这么做并不是说就是不好的，如果这么做了，那么应该素质是不错的。 我修改一下原话。

楼主是沈阳工业大学的么?....

这个非常赞同.... 不过现在啊，最大的问题就是KISS被滥用了，呵呵。
我到也不是究你文字，只是你作为原则，让人误解了总是不好。 而对于放在版本控制下的文件，其中有个建议是最好不用二进制格式的，包括word,excel等等，因为二进制是无法进行版本识别和判断的。其实wiki比较好，在没有wiki的情况下，word其实是一个不错的选择的，因为word是可以跟踪修改记录的。所以使用html也好（其实这个并建议，html最好是自动化生成，而非人手写的文档，受格式的影响非常难以版本比较），txt也好，也只能是建议，而上升不到原则的。

   其实跟楼主说这些，只是希望大家在很多时候更多斟酌，不要轻易下决定，其实很多时候，技术也好，方法论也好，都是有适用场景的，不是么？

只对第四条有同感，其他几条，呵呵，就不发表什么评论了，不知道楼主做的项目涉及的领域都是什么方面。

都不错。
任何原则都是有例外的，所谓仁者见仁，智者见智。
原则是没有错的，只有领会错，用错的人。