《程序员修炼之道》简略笔记：1-4章

程序员修炼之道——从小工到专家， The pragmatic programmer: from journeyman to master.

这本书，感觉就是装13的书....

从宏观的概念去讨论程序员的修炼，做大方向的指导。可能是自己的实践经验很少，感触和共鸣也比较少。很多地方都是：“啊，这样啊，嗯，看起来应该如此”。但是没有：“啊！对！没错！就是这样的！”的感觉。

以后要重看。

第一章：注重实效的哲学

这一章，讲得是做为一名程序的基本修养。

要负责任，对项目，对上级，对下级。当遇到问题时，“不要说事情做不到，要说明能够做什么来挽回局面”。先把谈话预演一遍。情商问题。

不要容忍破窗户。Don't live with broken windows. 低劣的设计、错误的决策、糟糕的代码，发现一个修一个。如果没有足够的时间去修理，用木板钉起来。对问题加入注释，显示未实现等等，采取某种方法防止进一步的破坏，说明情形处在控制之下。说明注意到这个问题了。

石头汤与煮青蛙。做变化的催化剂。设计出你可以合理要求的东西，好好开发它。一旦完成，拿给大家看。激发动力，添加东西。但是也要注意，也可能是煮青蛙，往不好的方向发展。

足够好的软件。“今天的了不起的软件，常常比明天的完美软件更可取。”而且，给用户看，让他们使用，能更早获得反馈，引向更好的实现。

第二章：注重实效的途径

这一章，讲得是一些基本的方法、原则。

重复。DRY-Don't repeat yourself. 这个很重要。在很多个地方表示同一事物。如果改变其中一处，也必须记得改变其他地方。书中一个例子也很经典，关于start, end, length的关系问题。由于start, end的变化，就会导致length的变化。所以应该使用自动更新的方法来获得length的信息。这样就避免了重复。这是无意的重复。这里还提到了一个Uniform Access 原则。如下。还有开发者间的重复。

在ＷＳ中，就感觉到了这点。当时在app下做了一个dictionary的tool，但是要用到sdk的东东。问题是sdk不公开，所以调用不能。后来因为赶时间，就拷贝了一份sdk相关的东西，放在app下。造成了重复。还有其他的很多类似重复。改了一个地方，就要记得去改另一个。但往往不记得，或者改得很麻烦。

Uniform Access 原则，模块提供的所有服务都应能通过统一的表示法使用。该表示法不能泄漏它们是通过存储、还是通过计算实现的。说白了，就是都使用函数的方法，来获得一个东西。如通过obj.sth 这种成员的方式来获得。如果以后有更改，比如sth要经过某种计算，那么所有曾经调用过obj.sth的代码都要更改。很麻烦，特别是对于一些公开给别人使用的东东。所以，统一使用obj.sth()这种方式。更容易应对变更。

正交性。嗯，很应该。编写自足的组件，羞怯的代码。就是降低耦合。

可撤销性。永远不要以为以后就不变动了，所以必须支持可撤销。"如果某个想法是你的唯一的想法，再没有比这更危险的事情了“。“There are on final decisions(不存在最终决策). ”举了个例子，如果决定使用某个数据库，将第三方产品的调用缠绕在代码各处。那么万一要更改数据库，就会造成灾难。所以，应该把数据库的概念抽象出来，作为一种服务提供。

曳光弹。当不知道如何进行时，使用曳光弹，尝试去开发，如果可以，那么以此为骨架，进行架构，添加新功能，完善功能。其实我们大多数情况都是这么做的吧。。。这里还提到原型开发。原型制作是生成用过就扔掉的代码。但是曳光弹不是。它虽然简约，但是完整，并且构成了最终系统的骨架的一部分。曳光弹有很多好处。如可以尽早给用户体验获取反馈等等。

领域语言。这部分就牛掰了。使用yacc等，实现小型语言，供我们使用。这不就是在做一个编译系统？？越贴近我们解决问题的领域，的确越容易让人明白，但是做个编译系统太大了吧。。

估算。我的弱项。。

第三章：基本工具

嗯，看完这一章，觉得我真是个程序猿。还没进化到会使用工具的地步。

纯文本的威力。使用纯文本来记录信息，方便直观，让人容易理解。文本的存活时间也较长。但是当然，占据的空间也较大。像是Ｕｎｉｘ，用于系统管理（用户、密码、网络配置等），都是使用纯文本来进行存储。

shell游戏。shell真心好用。除了一些makefile等外，像对于经常使用的命令，存成ｓｈ，然后直接调用，很方便。

强力编辑。vi什么的，不熟练啊。

源码控制。git, 还有hudson这些。还有ws有用过。关键是自动的和可重复的产品构建。

代码生成器。编写能写代码的代码。但是还木有概念。。

第四章：注重实效的偏执

采用各种方法，来确保自己工作的正确性。

按合约设计。在ws的工作很有感触。与客户进行商谈时，必须要确定好合约。不能客户说改就改。当时，也不能说定得太细。因为有些时候，留有适当的余地，程序员才有创作的空间。同时我们最为第一手使用人员，也有一些设计的想法，让设备使用来更方便、顺手。

断言式编程。确保它不会发生。但是，注意不要在这过程引入新的bug，也即海森堡虫子（Heisenbug），调试改变了被调试系统的行为。

其他的。。没什么感觉了。。