最近时间比较多，抽了4天时间读完了程序与经典书籍《程序员修炼之道》，结论是，这是一本适合多次阅读的书籍。
这是一本讲程序员内功的书籍，涵盖了设计一个的产品各个点，包括：设计，编码，测试，管理，文档等等，书中始终围绕的一个中心就是：注重实效的程序员应该如何做。
我选了一些有意思的内容分享给大家。
领域语言
让我想起了《代码的未来》中提到的DSL(Domain Specific Language)，在我们工作中会经历各种DSL，在我们需要的时候，我们可以自己来书写DSL。
如果出现了Bug,记住：
死程序不会说谎：
我是做测试出生，当时提交 Bug 到程序员那边，经常会被回应：怎么可能会有这个问题？现在我自己做程序员了，我发现我依然没有跳出这个怪圈，要时刻提醒自己死程序不会说谎。
断言式编程：
如果它不可能发生，用断言确保它不会发生。
里面举了两个例子来让我们对断言反思，很有意思：
（1）1752年9约只有19天，为使日历同步而进行的。 （2）非欧几何中，三角形的内角和不等于180°，想一想投影在球面上的三角形？
元数据
使用元数据来解耦，要配置，不要集成。
考虑并发：
软件设计的适时候，我们要考虑并发的情况，以提高效率。
不要靠巧合编程：
不要试，要证明；
这又是很多人学习新技术的通病，我们不但要知其然，而且要知其所以然。
算法：
1.估算你的算法。测试你的估算； 2.最高效的算法并非总是最好的。
重构：
早重构，常重构。
书里关于重构的内容讲得比较少，但是重构的方向已经给我们指明，使用重构这个武器，我们可以战胜两个敌人：提前超详细设计和烂代码。
需求：
与用户一同工作，像用户一样思考。
里面举了一个需求之坑，也很有意思：
“只有员工的上级和人事部门才可以查看员工的档案” “只有得到授权的用户可以访问员工档案”
哪个才是我们真正的需求？
维护词汇表，Use a project glossary 来让我们高效沟通吧。
测试：
早测试，常测试，自动测试：编一点，测一点。
要到通过全部测试，编码才算完成。
通过“蓄意破坏”测试你的测试。
测试状态覆盖，而不是代码覆盖。
为新bug编写新的测试；
文档：
代码中的注释应该讨论为何做某事，它的目标和目的。
让不同形式的文档内容保持一致：文档和代码是同一底层模型的不同视图。对待文档要像对待代码一样用心。
责任：
代码署名，代码所有人，责任。
我们的目的是：多年以后，当我们的孙子看到我们编写的代码的时候，他的眼里也会闪过一丝骄傲。
注重实效的团队：
- 不要留破窗户：
最勤勉的开发者如果被派到不在乎质量的团队里，会发现自己很难保持修正琐碎问题所需的热情。
注重检测环境的变化；
交流：一个方法给自己的项目团队创建一个名字和LOGO来增加归属感。
不要重复，重复代码，重复功能等等。
按照功能划分团队。而不是按工作职务来划分组织。
自动化：效率最大化。
制作完美软件的时候，要知道何时停止绘画？
最终结论：
注重实效的程序员应该不断学习！果然是这个样子。
本书结尾推荐的书籍：
经典好书，不要错过。
分析与设计：
Object-Oriented Software Construction 2nd Edition
Design Patterns
Analysis Patterns
团队与项目：
The Mythical Man Month.
Dynamics of Software Development
Surviving Object-Oriented Projects: A Manager’s Guide
具体环境：
Unix:
Advanced Programming in the Unix Environment
Unix Network Programming
本文链接： http://lijinma.com/blog/2014/08/06/learn-from-the-pragmatic-programmer/