项目中需要时刻提醒自己的六件事

一天写个杂粹至少可以让顾客审查提意见，之后可以修改。就怕你自以为是的花了n久搞了个以为很了不起的东西，结果顾客一看是个杂碎，你根本没时间修改。

设计现行，实现第一的思想是正确的。现在很多项目具都过度设计，真的很没必要。浪费时间而已。

过度设计-->就是个人水平问题.
一天写个杂粹至少可以让顾客审查提意见-->我把前期时间话在设计上同样可以让顾客审查提意见,除非你设计的时候是不考虑客户的感受.就怕你自以为是的花了n久搞了个以为很了不起的东西，结果顾客一看是个杂碎，你根本没时间修改-->什么叫沟通啊?什么就确定需求啊?
难道就不会先画一些带有静态数据的核心(注意:是核心)界面来让顾客审查提意见吗?

严重同意LZ的观点。

看到前面的反驳意见，大部分集中在第一点。认为做出的“杂碎”以后用不了。

个人以为，我们国内的程序员，了解重构的人太少。能够在项目中写完整单元测试的人太少。 所以造成了对“杂碎”程序的恐惧感。

其实看国外很多大牛们写的跟软件工程开发过程相关的书，都是认为实现一个很简单的东西要比做一大堆华丽的设计要好的多。

而且在各位大牛的书中都提到，重构是避免让软件腐朽的方法。有了重构，我们还怕什么呢？

如果一个程序员的风格，是写好了一段程序之后就很不喜欢修改，我非常推荐《重构》这本书， gigix翻译的。

支持50%,反对50%

呵呵，你牛的
我以前有个项目，客户用了半个月以后发现他在某个特别的时间段会经常需要查看一百八十几页后面的数据，估计你很有办法能提前就知道他有这需求

关于楼主所说的第一点,"即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多" 这对比似乎有点悬殊和极端

那这么说你觉得怎么样？

一天实现的虽然功能不完善但可用的并且有充分质量保障的系统，比闷头一个月想了很多却什么都没做出来要好得多

不一定是了解重构的人少，是能够实施下来很困难。
书尽量还是看原版吧，还有 尽信书不如无书。

关于重构，有人用过clearcase吗？我们的很多子项目是从一个主干项目拉出来的分支，不知道为啥不管从主干或者某个分支上删除一个文件后，所有其他的枝干就都看不到这个文件了，普通开发人员甚至连文件修改历史记录都看不到。于是管clearcase仓库的老英雄就把普通开发人员的文件删除权限给去掉了。想重构的时候，发现有的类是垃圾，但是不能删除。啧啧，那感觉简直就像是戴着脚镣在跑步一样。。。怎一个爽字了得

实施确实很困难，不过不是没办法做，7年40万行代码的遗留系统，15万行Java代码，我还不是给它搞了重构项目。
做是有办法做的，看你愿意下多大成本了。