程序员修炼之道

1、  经营你的知识资产

           定期投资、多元化（你知道的不同事情越多，你就越有价值（但也要精通）。你掌握的技术越多，你就越能更好地进行调整）、管理风险（技术覆盖范围要广）、低买高卖（善于抓住有潜力的技术）、重新评估和平衡你学的技术还是否有用。

           目标：每年至少学习一种语言、每季度阅读一本技术书籍、也要阅读非技术书籍、试验不同的开发环境、了解周围以及潮流+多跟人交流。

           要批判的思考，批判的思考你读到的和听到的。你要确保你的资产中的知识是准确的，并没有受到供应商或媒体炒作的影响。

           把握学习机会。让自己在空闲的片刻时间里总有东西可读。

 2、可撤销性

         要把决策视为写在沙滩上而不是把它们刻在石头上。大浪随时可能到来，把它们抹去。

         不存在最终决策。

         很多人设法保持代码的灵活性，而你还需要考虑维持架构、部署及供应商集成等领域的灵活性。

3、曳光弹

         曳光代码方法处理的问题与原型制作（好比画了一个界面原型，一旦作出决策，你都会重新开始在其最终环境中为算法编写代码）不同。你需要知道应用怎样结合成整体。你想要向用户演示，实际的交互是怎样工作的，同时你还想要给出一个架构骨架，开发者可以在其上增加代码。在这种情况下，你可以构造一段曳光代码，其中含有一个及其简单的集装箱装箱算法实现和一个简单、但却能工作的用户界面。一旦你把应用中的所有组件都组合在一起，你就拥有了一个可以向你的用户和开发者演示的框架。接下来的时间里，你给这个框架增加新功能，完成预留了接口的例程。但框架仍然保持完整，而你也知道，系统将会继续按照你第一次的曳光代码完成时的方式工作。

4、纯文本的威力（能力不够，还无法深刻体会）

         保证不过时、杠杆作用（从源码管理系统到编译器环境，再到编译器及独立的过滤器，都能在纯文本上进行操作）、更易于测试。

5、选一个强力编辑器作为你的利剑（vi）！确保你的编辑器是可配置、可扩展和可编程的。

6、总是使用源码控制（always use source code control）。

7、学习一种文本操纵（如测试数据生成、生成web文档等）语言：unix的如shell等，python，Tcl，perl等。

8、代码生成器（不太懂）：被动代码生成器本质上是参数化模板；主动代码生成器，如schema某一列被移走，那么访问代码中相应的字段也将消失。

         让输入格式保持简单，代码生成器就会变得简单。

9、按合约设计（这个还不能够深入体会，这跟写注释区别在哪）。

         在类或方法前面描述类或方法的前条件（为了调用例程，必须为真的条件；例程的需求）、后条件（例程保证会做的事情，例程完成时世界的状态）、类不变项（类确保从调用者的视角来看，该条件总是为真）。

22、死程序不说谎

         java中已经有很好的异常机制。对于c语言，可以通过#define定义宏，对每个类编写相应的状态检测方法，如果遇到异常则打印错误信息。

23、断言式编程

         如果它不可能发生，用断言确保它不会发生。但不要用断言代替真正的错误处理（如对于一个输入，用断言判断输入是否为指定的数，这不是个好想法）。

         Heisenbug：调试改变了被调试系统的行为。

         让断言开着，在c语言中用if语句让断言成为可选的，像java等提前设置编译时标志，java-ea AssertTest开启断言；-da是禁用断言。

24、何时使用异常

         将异常用于异常的问题。（例如，当你编写程序打开文件，你无法肯定该文件是否存在，那你引发无法找到文件的异常是没有正当理由的。如果你确定文件一定存在，那找不到文件异常是可以的）。

25、怎样配平资源

         DRY原则：是“Don'tRepeat Yourself”的缩写。意思是说，在一个设计里，对于任何东西，都应该有且只有一个表示，其它的地方都应该引用这一处。这样需要改动的时候，只需调整这一处，所有的地方就都变更过来了。（网上摘抄）

         资源分配要有始有终，有分配就要对应有释放。如文件的打开关联文件的关闭。

         一些习惯：C和C++开发者故意在解除了某个指针引用的内存分配之后，把该指针设为UMLL（防止如解决了某个内存块分配，随后又在程序中引用该内存）。java在使用完某个对象后，把该对象变量设为NULL（使指向被引用对象数目减一。一旦减为零则对象就会符合垃圾收集的条件）。

26、解耦与得墨忒耳法则

         函数的得墨忒耳法则规定，某个对象的任何方法都应该只调用属于以下四种情形的方法：

class Demeter{

         private:

          A *a;

         int func();

         public:

         void example(B&b);

         voidDemeter::example(B& b){

                   C c;

                   int f = func();//它自身

                   b.invert();//传入该方法的任何参数

                   a = new A();

                   a->setActive();//它创建的任何对象

                   c.print();//任何直接持有的组件对象

         }

}对于函数中有*c，然后通过b函数返回C的实例，则在example中访问c.**方法则算违反法则。

         要不要遵守该法则也是有选择的，事实上通过反得墨忒耳法则可以使模块紧密耦合，性能更快，所以还是看个人选择。

27、元程序设计

         要配置，不要集成；元数据驱动的应用；（这节无法深层次领悟）

28、时间耦合

         分析工作流，以改善并发性（analyzeworkflow to improve concurrency）

29、MVC

30、黑板系统

         黑板（就像侦探们讨论的黑板，每个人不同时候都可以交流），使得数据到达的次序无关紧要：在收到某项事实时，它可以触发适当的规则。反馈也很容易处理：任何规则集的输出都可以张贴到黑板上，并触发更为适用的规则。

31、不要靠巧合编程

         要总是意识到你在做什么，不要盲目编程，按照计划行事。为你的假定建立文档，并且不仅测试你的代码，还要测试你的假定。最后，不要做历史的奴隶。针对以前的不适用代码，随时准备好重构。

32、算法速率

         估算自己算法的阶，并测试你的估算。

33、重构

         现在没能进行重构，沿途修正问题将需要投入多得多的时间——那时将需要考虑更多的依赖关系。

34、易于测试的代码

         有利于发现bug的方法：（1）含有跟踪消息的日志文件（格式应该正规）；（2）“热键”序列。按下特定的键组合，就会弹出一个诊断控制窗口（最终用户并不知道）；（3）对于更大更复杂的服务器代码，提供其操作的内部视图的一种技术是使用内建的web服务器。

35、邪恶的向导

         不要使用你不理解的向导代码（即靠按键自动生成的代码）。

37、解开不可能解开的谜题

         解开谜题的秘诀是确定真正的约束，并在其中找出解决方法，有些约束是绝对的，有些则是先入为主的。（就像脑筋急转弯一样的思考···）如四个点，你只能用三条直线就把它们连接起来，并且最后回到落笔点。

39、规范陷阱

         对有些事情“做”胜于描述；作为注重实效的程序员，应该倾向于把需求搜集、设计、以及实现视为同一个过程——交付高质量的系统——的不同方面。越是把规约当做安乐毯，不让开发者进入coding，进入编码阶段就越困难。

40、圆圈与箭头

         不要做形式方法的奴隶，昂贵的工具不一定能制作出更好的设计。

41、注重实效的团队

         （1）不要容忍那些小小的、无人修正的不完美，团队必须为产品的质量负责。不要留破窗户。

         （2）确保每个人都主动地监视环境的变化，对新需求进行持续的度量。避免煮青蛙现象。

         （3）多交流。

         （4）不要重复。DRY原则。

         （5）围绕功能，而不是工作职务进行组织。

43、测试的重要性（单元测试、集成测试、验证和校验、资源耗尽、错误及恢复、性能测试、可用性测试）。

45、极大的期望

         用户在一开始就会带着他们对所需要的东西的想象来到你面前。那可能不完整、不一致、或在技术上不可能做到，但那是他们的，他们也在其中投入了一些感情。

         给他们的东西要比他们期望的多一点。给系统增加某种面向用户的特性所需的一点额外努力将一次又一次在商誉上带来回报。

46、傲慢与偏见

         注重实效的程序员不会逃避责任。相反，我们乐于接受挑战。当人们在一段代码上看到你的名字，应该期望它是 可靠的、用心编写的、测试过的和有文档的，一个真正的专业作品，由专业人员编写。