第8章 注重实效的项目

读书笔记 摘自：《程序员修炼之道》

---

41 注重实效的团队

60. 围绕功能组织团队
Organize Teams Around Functionality
不要把设计师与编码员分开，也不要把测试员与数据建模员分开。按照你构建代码的方式构建团队。

注重实效的方法适用于个人，同样适用于团队：不要留破窗户；温水煮青蛙；交流；不要重复你自己；正交性；自动化。
其中，对于项目团队的组织，以功能划分最佳，这样才具有较好的正交性。开发归开发，QA归QA，PD归PD，然后必然频繁的跨团队交流，我们公司目前正从这种方式慢慢转向Scrum团队：QA, 开发，PD同属一组，交流的效率能得到很大的提高。

42 无处不在的自动化　　

61. 不要使用手工流程
Don’t Use Manual Procedures
Shell脚本或批文件会一次次地以同一顺序执行同样的指令。

误导人的信息比完全没有信息还要糟糕。

这方面，我有两条信条：
1. 机器能做的事情，人就不要做
2. 凡是有固定规律的事情，都可以被自动化。

软件开发中的很多过程都能被自动化，我认为自动化繁琐的工作有两个好处：一个机器做的快而好，而且可重复；二是将繁琐的手工工作转化成编写自动化的程序，容易产生成就感。

43 无情的测试

62. 早测试，常测试，自动测试
Test Early. Test Often. Test Automatically
与呆在书架上的测试计划相比，每次构建时运行的测试要有效的多。
63. 要通过全部测试，编码才算完成
Coding didn’t Done Until All the Tests Run
就是这样。
64. 通过”蓄意破坏”测试你的测试
Use Saboteurs to Test Your Testing
在单独的软件副本上故意引用 bug，以检验测试能够抓住它们。
65. 测试状态覆盖，而不是代码覆盖
Test State Coverage, Not Code Coverage
确定并测试重要的程序状态。只是测试代码行是不够的。
66. 一个bug只抓一次
Find Bugs Once
一旦测试员找到一个bug，这应该是测试员最后一次找到它。此后自动测试应该对应其进行检查。

bug发现的越早，进行修补的成本就越低
关于测试的相当不错的论述。
自动化测试基础之上发现的bug，要为其添加case，不停的”把网收紧”。
但其中对于测试先行（TDD）没有特别的介绍，事实上，TDD是被认为是相当可行的一种编程方法学。

44 全都是写

67. 英语就是一种编程语言
English is Just a Programming Language
像你编写代码一样编写文档：遵守DRY原则、使用原数据、MVC、自动生成，等等。
68. 把文档建在里面，不要拴在外面
Build Documentation In, Don’t Bolt It On
与代码分离的文档不太可能被修整和更新。

难以描述、容易忘记、却又不能记载在别的任何地方的东西记下来
误导人的名称会增加你的代码的混乱

写注释、写文档。。。关键点还是在于：
1. 不要重复
2. 自动化

比如你需要某个DLL中的函数导出列表，不要自己维护一份（不要重复），而是写个工具从DLL中提取出来（自动化）。

45 极大的期望

69. 温和地超出用户的期望
Gently Exceed Your Users’ Expectations
要理解你的用户的期望，然后给他们的东西要多那么一点。

管理期望　　　不要因为增加这些新特性而破坏系统
知道用户的”期望”，不要无法达到，也不要超出太多。
“温柔的超出用户的期望”或许是最好的策略。
人的承受力是有个range的，不要太低，也不要太高~~~ 呃，或者，物极必反吧。

46 傲慢与偏见

70. 在你的作品上签名
Sign Your Work
过去时代的手工艺人为能在他们的作品上签名而自豪。你也应该如此。

不会逃避责任，乐于接受挑战
Sign You Work!!!
让别人知道这是你的作品：荣辱与共！这会催生一种自豪感与责任感。
如果你不敢在代码中签上你的名字，问问自己的内心：为什么?

部分评论摘自豆瓣书评

---

===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://my.csdn.net/dkjkls