程序员修炼之道 Jun, 2015

这本书出版有些年头了，虽然其中的例子有些老旧，但是有些思想和哲学永远不会过时。

注重实效的哲学

负责，提供各种选择，不找蹩脚的借口。

避免软件腐烂，破窗效应，不要容忍破窗户。

启动杂役，做变化的催化剂。

不要被温水煮青蛙，留意大图景。

让用户参与权衡，使质量成为需求问题。

像管理金融资产一样管理知识资产。定期为你的知识资产投资。

不要搁置问题。

批判的分析你读到的和听到的。

注重交流，想清楚你要说什么，了解听众。

注重实效的途径

重复的危害

系统中的每一项知识都必须具有单一、无歧义、权威的表示。Don’t Repeat Yourself！这不是你是否能记住的问题，而是何时忘记的问题。

强加的重复：

客户端服务器端不同语言：可以根据元数据在Build时生成不同语言的类定义及结构。

根据需求文档自动生成测试。

无意的重复：

需要缓存时可能会破坏DRY原则，但是应该在类内部解决，不要将其暴露给外界。

正交性

消除无关事物之间的影响。

可撤销性

不存在最终决策，采用灵活的架构。

曳光弹

用曳光弹找到目标，给出可展示的项目骨架，它可以即时的反馈。

原型与便笺

为了学习而制作原型。原型甚至可以不用编码，他需要确定各个组件的责任和是否解耦。

基本工具

用纯文本保存知识。它不会过时，更易测试。

要修正问题，而不是发出指责。

再现bug，使数据可视化。

向别人讲述你的代码要做什么时可能会帮助你理清思路。

不要假定，要证明。

注重实效的偏执

你不可能写出完美的软件。

DBC 按合约设计

前条件，后条件，类不变项。

死程序不说谎

早崩溃，要崩溃不要破坏。

断言式编程

如果他不可能发生，用断言确保。

弯曲，或折断

使模块之间的耦合减至最小。

要配置，不要集成。

将抽象放进代码，将细节放进元数据。

总是为并发进行设计。

使模型与视图分离。

当你编码时

不要靠巧合编程。

为你的假定建立文档。

早重构，常重构。这是一种痛苦管理。经常进行短小的重构之后测试。

测试驱动的设计。测试你的软件，否则你的用户就得测试。

与用户一同工作，以像用户一样思考。

抽象比细节获得更长久。

不要在盒子外面思考，要找到盒子，即真正的约束。亚历山大大帝用剑劈开了弗里吉亚国王戈尔系的号称解不开的结。

有些事情去做胜于描述，比如试着描述一下你系鞋带的过程。不要一开始编写太过详尽的规范。它和编码总是交替进行。

不要做形式方法的奴隶，有时原型展示比UML图更有说服力。昂贵的工具不一定能制作出更好的设计。

注重实效的项目

不要使用手工流程。

早测试，常测试，自动测试。

温和的超出用户的期望。与用户交流期望。

在你的作品上签名。这是责任和荣耀的表现。