小土刀

为了不至于让第一次负责项目就落得个尴尬的结局，这几天一直在看各种关于软件项目管理及开发的书。这本书我隐约记得之前看过，是《程序员修炼之道》的姊妹篇。果然，半年前看过，但是当时并没有太大的感觉，反而是现在真正开始思考如何做好一个项目，才意识到个中滋味。

看了一下书评，很多在抱怨这里面的工具过时，我觉得要是看一本书仅仅是为了最表面的东西，未免有些肤浅，了解了原来的工具，并懂得了其进化的方向，要比直接学会新工具要有意义得多。其实说是软件项目，完全可以推广到其他事情上，因为做好一个项目，很多东西都是共同的，触类旁通嘛。

书中提及了42个技巧，这里一并附上，并加上我的一些感想：

1. 选择习惯。不要偶然地养成某些习惯，要有意识地主动选择习惯。

2. 留在沙箱里。在你准备好之前，要与其他人隔离，使他们不会受到你的工作的影响。（更高级的版本控制，要在服务器上留好空间和备份）

3. 如果需要就将其签入。你的源代码管理系统一定要包含构建、部署和运行产品所需的一切。

4. 从第一天起就使用脚本构建。要保证在工作室的每一个工作站上都能以完全相同的方式构建产品

5. 任何机器都可以作为构建机 

6. 持续构建 

7. 持续测试 

8. 避免集体失忆。跟踪系统不仅可以为产品生成已知问题列表，还可以为开发人员生成任务列表。

9. 演练产品——自动测试

10. 使用通用、灵活的自动化测试框架 

11. 工欲善其事，必先利其器。

12. 使用开放格式集成工具 

13. 使用熟悉的关键路径技术。创建一个关键技术时千万不要把它变成一个技术试验。不要使用你不理解的向导代码

14. 按照任务清单工作。如果任务清单包含很多深入的工作，说明你已经提前考虑并对后面的步骤做了计划。

15. 要有一个技术领导人。每个开发人员都应该渴望成为一个好的技术领导人。

16. 通过每日例会频繁进行航向修正 

17. 可以说“以后再来”。如果你正处在需要全神贯注的情况下，让别人稍后再来并不是侮辱他。

18. 经常审查所有代码 

19. 目标是软件，而不是遵从过程 

20. 集体参与建立架构 

21. 如果生产环境会用到，你也要用到 

22. 先解决最难的问题 

23. 封装的架构是一个可伸缩的架构 

24. 除非船在移动，否则转动方向盘没有用。大多数人在回避问题上花费的时间和精力比他们尝试解决问题所下的功夫还要多 

25. 测试之前不要修改遗留代码 

26. 使用测试驱动重构清理不可测试的代码 

27. 模拟客户测试可以事半功倍。能在最短的时间内测试最多的代码

28. 持续测试不断改变的代码 

29. 必须适用于所有人

30. 经常集成，并持续构建和测试 

31. 尽早而且经常发布真实演示系统 

32. 公布你在做什么以及为什么这么做 

33. 会面才能建立真正的团队 

34. 只修正需要修正的地方。绝对不要因为一个实践是“正确做法”就盲目引入

35. 破坏性的“最佳实践”不是最佳实践 

36. 自下而上改革 

37. 要具体展示，不要光说不练 

38. 让管理层逐渐认可 

39. 测试有bug的代码 

40. 任务清单是一个活动的文档，生活中处处有变化 

41. 如果任务清单上没有，那就不是项目的一部分 

42. 要快速做出反馈

其实还有很多地方不是特别清晰明白，不过我相信在做项目的过程中，能拨开迷雾，见到天空吧。