01程序员修炼之道阅读笔记之一

01程序员修炼之道阅读笔记之一

第一章：注重时效的哲学

第一节：我的代码让猫给吃了

在做项目的过程中，我们每个人难免会犯错。对于这类错误，单单一句“我的代码让猫吃了”，是远不能解决的。这时候需要自己主动承担这份责任，主动承认错误。并且在最快的时间内提供解决方案，尽可能地挽回局面。

第二节：软件的熵

熵是一个热力学概念，指的是在某个系统中的“无序”的总量，热力学定律指出宇宙中的熵总是倾向于最大化。软件工程里中也存在这么一个定律，工程越庞大，代码的“无序”状态越严重。

根据破窗效应，项目的腐烂并不是突然发生的，而是由一个小的漏洞引起的，另一个人接手之后，并不会修复它，还会在原来的基础上进行破坏。对于这类问题的解决，是在发现漏洞伊始，便召集团队进行修复。毕竟，一个优美的景区，谁也不愿意把它弄脏的。

第三节：石头汤和煮青蛙

石头汤和温水煮青蛙的故事都是听过的。

有时候，我们不需要要求别人如何办事，我们只需要将项目设计好，将小的成品展示给大家，然后向其他成员提出需求（前提是你的项目足够吸引人），将所有人拉到自己的身边。做团队的催化剂，实现共赢；同时，我们需要时刻关注周围的变化，并且利用这种变化，将团队的“蛋糕”做大。

第四节：足够好的软件

现实生活中，我们往往不能保证产品的质量。所以指定需求时，把质量这一块考虑进去，在商定的时间内，由产品或者客户决定他们可以接受的质量是什么样的。

没有完美的软件，应该知道何时止步。今天了不起质量高的软件往往是由用户决定的，开发人员仅需要尽可能满足用户的需求，及早让客户使用，他们的反馈常会把你引向更好的解决方案。

第五节：你的知识资产

本杰明·富兰克林说过：知识上的投资总能得到最好的回报。这没问题，但遗憾的是知识是有时效的资产，特别是计算机领域。我们可以把我们了解的技术实现、工作经验视为知识资产，并使用管理金融资产的形式管理这些知识。

经营知识资产可以从以下方面进行：

定期投资：定期投入时间学习，即使很小的投资也是很重要的。

多元化：作为底线我们需要对当前所从事的技术熟练掌握。但不要就此止步，技术的发展 变化很快，掌握的知识越多，就越能更好的进行调整，赶上变化。

管理风险：不要把所有的“技术鸡蛋”放到一个篮子里。

低买高卖：新技术流行之前就掌握它往往比之后跟风再学得到更大的回报。

第六节：交流

在一个有效的交流中，我们可以得到许多信息，从而升华自己的项目。

一个真正有效的交流，发言者必须知道自己在说什么，了解自己的听众。信息紊乱以及不了解听众，无法将自己的项目表达清楚，听众也只会做做样子。

同时，发言的时机也很重要，选择合适的时机能让你的发言事半功倍。

在介绍自己的文档时，让其保持优美，直观准确的表达自己的观点。

在做发言者的同时，也要学会做倾听者，让观众参与到你的项目。

第二章：注重时效的途径

第七节：重复的危害

强加的重复：开发者觉得他们无可选择，其实是有一些方法让我们避免重复的

无意的重复：设计中的错误，开发者并没有意识到自己的错误，需要提高代码意识。

无耐性的重复：在时间压力之下，开发者进行偷懒。

开发者之间的重复：众多开发者使用同意公共区域，进行了多次重复，主要缺少交流。

第八节：正交性

正交性是一个从几何学中借鉴而来的术语，如果两条直线相交成直角，他们就是正交的。这在向量中的解释是沿着一条直线移动，你投影到另一条直线上的位置不变。

正交的好处是它提高生产效率，各个组件不相互依赖，使得改变得以局部化，促进复用，对于正交组件进行组合也可以提高生产效率，同时它还降低了代码的风险。

延伸开来，项目团队的配合也应该遵循正交性。如果成员之间任务重叠较多容易让大家疑惑问题和责任的归属如何划分，这会造成配合的效率低下。

第九节：可撤销性

如果某个想法是你唯一的想法，那再没有比这更危险的事情了。

在开发过程中，保持代码的灵活性，为随时出现的错误做准备，构建一个灵活的框架，让代码能够“摇滚”。

第十节：曳光弹

聪明的程序员往往使用曳光弹。

在黑暗中发光的代码——曳光代码，适合不熟悉的项目。使用曳光代码，保留了完整的错误检查，只不过功能不全而已。它有以下优点：

用户能够及早的看到能工作的东西。

开发者构建了一个能在其中工作的结构。

你有了可用于演示的东西。

你能共感觉到工作的进展。

第十一节：原型与便签

制作原型是一种学习经验，其价值不在于产生代码，而在于从其中所得到的经验教训。

使用原型可以忽略细节：正确性、完整性、健壮性、风格。

制作原型不需要编码，只需要实现逻辑模型。制作原型时需要考虑以下问题：

·主要组件的责任是否得到了良好定义？是否恰当？

·主要组件间的协作是否得到了良好的定义？

·耦合是否得以最小化？

·你能否克服确认重复的潜在来源？

·接口定义和各项约束是否可接受？

第十二节：领域语言

计算机语言会影响你思考问题的方式，以及你看待交流的方式。

无论用于控制和配置应用程序的简单语言，还是用于制定规则或过程的更为复杂的语言，你都应该考虑让你的项目更接近问题领域。

易于开发还是易于维护，决定了采用哪种语言。

第十三节：估算

估算，以避免发生意外。

在估算的过程中，你将会加深对你的程序所处的世界的理解。

多准确才足够准确？130 个工作日和大概 6 个月，是不同的，显然，前者表示的精度更高。我们在做估算的时候也需要选好描述估算时间的单位值。

估算结果怎么来呢。

首先需要确认你是否理解了需求所涉及的各个方面，这个是前置条件。

然后你需要建立系统模型，在这个系统中，把模型分拆成各个组件，然后给每个参数设置定一个值，最后根据模型计算一个时间。

模型应该是一个动态的，它像一个人工智能模型，你需要持续不断的训练它，才能使它真正准确起来。每次的估算都需要记录，反思估算效果，找出影响因素，加入新的影响项或者调整对应参数。

被要求进行估算时间时，我们可以这样回答：我等会儿回答你。然后花点时间仔细检查我们在这一节描述的步骤，你总能得到更好的结果。

第三章：基本工具

第十四节：纯文本的威力

纯文本由可打印字符组成，人可以直接阅读和理解其形式。纯文本没有结构，可用于保存知识。

文本的威力：保证不过时、杠杆作用、更易于测试。

第十五节：shell游戏

对于程序员来说，shell命令就是工作台。

对于习惯 GUI 的开发者来说一直使用 Shell 有些极端。GUI 的好处是所见即所得，但他的缺点却是，所见即全部所得。GUI 环境通常受限于它们的设计者想要提供的能力。

Shell命令可能很晦涩，或太简略，但很强大，也很简练。熟悉shell命令之后，你的生产效率将会提高。

第十六节：强力编辑

坚持使用一种编辑器，如果不坚持使用，你就可能面临现代的巴别塔大混乱。同时，你需要学会精通它。

使用一种高级的IDE,它能够在一定程度上提高生产效率。

第十七节：源码控制

Undo键和ctrl+z——原谅我们错误的按键。而源码控制系统就相当于一个巨大的 UNDO 键，一个项目级的时间机器。源码控制系统（SCCS）能够追踪你在源码和文档中做的每一项改动。

总是使用源码控制系统，即使只有你一个人，即使你的项目很小。

第十八节：调试

调试会占用大量的时间。

调试就是解决问题，发现bug后，最重要的是解决问题，不是指责。

调试时不要恐慌，正确对待出现的bug。

将你的数据可视化，譬如采用循环链表。

跟踪代码。发生 crash 我们能够查看系统的调用堆栈，但这些数据不一定够。对于非 crash 类错误，因为没有抛出，我们甚至不知道发生了什么。所以添加所谓的跟踪日志很有必要，这类日志最好采用统一规范，便于后期我们可以自动解析他们。

橡皮鸭，也叫小黄鸭调试法。遇到无法定位的问题时，对着小黄鸭（屏幕）解释自己的实现逻辑，很可能在说的过程中你自己就发现了问题所在。

不要第一时间怀疑 OS，IDE，三方库的问题，他们出问题的概率比你代码出问题概率小得多。我们应该首先确认和排查自己的问题。

对 bug 原因进行复盘。修复了一个 bug，不要就让它结束了，想一下，为什么它会出现了，如何避免。定位过程如果耗时较长，也需要复盘下为何花费了那么长时间，以及后续如何优化。

第十九节：文本操纵

学习一种文本操纵语言，其作用十分广泛。

第二十节：代码生成器

作为一个程序员，我们需要一个工具用来减少代码的编写。

被动代码生成器：减少敲键次数，本质是参数化模板。可创建新的源文件、在编程语言之间进行一次性转换、生成查找表以及其他在运行时计算很昂贵的资源。

主动代码生成器：在编译时就能出抓住错误，不用等投入运行时发现。

代码生成器不一定很复杂，同时也不一定生成代码。