今天读完了《程序员修炼之道——从小工到专家》（《The Pragmatic Programmer》），深深的觉得这种经典的书籍是值得我们反复去阅读的，可能每读一遍都会有新的收获。真的觉得这个中文译名很low，以后还是要锻炼自己读英文原版的能力。
今天先记录一下书中提到的一些tips，总共有70个。其实书里有快速参考指南，但是还是想记录一下，加深一下印象，也方便以后加一些自己对这些tips的理解吧。
- Care About Your Craft
关心你的技艺
如果你不在乎能否漂亮地开发出软件，你又为何要耗费生命去开发软件呢？
- Think! About Your Work
思考！你的工作
关掉自动驾驶仪，接管操作。不断地批评和评估你的工作。
- Provide Options, Don't Make Lame Excuses
提供各种选择，不要找蹩脚的借口
要提供各种选择，而不是找借口。不要说事情做不到；说明能够做到什么。
- Don't Live with Broken Windows
不要容忍破窗户
当你看到糟糕的设计、错误的决策和糟糕的代码时，修正它们。
- Be a Catalyst for Change
做变化的催化剂
你不能强迫人们改变。相反，要向他们展示未来可能会怎样，并帮助他们参与对未来的创造。
- Remember the Big Picture
记住大图景
不要太过专注于细节，以致忘了查看你周围正在发生什么。
- Make Quality a Requirements Issue
使质量成为需要问题
让你的用户参与确定项目真正的质量需求。
- Invest Regularly in Your Knowledge Portfolio
定期为你的知识资产投资
让学习成为习惯。
- Critically Analyze What You Read and Hear
批判的分析你读到的和听到的
不要被供应商、媒体炒作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行分析。
- It's Both What You Say and the Way You Say It
你说什么和你怎么说同样重要
如果你不能有效地向他人传达你的了不起的想法，这些想法就毫无用处。
- DRY - Don't Repeat Yourself
不要重复你自己
系统中的每一项知识都必须具有单一、无歧义、权威的表示。
- Make It Easy to Reuse
让复用变得容易
如果复用很容易，人们就会去复用。创造一个支持复用的环境。
- Eliminate Effects Between Unrelated Things
消除无关事物之间的影响
设计自足、独立、并具有单一、良好定义的目的的组件。
- There Are No Final Decisions
不存在最终决策
没有决策时浇铸在石头上的。相反，要把每项决策都视为是写在沙滩上的，并为变化做好计划。
- Use Tracer Bullets to Find the Target
用曳光弹找到目标
曳光弹能通过试验各种事物并检查它们离目标有多远来让你追踪目标。
- Prototype to Learn
为了学习而制作原型
原型制作是一种学习经验。其价值并不在于所产生的代码，而在于所学到的经验教训。
- Program Close to the Problem Domain
靠近问题领域编程
用你的用户的语言进行设计和编码。
- Estimate to Avoid Surprises
估算，以避免发生意外
在着手之前先进行估算。你将提前发现潜在的问题。
- Iterate the Schedule with the Code
通过代码对进度表进行迭代
用你在进行实现时获得的经验提炼项目的时间标度。
- Keep Knowledge in Plain Text
用纯文本保存知识
纯文本不会过时。它能够帮助你有效利用你的工作，并简化调试和测试。
- Use the Power of Command Shells
利用命令shell的力量
当图形用户界面无能为力时使用shell。
- Use a Single Editor Well
用好一种编辑器
编辑器应该是你的手的延伸；确保你的编辑器是可配置、可扩展和可编程的。
- Always Use Source Code Control
总是使用源码控制
源码控制是你的工作的时间机器——你能够回到过去。
- Fix the Problem, Not the Blame
要修正问题，而不是发出指责
bug是你的过错还是别人的过错，并不是真的很有关系——它仍然是你的问题，它仍然需要修正。
- Don't Panic When Debugging
不要恐慌
做一次深呼吸，思考什么可能是bug的原因。
- "Select" Isn't Broken
“Select”没有问题
在OS或编译器、甚或是第三方产品或库中很少发现bug。bug很可能在应用中。
- Don't Assume It - Prove It
不要假定，要证明
在实际环境中——使用真正的数据和边界条件——证明你的假定。
- Learn a Text Manipulation Language
学习一种文本操纵语言
你用每天的很大一部分时间处理文本，为什么不让计算机替你完成部分工作呢？
- Write Code That Writes Code
编写能编写代码的代码
代码生成器能提高你的生产率，并有助于避免重复。
- You Can't Write Perfect Software
你不可能写出完美的软件
软件不可能完美。保护你的代码和用户，使它（他）们免于能够预见的错误。
- Design with Contracts
通过合约进行设计
使用合约建立文档，并检查代码所做的事情正好是它声明要做的。
- Crash Early
早崩溃
死程序造成的危害通常比有问题的程序要小得多。
- Use Assertions to Prevent the Impossible
用断言避免不可能发生的事情
断言验证你的各种假定。在一个不确定的世界里，用断言保护你的代码。
- Use Exceptions for Exceptional Problems
将异常用于异常的问题
异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨。将异常保留给异常的事物。
- Finish What You Start
要有始有终
只要可能，分配某资源的例程或对象也应该负责解除其分配。
- Minimize Coupling Between Modules
使模块之间的耦合减至最少
通过编写“羞怯”的代码并应用德墨忒尔法则来避免耦合。
- Configure, Don't Integrate
要配置，不要集成
要将应用的各种技术选择实现为配置选项，而不是通过集成或工程方法实现。
- Put Abstractions in Code, Details in Metadata
将抽象放进代码，细节放进元数据
为一般情况编程，将细节放在被编译的代码库之外。
- Analyze Workflow to Improve Concurrency
分析工作流，以改善并发性
利用你的用户的工作流中的并发性。
- Design Using Services
用服务进行设计
根据服务——独立的、在良好定义、一致的接口之后的并发对象——进行设计。
- Always Design for Concurrency
总是为并发进行设计
容许并发，你将会设计出更整洁、具有更少假定的接口。
- Separate Views from Models
使视图和模型分离
要根据模型和视图设计你的应用，从而以低廉的代码获取灵活性。
- Use Blackboards to Coordinate Workflow
用黑板协调工作流
用黑板协调完全不同的事实和因素，同时又使各参与方保持独立和隔离。
- Don't Program by Coincidence
不要靠巧合编程
只依靠可靠的事物。注意偶发的复杂性，不要把幸运的巧合与有目的的计划混为一谈。
- Estimate the Order of Your Algorithms
估算你的算法的阶
在你编写代码之前，先大致估算事情需要多长时间。
- Test Your Estimates
测试你的估算
对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中测定它的速度。
- Refactor Early, Refactor Often
早重构，常重构
就和你会在花园里除草、并重新布置一样，在需要时对代码进行重写、重做和重新架构。要铲除问题的根源。
- Design to Test
为测试而设计
在你还没有编写代码时就开始思考测试的问题。
- Test Your Software, or Your Users Will
测试你的软件，否则你的用户就得测试
无情地测试。不要让你的用户为你查找bug。
- Don't Use Wizard Code You Don't Understand
不要使用你不理解的向导代码
向导可以生成大量代码。在你把它们合并进你的项目之前，确保你理解全部这些代码。
- Don't Gather Requirements - Dig for Them
不要搜集需求——挖掘它们
需求很少存在于表面。它们深深地埋藏在层层假定、误解和政治手段下面。
- Work with a User to Think Like a User
与用户一同工作，以像用户一样思考
要了解系统实际上将如何被使用，这是最好的方法。
- Abstractions Live Longer than Details
抽象比细节活得更长久
“投资”于抽象，而不是实现。抽象能在来自不同的实现和新技术的变化的“攻击”之下存活下去。
- Use a Project Glossary
使用项目词汇表
创建并维护项目中使用的专用术语和词汇的单一信息源。
- Don't Think Outside the Box - Find the Box
不要在盒子外面思考——要找到盒子
在遇到不可能解决的问题时，要确定真正的约束。问问你自己：“它必须以这种方式完成吗？它真的必须完成吗？”
- Start When You're Ready
等你准备好再开始
你的一生都在积累经验。不要忽视反复出现的疑虑。
- Some Things Are Better Done than Described
对有些事情“做”胜于“描述”
不要掉进规范的螺旋——在某个时刻，你需要开始编码。
- Don't Be a Slave to Formal Methods
不要做形式方法的奴隶
如果你没有把某项技术放进你的开发实践和能力的语境中，不要盲目地采用它。
- Costly Tools Don't Produce Better Designs
昂贵的工具不一定能制作出更好的设计
小心供应商的炒作、行业教条、以及价格标签的诱惑。要根据工具的价值判断它们。
- Organize Teams Around Functionality
围绕功能组织团队
不要把设计师与编码员分开，也不要把测试员与数据建模员分开。按照你构建代码的方式构建团队。
- Don't Use Manual Procedures
不要使用手工流程
shell脚本或批文件会一次次地以同一顺序执行同样的指令。
- Test Early.Test Often.Test Automatically
早测试，常测试，自动测试
与呆在书架上的测试计划相比，每次构建时运行的测试要有效得多。
- Coding Ain't Done 'Til All the Tests Run
要到通过全部测试，编码才算完成
就是这样。
- Use Saboteurs to Test Your Testing
通过“蓄意破坏”测试你的测试
在单独的软件副本上故意引入bug，以检验测试能够抓住它们。
- Test State Coverage, Not Code Coverage
测试状态覆盖，而不是代码覆盖
确定并测试重要的程序状态。只是测试代码行是不够的。
- Find Bugs Once
一个bug只抓一次
一旦测试员找到一个bug，这应该是测试员最后一次找到它。此后自动测试应该对其进行检查。
- English is Just a Programming Language
英语就是一种编程语言
像你编写代码一样编写文档：遵守DRY原则、使用元数据、MVC、自动生成，等等。
- Build Documentation In, Don't Bolt It On
把文档建在里面，不要拴在外面
与代码分离的文档不太可能被修正和更新。
- Gently Exceed Your Users' Expectations
温和地超出用户的期望
要理解你的用户的期望，然后给他们的东西要多那么一点。
- Sign Your Work
在你的作品上签名
过去时代的手艺人为能在他们的作品上签名而自豪。你也应该如此。
