项目中需要时刻提醒自己的六件事
一些心得，写下来时刻提醒自己。
1.实现优先
这个问题很明显：无论如何，你都要先做出来。技术，性能，优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。
记住：即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。
2.以人为本
充分的衡量一下整个团队的能力，按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。
记住：你必须详细的了解团队中的每一个人，说不定一个闷臊的程序员恰恰成为了最好的客户沟通专家......
3.demo驱动开发
天下最“敏捷”的事情莫过于让用户经常能知道你的想法。那么正式开始之前都给他们做个demo，哪怕功能都是伪造的......或许你会发现其实客户要求的比你想的要少得多....
记住：让客户看到，永远比让客户听到要好
4.每天都是一个成功
与其每天气急败坏的催促手下加快开发进度，不如建立多个短期目标，每个目标都实现了，你就会发现自己腰不酸了，手下腿不痛了，客户一口气上五楼，不喘气了。
记住：让团队不被压力压倒是每一个管理者最重要的责任。
5.量力而为
如果你在上一条里的目标每个都是难以实现的，团队的士气或许很快就会降到谷底...项目的失败是可预期的。如果客户的要求也超出了团队的能力，放弃绝对比硬撑要值。
记住：别妄图在项目中保持120%的开发能力，你或许会在项目完成的前一天倒下...
6.横向储备
只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。
记住：项目总是会照顾那些有准备的人...
那这么说你觉得怎么样？
一天实现的虽然功能不完善但可用的并且有充分质量保障的系统，比闷头一个月想了很多却什么都没做出来要好得多 37 楼 Godlikeme 2008-02-15 不一定是了解重构的人少，是能够实施下来很困难。
书尽量还是看原版吧，还有 尽信书不如无书。
38 楼 BadLuck 2008-02-15 关于重构，有人用过clearcase吗？我们的很多子项目是从一个主干项目拉出来的分支，不知道为啥不管从主干或者某个分支上删除一个文件后，所有其他的枝干就都看不到这个文件了，普通开发人员甚至连文件修改历史记录都看不到。于是管clearcase仓库的老英雄就把普通开发人员的文件删除权限给去掉了。想重构的时候，发现有的类是垃圾，但是不能删除。啧啧，那感觉简直就像是戴着脚镣在跑步一样。。。怎一个爽字了得 39 楼 gigix 2008-02-15 Godlikeme 写道不一定是了解重构的人少，是能够实施下来很困难。
书尽量还是看原版吧，还有 尽信书不如无书。
实施确实很困难，不过不是没办法做，7年40万行代码的遗留系统，15万行Java代码，我还不是给它搞了重构项目。
做是有办法做的，看你愿意下多大成本了。 40 楼 Godlikeme 2008-02-15 BadLuck 写道关于重构，有人用过clearcase吗？我们的很多子项目是从一个主干项目拉出来的分支，不知道为啥不管从主干或者某个分支上删除一个文件后，所有其他的枝干就都看不到这个文件了，普通开发人员甚至连文件修改历史记录都看不到。于是管clearcase仓库的老英雄就把普通开发人员的文件删除权限给去掉了。想重构的时候，发现有的类是垃圾，但是不能删除。啧啧，那感觉简直就像是戴着脚镣在跑步一样。。。怎一个爽字了得
可能删掉了是更大的问题，@deprecated.重大版本订版时候统一做掉。
41 楼 Godlikeme 2008-02-15 就如同Refactoring 书中开篇讲到的，没有强有力的推动者，绝对是阻力重重。 42 楼 liudaoru 2008-02-20 lz写的还是不错的，有些同感。。。 43 楼 gurudk 2008-02-21 timerri 写道一些心得，写下来时刻提醒自己。
1.实现优先
这个问题很明显：无论如何，你都要先做出来。技术，性能，优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。
记住：即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。
2.以人为本
充分的衡量一下整个团队的能力，按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。
记住：你必须详细的了解团队中的每一个人，说不定一个闷臊的程序员恰恰成为了最好的客户沟通专家......
3.demo驱动开发
天下最“敏捷”的事情莫过于让用户经常能知道你的想法。那么正式开始之前都给他们做个demo，哪怕功能都是伪造的......或许你会发现其实客户要求的比你想的要少得多....
记住：让客户看到，永远比让客户听到要好
4.每天都是一个成功
与其每天气急败坏的催促手下加快开发进度，不如建立多个短期目标，每个目标都实现了，你就会发现自己腰不酸了，手下腿不痛了，客户一口气上五楼，不喘气了。
记住：让团队不被压力压倒是每一个管理者最重要的责任。
5.量力而为
如果你在上一条里的目标每个都是难以实现的，团队的士气或许很快就会降到谷底...项目的失败是可预期的。如果客户的要求也超出了团队的能力，放弃绝对比硬撑要值。
记住：别妄图在项目中保持120%的开发能力，你或许会在项目完成的前一天倒下...
6.横向储备
只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。
记住：项目总是会照顾那些有准备的人...
说的不错，能理解这六条说明都比较有经验的。楼主总结的还是比较精炼的。
44 楼 gurudk 2008-02-21 timerri 写道看来这个实现优先还是没有讲清楚啊。
实现优先并不是说完全的实现整个系统后再去重构，而是在项目最开始的时候尽快建立起一个能满足项目中最关键需求的原型系统(哪怕你得到是一个由shell,script,java等等拼出的大杂烩，但只要还能跑就足够了)，随后的沟通，设计都基于原型来进行。通过构建原型系统，你将最早的了解到项目中的难题。此外，由于原型的存在，你有了一个最好的沟通基础，无论是对客户还是对组员，你的描述和设计都将言之有物，你对于需求的收集也将更明确和详细。
喜欢xp的朋友应该更容易理解，还记得xp的4个核心价值么？交流，简单，回馈，勇气......
还有plan design...simple design.....
其实这里所谓的实现优先与xp并没有冲突，只是侧重的部分不同罢了。
实现优先，是要有基本的代码规范的，否则会给后面的重构增加很大的阻力。至于性能，我也赞同前期不用过多考虑，但要有一个有丰富的架构师对以后可能带来的性能风险进行识别，有基本的应对措施，比如访问量提高的应对措施（负载均衡，静态化，数据库索引）。记得Martin Fowler说过，性能到具体的环境下才能知道具体的含义，也只有实际通过测试才能衡量。
45 楼 zingers 2008-02-21 楼主说的还是蛮有道理的，反对的人可以举例说明 46 楼 yecllsl 2008-02-25 目前因为公司重视程度不同、人员能力不同，很难让你在项目开始之前建立一个合适的团队，可能公司哪些人闲着那些人就是项目中的人了。（当然大公司、管理完善的应该好一点，我现在只知道一家印度公司、MS是项目经理组建团队的，大多数还是哪些人闲着就是那些人）而这些闲着的人都有能力重构、TDD吗？我觉得只能让过程、管理适应人了，不同的项目有不同的过程，只遵循迭代开发的宗旨，遵守大家认同的最佳实践。每个项目的过程都可调，而楼主提到的这些实践，第一条不敢苟同，因为被这样的“坑”害惨了。 47 楼 yecllsl 2008-02-25 gurudk 写道timerri 写道看来这个实现优先还是没有讲清楚啊。
实现优先并不是说完全的实现整个系统后再去重构，而是在项目最开始的时候尽快建立起一个能满足项目中最关键需求的原型系统(哪怕你得到是一个由shell,script,java等等拼出的大杂烩，但只要还能跑就足够了)，随后的沟通，设计都基于原型来进行。通过构建原型系统，你将最早的了解到项目中的难题。此外，由于原型的存在，你有了一个最好的沟通基础，无论是对客户还是对组员，你的描述和设计都将言之有物，你对于需求的收集也将更明确和详细。
喜欢xp的朋友应该更容易理解，还记得xp的4个核心价值么？交流，简单，回馈，勇气......
还有plan design...simple design.....
其实这里所谓的实现优先与xp并没有冲突，只是侧重的部分不同罢了。
实现优先，是要有基本的代码规范的，否则会给后面的重构增加很大的阻力。至于性能，我也赞同前期不用过多考虑，但要有一个有丰富的架构师对以后可能带来的性能风险进行识别，有基本的应对措施，比如访问量提高的应对措施（负载均衡，静态化，数据库索引）。记得Martin Fowler说过，性能到具体的环境下才能知道具体的含义，也只有实际通过测试才能衡量。
代买规范要有的。性能我觉得应该一开始就注意，架构中应该明确非功能需求，你架构的质量，如果一开始就盲目实现，连架构都不考虑，那有些性能指标是永远也达不到的，无论你如何扩展，横向还是纵向。因为性能的提高主要是架构的支持（负载均衡、缓存、池、数据库索引或者去规范化等等），依靠代码调优提升性能的空间太小了。开发人员在自己的开发机器上就可以验证性能，不一定非要在“压力测试”环境，如果PC上很小的压力都过不去，那服务器上也很难有高的性能。
48 楼 tinggu 2008-02-28 建议楼主看看代码大全2。 49 楼 catchwang 2008-03-05 LZ说的是正确的，但是这些道理都知道。。。。。。 50 楼 sea2000 2008-03-12 客户管理混乱无序同时开发商也管理混乱无序时，应该时适用的 51 楼 dboylx 2008-03-12 即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。
您说的这句太经典了 52 楼 kellersoon 2008-04-03 同意 實現優先 軀動開發 量力而為 熟悉每一個開發成員
