程序员修炼之道 02：务实的哲学 ①

不记录，等于没读。

这里是我阅读《程序员修炼之道》这本书的记录。

---

在上一篇文章《前言》中，我们知道了：

1. 何为 务实的程序员 。
2. 这本书的目的是教你成为 务实的程序员 。

务实的编程源自一种务实思考的哲学。本文描述其中最基础的部分，即 务实的哲学 。

1 这是你的人生

It is your life.

人类是有意识、有目的、有选择能力的个体，具有主动地认识世界、改造世界以及自我改造的能力。你的人生如何度过，取决于你的选择。你可以努力经营自己的人生，主动争取自己想要的。就像保尔·柯察金的那句名言：人最宝贵的是生命。生命属于人只有一次。人的一生应当这样度过：当回忆往事的时候，他不会因虚度年华而悔恨，也不会因碌碌无为而羞愧。

这是你的人生，你理应努力经营。

在解决问题时展现的态度、风格和寻求解决方案的哲学，这一切，给人的印象是不靠谱，还是无可挑剔的专业人士？我们理当能自己掌控。我们相信自己可以成为一个更好的开发者，一个务实的程序员。我们了解来龙去脉，清楚要做什么，有担当、不行损害之事。

这是你的人生，你理应主动争取。

你觉得办公环境很差吗？
你觉得自己薪水过低吗？
你觉得团队一团糟吗？
你觉得当前项目的时间太紧张吗？

别期望它能自己变好，去改变它！作者认为本书最重要的提示是：你有权选择。

有不平之事，那就去要求。如果他们说不行，就去找个说行的人。OpenAI is nothing without its people ( 没有了员工，OpenAI 什么也不是)。你可以去改变组织，或是让自己换一个组织。

不要担心什么。作为一个务实的程序员，你是处于管理最底层且专长于干活的人，你不会被降级——再没有比你的岗位更低的职位了，你比其他任何人都有更大的威力！

2 我的源码被猫吃了

务实的程序员为所做的一切负责。对自己负责，对自己的行为负责，这是务实哲学的基石之一。

如果磁盘损坏，你所有的源码都在里面，而你没有备份，这就是你的错。跟你的老板说“我的源码被猫吃了”解决不了问题。

你有说“不”的权利，那些无理的截止日期，或者让你感到不安的事情，你都有拒绝的权利。但如果你同意某事情，这意味着你将对此事负责。你保证事情能搞定，并为之做出承诺，那你就要尽一切可能做好。如果失败了，让别人失望了，不要寻找借口。信任第一定律是：除了你自己，没人在乎你让别人失望的理由。你给人解释为什么做不完、为什么延期、为什么搞砸？没有意义的。别人会按照自己的判断形成对你的印象，判断的依据来自于你的行为，而不是说什么。

所以，未雨绸缪，把事情做成。或者在失败后坦白的承认自己的失误，想办法做些能挽回这个局面的事情。

提供选择，别找借口。

如果你在一个团队之中，更要为自己的言行负责。团队信任对于创新和协作至关重要。你的团队要能信任并依赖你，你也需要对团队中的每位成员感到安心。

想象一支装备高科技武器的忍者小队正潜入反派的秘密基地。经过数月精心策划与小心翼翼的执行，你们终于抵达现场。现在轮到你布置激光制导器时，你说：“抱歉兄弟们，我没带激光器。我家猫可喜欢它发出的红点，我就把它留在家里了。”

这种不靠谱的操作对信任的破坏可能难以修复。信任第二定律告诉我们：信任需要多年才能赢得，但只需一瞬间就可失去。然后信任第三定律告诉我们：人们不再信任你的时候不会告诉你。所以如果你的行为不可靠，可能在悄无声息之中，你就被团队抛弃。无论去哪个团队，无论在什么岗位，这样的事情一遍又一遍，还会发生。直到你学会担当，负起责任。

3 软件的熵

“软件的熵”这一概念借鉴了物理学中的熵（Entropy）概念，并将其应用于软件工程领域，用来描述软件系统的无序程度。热力学第二定律告诉我们：在一个封闭系统中，自发过程总是使系统的总熵趋于增大。引申到软件工程领域，是说软件会逐渐腐烂，不可逆转。这节讲述了软件腐烂的原因，以及减缓腐烂的策略。

导致软件腐烂的最重要原因是文化。这要从软件的质量说起。

软件的质量难以度量。Robert L.Glass 认为软件质量是七项属性的合集，这些属性分别是：可移植性、可靠性、效率、可使用性、可测试性、易理解性 以及 可修改性 (在项目开始时，确定这些属性的优先顺序非常重要) 。软件的质量难以度量，是因为这些属性全都难以度量。如果仔细观察这些属性，可以发现：这些属性都是深入的技术问题，要想得到较高的质量，必须要有深厚的技术知识。换句话说，决定软件质量的是程序员，而不是管理者。

如果管理者不能提供便利、消除障碍，而是紧盯进度表、随意修改需求，这就会造成一个不好的企业文化，身在这样的环境中，程序员为了赶进度，往往会走捷径，欠下技术债，然后软件会不可避免的加速腐烂。借用一位网友的话就是：

我们所在的部门、公司，他们的文化，到底是关心做出了一个东西，还是关心做好了一个东西？
如果一个人，总是给系统添加垃圾，留坑给后人，但是能很快做出跑起来的系统。我们到底认为他做了好事还是做了坏事，认为他很强还是很弱？那里的文化，到底应该是鼓励还是抑制这种行为？

我们过早地放弃了在代码上的工作，并不是因为它业已完成，而是因为我们的价值体系关注外在表现甚于关注要交付之物的本质。漫不经心最终结出了恶果：坏东西一再出现。

但不可否认的是，我们与项目的规划脱不了干系，对失败负有极大的责任；特别是失败与糟糕的代码有关时尤为如此！

经理和营销人员指望从我们这里得到必须的信息，然后才能做出承诺和保证；用户指望我们验证需求是否都在系统中实现了。项目经理指望我们遵守进度。他们会奋力护卫进度和需求；那是他们该干的。你则当以同等的热情卫护代码，你要勇敢的学会说“不”。

对不正之风说“不”。正如在前面说过的那样：别期望它能自己变好，去改变它！作为务实的程序员，我们有专业的知识，也有专业的态度，我们不产出垃圾。那些糟糕的设计、错误的决定、低劣的代码，我们要对这些“坏味道”保持敏感，绝不容忍。

不要只是因为一些东西非常危急，就去造成附带伤害。

---

既然提及了软件质量，这里分享一个公式，我第一次看到它时，瞬间顿悟了很多东西：

$$用户满意=满足需求+按时交付+适当的成本+产品质量$$

这个公式说明软件质量不是用户满意、满足需求、满足成本、满足时间表。软件质量是独立的、可以与软件的其它特性区分开来的特性。管理者能够决定需求、截止日期、成本，但他们不能决定质量。质量具有不可度量的特性，即便经过严格的测试，也无法断言其绝对优良。质量的优劣，只能由程序员的专业素养和责任心决定。在有些情况下，管理者蛮横的制定了不合理的需求、截止日期和成本，那么可以确定的是，质量会成为牺牲品。在进度压力面前，不那么务实的程序员会毫不犹豫的牺牲质量，最终导致用户不满意，特别是在维护阶段 。因为软件质量在时间上具有迟滞性，即开发阶段积累的技术债，会在维护阶段爆发出来。此时，前期对质量的误解与漠视，最终化为高昂的代价。

---

本文用到了以下书籍的观点：

• 《程序员修炼之道》
• 《代码整洁之道》
• 《软件工程的事实与谬误》
• 《咨询的奥秘》

---

每一份打赏，都是对创作者劳动的肯定与回报。！