Skip to content

第一版 ​

务实(Pragmatic)这个词来自拉丁语 pragmaticus ------ "精通业务",该词又来源于希腊语 πραγματικός ,意思是 "适合使用"。

"务实" 一词源远流长。

编程是一门技艺。简单地说,就是让计算机做你想让它做的事情(或是你的用户想让它做的事情)。作为一名程序员,你既在倾听,又在献策;既是传译,又行独裁;你试图捕捉难以捉摸的需求,并找到一种表达它们的方式,以便仅靠一台机器就可以从容应付。你试着把工作记录成文档,以便他人理解;你试着将工作工程化,这样别人就能在骑上有所建树;更重要的是,你试图在项目时钟的滴答声中完成所有这些工作。你每天都在创造小小的奇迹。

编程是一门技艺。同时它也需要和别人沟通。程序员可以和人很好地沟通,如果不能,可能就不会有人知道他,因为他是靠作品交流的。

这就让务实主义有了用武之地。你不应该拘泥于任何特定的技术,而应该拥有足够广泛的背景和经验基础,以便在特定的情况下选择合适的解决方案。你的背景来自对计算机科学基本原理的理解,而你的经验来自广泛的实际项目。理论结合实践会让你变得强大。

实践是检验真理的唯一标准。不必拘泥于特定技术,要有足够广泛的背景和经验基础,以便在特定的情况下选择合适的解决方案。背景来自于对计算机科学基本原理的理解,而经验来自广泛的实际项目。

调整方法去适应当前的情况和环境。对所有影响项目因素的相对重要性进行判断,并通过经验找到适当的解决方案。随着工作的进展,你要不断地这样做。

根据具体情况变通,依据经验和已有知识进行判断。

作为务实的程序员,会共有许多以下特征:

早期的采纳者/快速的适配者

你对技术和技巧有一种直觉,喜欢尝试。当接触新东西时,你可以很快地掌握它们,并把它们与其他的知识结合起来。你的信心来自经验。

好奇

你倾向于问问题。这真不错------你怎么做到的?你对那个库有意见吗?总在听人说起的量子计算到底是什么?符号链接是怎么实现的?你热衷于收集各种细微的事实,坚信它们会影响自己多年后的决策。

批判性的思考者

你在没有得到证实前很少接受既定的现实。当同事们说 "因为就该这么做",或者供应商承诺会解决所有问题时,你会闻到挑战的味道。

现实主义

你试图理解所面临的每个问题的本质。这种现实主义让你对事情有多困难、需要用多长时间有一个很好的感知。一个过程应该很难,或是需要点时间才能完成,对这些的深刻理解,给了你坚持下去的毅力。

多面手

你努力熟悉各种技术和环境,并努力跟上新的进展。虽然目前的工作可能要求你在某个专门领域成为行家,但你总是能够进入新的领域,迎接新的挑战。


我们把最基本的特征留到最后。所有务实的程序员都有这个特征。它足够基本,完全可以作为提示来加以声明。

提示 1 关注你的技艺

我们觉得,如果你不关心怎么把软件开发好,那么软件开发领域就再也没什么好谈的事情了。

提示 2 思考!思考你的工作

为了成为一名务实的程序员,我们要求你在做事的时候,思考一下自己正在做什么。这不是对当前实践做的一次性审计


而是对每天里每一个项目所做的每一个决定进行的批判性评估。不要用自动辅助驾驶系统偷懒,而是要不断地思考,即时地批判自己的工作。 IBM 公司的座右铭 "思考!",实属每个务实程序员的真言。

关注怎么把软件开发好最重要;

思考工作的意义;

多面手

现实主义

批判的思考者

好奇

早期的采纳者/快速的适配者

如果你觉得这听起来很困难,那么你就表现出了现实主义的特征。这会占用你一些宝贵的时间


可能是已经处于巨大压力之下的时间。当然会有回报, 你能更积极地投入喜欢的工作,对越来越多的学科有掌控感,对不断进步产生愉悦感 。从长期来看,时间投资将得到回报,因为你和你的团队将变得更高效,能编写出更容易维护的代码,并且在会议上花的时间更少。

处于巨大压力之下,让自己保持愉悦感。

务实的个体,大型的团队

有些人认为在大型团队或复杂的项目中没有个性的空间。"软件是一门工程学科,"他们说,"如果团队成员个体自行其是,软件就会崩溃。"

大型团队中不容许个体特征呈现。

我们强烈反对这种看法。

诚然,软件构造有工程的成分。然而,这并不妨碍个体的技艺。想想中世纪在欧洲建造的大教堂,每一座都需要数千人年的努力,时间跨度长达几十年。从中吸取的经验教训被传递给下一代的建造者,最终一代代累积的造诣推动了结构工程的发展。而木匠、石匠、雕刻师和玻璃工人都是手工艺人


通过吃透工程要求,其创造所体现出的整体水准,已远超建筑中纯机械的部分。正是他们对个人贡献的信念支撑着这些项目:我们,采集的只是石头,却必须始终展望着未来的大教堂。

在一个项目的整体结构中,总有个性和技艺的空间。考虑到软件工程的当前状态,这一点尤为正确。今天的土木工程师,很难接受中世纪大教堂建造者使用的技术

百年后我们的工程看上去也一样古老,而我们的技艺仍将受到尊重。

1 我的源码让猫吃了 ​

注重实效的程序员的特征是什么?我们觉得是他们处理问题、寻求解决方案时的态度、风格、哲学。他们能够直接跃出直接的问题去思考,总是设法把问题放在更大的语境中,总是设法注意更大的图景。毕竟,没有这样的更大的语境,你有怎能注重实效?你又怎能做出明智的妥协和有见识的决策?

他们成功的关键是他们对自己所做的每件事情负责,关于这一点,我们将在 "我的源码让猫给吃了" 中加以讨论。因为负责,注重实效的程序员不会坐视他们的项目土崩瓦解。在 "软件的熵" 中,我们将告诉你怎样使你的项目保持整洁。

大多数人发现自己很难接受变化,有时是出于好的理由,有时只是因为固有的惰性。在 "石头汤与煮青蛙" 中,我们将考察一种促成变化的策略,并(处于平衡的兴趣)讲述一个忽视渐变危险的两栖动物的警世传说。

理解你的工作的语境的好处之一是,了解你的软件必须有多好变得更容易了。有时接近完美是唯一的选择,但常常会涉及各种权衡。我们将在 "足够好的软件" 中探究这一问题。

当然,你需要拥有广泛的知识和经验基础才能赢得这一切。学习是一个持续不断的过程。在 "你的知识资产" 中,我们将讨论一些策略,让你 "开足马力"。

最后,我们没有人生活在真空中。我们都要花大量时间与他人打交道。在 "交流!" 中列出了能让我们更好地做到这一点的几种途径。

注重实效的编程源于注重实效的思考的哲学。本章将为这种哲学设立基础。

第二版 ​

第一章 务实的哲学 ​

一个务实的程序员能够透过问题表面,将问题放在更宽泛的上下文综合考虑。

了解当前项目的来龙去脉,有利于把握项目接下来的发展脉络。

要做到以上几点,要大量的知识和经验。

人生是你自己的,是你在拥有、经营和创造。

在自己的职业发展、学习教育,以及项目和每天的工作等方面对自己负责,对自己的行为负责。

团队需要能够信赖我,我也要信赖团队里的每个人。

我想承担责任意味着我对这件事很是认同,保证能够完成,并做出承诺。我还必须分析超出我能力的风险情况。

如果责任并不明确,或是风险过大,都有权不承担责任。

不要把问题归咎于其他人,多想想自己能做什么。

提供选择,别找借口。

别害怕请教别人,别害怕承认自己需要帮助。

在说“我不知道”后,一定补上“------但是我会去搞清楚”。

软件的熵------软件的混乱程度。

负面情绪容易传染。

不要放任糟糕的设计、错误的决定、低劣的代码不去修理。

First, Do No Harm.

软件开发过程中,对应急问题的处理办法,不要干扰正常代码的运转。

项目协作:知道如何“借来”资源。找到合理需求,不断完善,一旦有成果的展示给大家看,这时可以说“当然了,它可以更好,只要我们再加点......”这句话。

持续审视身边和整个领域发生的事情,不要只专注自己在做的事情。

构建够好即可的软件。

投资知识,收益最佳。

知识组合:程序员了解的有关计算过程的事实、工作的应用领域,以及所有经验。

构建知识组合:

  1. 定期学习新知识。示例,每年学习一门新语言、每月读一本技术书、读非技术书、上课、加入本地用户组/交流群、尝试不同编程环境、与时俱进\
  2. 拓宽知识边界。别人的每次提问都是一个学习的机会。\
  3. 不要学习即将淘汰的技术\
  4. 在新技术流行以前开始学习\
  5. 评估哪些技术在未来前景更好

批判性思维:不要让自己的大脑成为别人思想的跑马场。

几个和批判性思维相关的问题:

  1. 问“五个为什么”\
  2. 谁从中收益\
  3. 这件事发生的背景是什么\
  4. 什么时候在哪里可以工作起来;当它结束后还会发生什么\
  5. 为什么是这个问题

交流很重要。作为开发人员,必须在多个层次上进行交流:

  1. 开会与老板同事交流\
  2. 和最终用户交流,理解他们的需求\
  3. 编写代码与机器交流\
  4. 编写文档,与下一个阅读文档的开发者交流\
  5. 写建议和备忘录,用于资源申请、报告现状以及提出新的解决方案

了解听众,明白自己想说什么,选择时机,根据听众调节表达方式,让它看起来不错,让听众参与进来,做倾听者,回应别人,把代码和文档绑在一起。

网上交流,特别是电子邮件,同样需要注意以上几点,一些建议:

  1. 点击发送按钮前先校对一遍\
  2. 检查一遍拼写,找到有可能是自动纠错没做对的地方\
  3. 用简单的格式\
  4. 尽可能少地引用原文\
  5. 如果要引用别人的邮件,一定要注明出处,而且是内联引用(不是放在附件里)\
  6. 不要在网上侮辱别人\
  7. 在点发送前,检查一下收件人列表