注重实效的哲学

1、我的源码让猫吃了
要为自己的项目负责，不要找借口，而是要找选择，找解决方案

2、软件的熵
破窗理论
不要容忍“破窗户”（低劣的设计、错误决策、糟糕代码）
一个干净整洁没有破窗的项目，其他人也不忍心第一个破坏它。但是一旦有破窗，其他人也就不在乎了，破窗越来越多。

3、石头汤与煮青蛙
做变化的催化剂
遇到问题的时候，尽管会面临其他人或者团队的无法支持。但是主动的去做，去拿出一个你可以拿出的可用的原型。这个时候，相关的人和团队就会发现，自己向上面添加东西，就会变得更好。
记住大图景。避免温水煮青蛙。

4、足够好的软件
今天的了不起的软件常常比明天的完美软件更可取。
不要过度求精，软件不可能完美。

5、你的知识资产
定期为你的知识资产投资
持续学习

  • 每年至少学习一种新语言
  • 每季度阅读一本技术书籍
  • 也要阅读非技术书籍
  • 上课
  • 参与本地用户组织
  • 试验不同的环境
  • 跟上潮流
  • 上网
    批判的分析你读到和听到的

6、交流
要了解听众，要有效的传递信息，不能空谈
应该总是对电子邮件或者语音作出回应。
总结：

  • 知道你要说什么
  • 了解你的听众
  • 选择时机
  • 选择风格
  • 让文档美观
  • 让听众参与
  • 做倾听者
  • 回复他人

注重实效的途径

7、重复的危害
DRY：系统中的每一项知识都必须具有单一、无歧义、权威的表示

8、正交性
消除无关事物之间的影响
正交系统：提高生产率、降低风险
团队组织也要有正交性
养成不断地批判对待自己的代码的习惯

9、可撤销性
不存在最终决策，让代码学会“摇滚”

10、曳光弹
原型制作生成用过就扔的代码。曳光弹代码虽然简约，但却是完整的，并且构成最终系统骨架的一部分。
可以把原型制作视为在第一发曳光弹发射之前进行的侦查和情报搜集工作。

11、原型与便笺
为了学习而制作原型

12、领域语言
靠近问题领域编程

13、估算
估算，以避免发生意外
估算的第一步都是建立在对提问内容的理解
放慢估算的速度，仔细检查在这一节描述的步骤，几乎总能得到更好的结果

基本工具

14、纯文本的威力
持久存储知识的最佳格式是纯文本
用纯文本保存知识

威力：

  1. 保证不过时
  2. 杠杆作用：围绕一堆基于纯文本的工具链
  3. 更易于测试

15、shell 游戏
利用命令 shell 的力量

16、强力编辑
用好一种编辑器，并将其用于所有编辑任务

17、源码控制
总是使用源码控制

18、调试
要修正问题，而不是发出指责
不要恐慌
开始修正 bug 的最佳途径是再现 bug
不要假定、要证明

19、文本操纵
学习一种文本操纵语言

20、代码生成器
编写能编写代码的代码

注重实效的偏执

你不可能写出完美的软件
注重实效的程序员连自己也不信任

21、按合约设计
什么是正确的程序？不多不少，做它声明要做的事情的程序。
对接受的东西要严格，而允诺返回的东西要尽可能少
可以通过断言进行部分模拟

22、死程序不说谎
早崩溃
让你的程序崩溃是最佳选择
死程序带来的危害通常比有疾患的程序小的多

23、断言式编程
如果它不可能发生，用断言确保它不会发生
不要用断言代替真正的错误处理，断言检查的是决不应该发生的事情

24、何时使用异常
将异常用于异常的问题

25、怎样配平资源
要有始有终
分配某项资源的对象应该负责解除该资源的分配

弯曲，或折断

创建灵活代码的一个关键概念是数据模型（model）与该模型的视图（view）的分离

26、解耦与得墨忒耳法则
把你的代码组织成最小组织单位（模块），并限制它们之间的交互
使模块之间的耦合减至最少
通过反转得墨忒耳法则，是若干模块紧密耦合，你可以获得重大的性能改进

27、元程序设计
要配置，不要集成
将抽象放进代码，细节放进元数据

28、时间耦合
我们要容许并发
分析工作流，以改善并发性
总是为并发进行设计

29、它只是视图
模块的一个好定义就是，它具有单一的、定义良好的责任
使视图与模型分离

30、黑板
用黑板协调工作流

当你编码时

31、靠巧合编程
不要靠巧合编程

  • 总是意识到你在做什么
  • 不要盲目的编程
  • 按照计划行事
  • 依靠可靠的事物
  • 为你的假定建立文档
  • 不要只是测试你的代码，还要测试你的假定
  • 为你的工作划分优先级
  • 不要做历史的奴隶

32、算法速率
估算你算法的阶
测试你的估算

33、重构
不要对改动犹豫不决，应该现在就做
无论代码具有下面的哪些特性，你都应该考虑重构代码：

  • 重复
  • 非正交设计
  • 过时的知识
  • 性能
  • 早重构，常重构*
    提示：
  1. 不要试图在重构的同时增加功能
  2. 在开始重构之前，确保拥有良好的测试
  3. 采取短小、深思熟虑的步骤

34、易于测试的代码
为测试而设计
通过使测试代码易于找到，你是在给你的代码开发者提供两样无价的资源：

  1. 一些例子，说明怎样使用你的模块的所有功能
  2. 用以构建回归测试、以验证未来对代码的任何改动是否正确的一种手段

35、邪恶的向导
不要使用你不理解的向导代码

项目开始之前

36、需求之坑
不要搜集需求——挖掘它们
找出用户为何要做特定事情的原因、而不只是他们目前做这件事情的方式
你的开发必须解决他们的商业问题，而不只是满足他们陈述的需求
与用户一同工作，以像用户一样思考
使用项目词汇表

37、解开不可能解开的谜题
对需求的重新诠释能让整个问题全部消失
你所需要的只是真正的约束、令人误解的约束、还有区分它们的智慧

38、等你准备好
倾听反复出现的疑虑——等你准备好再开始
从“政治策略”角度说，去构建原型也许比简单地宣布“我觉得不该启动”、并开始玩单人纸牌游戏更能让人接受

39、规范陷阱
对有些事情“做”胜于“描述”

40、圆圈与箭头
不要做形式方法的奴隶
注重实效的程序员批判的看待方法学，并从各种方法学中提取精华，融合成每个月都在变得更好的一套工作习惯
你应该不断努力提炼和改善你的开发过程

注重实效的项目

使项目级活动保持一致和可靠的一个最重要的因素是使你的各种工作流程自动化

41、注重实效的团队
不要留破窗户
围绕功能、而不是工作职务进行组织
我们是在寻求内聚的、在很大程度上自足的团队
让每个成员都能以他们自己的方式闪亮

42、无处不在的自动化
不要使用手工流程

43、无情的测试
早测试，常测试，自动测试
要到通过全部测试，编码才算完成
一个 bug 只抓一次：如果有 bug 漏过了现有的测试网，你需要增加新的测试，以在下一次抓住它

44、全都是写
好记性不如烂笔头
一般而言，注释应该讨论为何要做某事、它的目的和目标

45、极大的期望
温和的超出用户的期望

46、傲慢与偏见
在你的作品上签名
注重实效的程序员不会逃避责任，相反，我们乐于接受挑战。