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

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

一些心得，写下来时刻提醒自己。

1.实现优先
这个问题很明显：无论如何，你都要先做出来。技术，性能，优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。
记住：即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。

2.以人为本
充分的衡量一下整个团队的能力，按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。
记住：你必须详细的了解团队中的每一个人，说不定一个闷臊的程序员恰恰成为了最好的客户沟通专家......

3.demo驱动开发
天下最“敏捷”的事情莫过于让用户经常能知道你的想法。那么正式开始之前都给他们做个demo，哪怕功能都是伪造的......或许你会发现其实客户要求的比你想的要少得多....
记住：让客户看到，永远比让客户听到要好

4.每天都是一个成功
与其每天气急败坏的催促手下加快开发进度，不如建立多个短期目标，每个目标都实现了，你就会发现自己腰不酸了，手下腿不痛了，客户一口气上五楼，不喘气了。
记住：让团队不被压力压倒是每一个管理者最重要的责任。

5.量力而为
如果你在上一条里的目标每个都是难以实现的，团队的士气或许很快就会降到谷底...项目的失败是可预期的。如果客户的要求也超出了团队的能力，放弃绝对比硬撑要值。
记住：别妄图在项目中保持120%的开发能力，你或许会在项目完成的前一天倒下...

6.横向储备
只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。
记住：项目总是会照顾那些有准备的人...

看来这个实现优先还是没有讲清楚啊。

实现优先并不是说完全的实现整个系统后再去重构，而是在项目最开始的时候尽快建立起一个能满足项目中最关键需求的原型系统(哪怕你得到是一个由shell,script,java等等拼出的大杂烩，但只要还能跑就足够了)，随后的沟通，设计都基于原型来进行。通过构建原型系统，你将最早的了解到项目中的难题。此外，由于原型的存在，你有了一个最好的沟通基础，无论是对客户还是对组员，你的描述和设计都将言之有物，你对于需求的收集也将更明确和详细。


喜欢xp的朋友应该更容易理解，还记得xp的4个核心价值么？交流，简单，回馈，勇气......

还有plan design...simple design.....

其实这里所谓的实现优先与xp并没有冲突，只是侧重的部分不同罢了。

实现优先，是要有基本的代码规范的，否则会给后面的重构增加很大的阻力。至于性能，我也赞同前期不用过多考虑，但要有一个有丰富的架构师对以后可能带来的性能风险进行识别，有基本的应对措施，比如访问量提高的应对措施（负载均衡，静态化，数据库索引）。记得Martin Fowler说过，性能到具体的环境下才能知道具体的含义，也只有实际通过测试才能衡量。