《程序员修炼之道》读后感

前言

这篇是《程序猿修炼之道——从小工到专家》的摘要。初读此书，是在大三。再读此书，是工作后三年。期间有不少观点发生了变化，或有了深入的了解，故将这些小牢骚记录与此，一是作为此书的实践有感，二是记录自己的成长，三是越发感到此书虽薄，然而字字珠玑，愿自己能常回归，常思考，在否定否定中进步。

关心你的技艺

Care About Your Craft

如果你不在乎能否漂亮地开发软件,你又为何要浪费生命去开发软件呢?

思考!你的工作

Think! About Your Work

关掉自动驾驶仪,接管操作.不断地批评和评估你的工作

我思，故我在。假若不思考，便如流水线上的机器。常呆在舒适区，会固化人的思维，使人不思进取。若遇到了不可估计的突发事件，如公司倒闭，部门调整，便会不知所措。保持适度的警惕，尝试接受更多来自外界的反馈（如定期接受外界面试）。完成一项需求，尝试优化它的性能，完善它的功能，健壮它的逻辑，寻求更好的实现。即使是重复的工作，只要思考，都有可能发现自己的不足。生活何尝不如此呢？

提供各种选择,不要找蹩脚的借口

Provide Options, Don’t Make Lame Excuses

要提供各种选择, 而不是找借口. 不要说事情做不到; 说明能够做什么

不要容忍破窗户

Don’t Live with Broken Windows

当你看到糟糕的设计, 错误的抉择和糟糕的代码时, 修正它们

发现糟糕的设计，记录下来，不要贸然修正它们。先去了解全局的逻辑，前因后果，其次，设计你的代码，验证你的代码，最好能配套对应的测试用例。从发现，到设计，到实践，可能跨越几个月的时间，越是复杂的逻辑，越应保持应有的谨慎。当然，回归主题，面对需要长期维护的代码，在条件运行的情况，想方设法修正它，若暂时没有空闲的时间，用工具记录下来，加入你的TODO！

做变化的催化剂

Be a Catalyst for Change

你不能强迫人们改变. 相反, 要向他们展示未来可能会怎样, 并帮助他们参与对未来的创造

记住大图景

Remember the Big Picture

不要太过专注于细节, 以致忘了查看你周围正在发生什么

使质量成为需求问题

Make Quality a Requirements Issue

让你的用户参与确定项目真正的质量需求

定期为你的知识投资

Invest Regularly in Your Knowledge Porfolio

让学习成为习惯

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

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 Program domain

用你的用户的语言进行设计和编码

估算, 以避免发生意外

Estimate to Avoid Surprises

在着手之前进行估算. 你将提前发现潜在的问题

通过代码对比进行迭代

Iterate the Schedule with the code

用你在进行实现时获得的经验提炼项目的时间标度

用纯文本保存知识

Keep Knowledge in Plain Text

纯文本不会过时. 它能够帮助你有效利用你的工作, 并简化调试和测试

恩，这就是我一直维护我博客的原因。

利用命令行Shell的力量

Use the Power of Command Shells

当图形用户界面无能为力时使用Shell

用好一种编辑器

Use a Single Editor Well

编辑器应该是你的手的延伸; 确保你的编辑器是可配置, 可拓展和可编程的

总是使用源码控制

Always Use Source Code Control

源码控制是你的工作时间机器——你能够回到过去

了解Git的原理，熟悉基本的命令，适应不同的工作流。然后，选择一项跨平台的图形工具，eg：sourcetree。当开展个人项目，git init和npm init同样重要。

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

Fix the Problem, Not the Blame

bug是你的过错还是别人的过错, 并不是真的很有关系, 它仍旧是你的问题, 它仍然需要修正

分析问题，寻找原因，尝试在工作流的方式避免它。允许他人犯错，健壮自己的代码。越是没有经验的人越容易从别人身上寻找原因。学会抗压，总结原因。当然，避免和那些多次反馈问题而又不愿意改正的人合作。假若不得不，那么，健壮自己的代码。

不要恐慌

Don’t Panic When Debuging

做一次深呼吸, 思考什么可能是bug的原因

绝大部分时候，恐慌不会让你更快修正代码，反而更容易让你得到错误的代码。恐慌会使你的神经敏感，脾气变差，进而降低团队的工作效率。

“Select” 没有问题

“Select” Isn’t Broken

在OS或编辑器, 甚至是第三方产品或库中很少发现bug. bug很可能在应用中

不要假定, 要证明

Don’t Assume It - Prove It

在实际环境中——使用真正的数据和边界条件——证明你的假定

学习一种文本操纵语言

Learn a Text Manipulation Language

你用每天的很大一部分时间处理文本, 为什么不让计算机替你完成部分工作呢?

编写能编写代码的代码

Write Code That Write 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 Concurrenc

利用你的用户的工作流的并发性

用服务进行设计

Design Using Services

根据服务——独立的, 在良好定义, 一致的接口之后的并发对象——进行设计

总是为并发进行设计

Alaways Design for Concurrency

容许并发, 你将会设计出更整洁, 具有更少假定的接口

使视图与模型分离

Separate Views from Models

要根据模型和视图设计你的应用, 从而以低廉的代码获取灵活性

用黑板协调工作流

Use Blackboards to Coordinate Workflow

用黑板协调完全不同的事实和因素, 同时又使各参与方保持独立和隔离

不要靠巧合编程

Don’t Porgram By Coincidencs

只依靠可靠的事物. 注意偶发的复杂性, 不要把幸运的巧合与有目的的计划混为一谈

估算你的算法的阶

Estimate the Order of Your Algorithms

在你编写代码之前, 先大致估算事物需要多长时间

测试你的估算

Test Your Estimates

对算法的数学分析并不会告诉你每一件事情. 在你的代码的目标环境中测试它的速度

早重构, 常重构

Refactor Early, Refactor Often

就和你会在花园里除草, 并重新布置一样, 在需要时对代码进行重写, 重做和重新架构. 要铲除问题的根源

过多的重构反而容易导致无法追赶需求的进度。掌握合适的重构时机，必不可少，代码改动频繁，或BUG频出，或灵感迸发，想到了绝妙的实现手段，在理解了前因后果后，重构吧。

不及时重构的后果，可能是下次重构的难度比多次“除草”的难度总和还要大，因为可能你已经在杂草上盖上了狗窝，除草会让狗窝坍塌，导致了进退两难的地步。

为测试而设计

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 Thing 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 Test Run’

就是这样

通过”蓄意破坏”测试你的测试

Use Saboteurs to Your Testing

在单独的软件副本上故意引入bug, 以检验测试能够抓住它们

测试状态覆盖, 而不是代码覆盖

Test State Coverage, Not Code Coverage

确定并测试重要的程序状态

一个bug只抓一次

Find Bugs Once

一旦测试人员找到一个bug, 这应该是测试员最后一次找到它. 此后自动测试应该对其进行检查

视图的BUG，很难只抓一次，因为变动太频繁了！!

开发者在测试人员发现了三次类似的BUG后，将这个BUG加入自测的用例中。

越早发现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

过去时代的手艺人能为他们的作品签名而自豪. 你也应该如此

就代码而言，已经不需要在顶部写上你的名字了。这除了多一行尴尬无用的注释外，我没发现额外的作用。版本工具会帮你签名的，当然，你首先得用版本工具，如Git。

在团队工作中，除非有团队文化，或保密要求，最好用你真实的完整的名字，不要用那些乱七八糟的名字，没人关心你的外文名是jack还是joker。

就作品而言，恩，你当然要自豪地告诉别人，这是我的作品了。