2020毕业季已到，一大批新人程序员正在进入职场。

职场不像学校，有人在这里获得了成功，也有人工作了很多年依旧默默无闻，甚至被埋没。从校园到职场的环境转变，从大学生到程序员的身份转变，你准备好了吗？面对这份职业，究竟应如何开始？

博文菌又重新认真翻阅了《程序员修炼之道：通向务实的最高境界（第2版）》一书，并中摘出了18条建言作为毕业寄语送给刚刚走上职场的你。

希望书中前辈的思想能带给你启迪，帮助你迅速完成身份转换，建立起正确的原则，为你的职业成长道路开个好头。

本书是一本畅销了 20 年的书

其中很多道理都是编程的底层原则

虽然它不是一本技术书

但可以让你的技术发挥更大的作用

如果想更深的感悟理解某条建言

你可以根据提示数字（如 提示3）

在书中找到对应的详细讲解

▼

1

提示3 你有权选择

你的工作环境很糟糕？你的工作很无聊？尝试纠正它。不过，不要一直试下去。正如软件开发教父Martin Fowler 说的，“你可以去改变组织，或是让自己换一个组织。”

如果你的技术过时了，安排时间（你自己的时间）学习一些看起来有趣的新东西。这是一种自我投资，只有为此而加班才是合理的。

想远程工作？要求过了吗？如果他们说不行，就去找个说行的人。

这个行业给了你一系列非凡的机遇。积极主动点，掌控这些机遇。

2

提示4 提供选择，别找借口

如果你打算跟别人解释为什么做不完、为什么延期、为什么搞砸了，在此之前先等等，听一下自己的内心。讲给你显示器上的橡皮鸭听听，或是先对着猫说一遍。你的那些借口听起来合理吗？还是很愚蠢？你的老板听到会怎样？

把谈话在心里过一遍。其他人可能说什么？他们会问，“你试过这样做吗……”“为什么你不考虑一下那样做？”而你怎么回答？在你跑去告诉他们坏消息前，还有什么你可以再试试的？有时，你已经能知道他们会说什么，那么就直接帮他们搞定。

给出选择，而不是找借口。不要说搞不定；解释一下要做些什么才能挽救这个局面。打算敷衍搪塞前，试着驱走这些念头。如果实在做不到，那么就先和你的猫通个气。毕竟你想让这只可怜的小猫背锅……

3

提示 8 将质量要求视为需求问题

令人惊讶的是，许多用户宁愿今天就用上一个毛糙的软件，也不愿意多等上一年再用那个打磨光亮、功能齐备的版本（而且，实际上他们一年后真正需要的东西可能完全不同）。许多预算紧张的IT部门会同意这样的说法。今天就还不错的软件通常比构想中的明天那个完美的软件更讨人喜欢。如果你早点给用户一点东西玩，他们的反馈常常能引领你做出更好的最终方案。

4

提示10 批判性地分析你读到和听到的东西

永远不要低估商业主义的力量。网络搜索引擎有时仅仅是把热门的东西列在最前面而已，并不能说明这是你的最佳选择，而且内容提供商也可以花钱把它们的东西排到前列。书店有时仅仅是把一本书摆在显著的位置而已，并不能说明这是一本好书，甚至不能说明这本书很流行，可能只是有人花钱把它摆在了那里。

5

提示16 让复用变得更容易

你要努力的方向，应该是孕育出一个更容易找到和复用已有事物的环境，而不是自己

重新编写。如果复用不容易，人们就不会这么做。如果你未能复用，就有重复知识的风险。

6

提示29 去解决问题，而不是责备

Bug 是你的错还是别人的错并不重要。无论是谁的错，问题仍然要你来面对。

7

提示30 不要恐慌

人们很容易陷入恐慌，尤其是当最后期限逼近，或是老板或客户站在背后紧张凝视之下拼命找出问题原因时。然而，这时非常重要的是要退后一步冷静思考。对于那些你觉得是Bug 引起的症状，认真想想，到底是什么会导致这个样子。

如果你在看到 Bug 或 Bug 报告时的第一反应是“这不可能”，那你就大错特错了。不要在“但那不可能发生”的思路上浪费哪怕一个神经元，因为很明显它会发生，而且已经发生了。

调试时要注意不要短视。不要仅仅去纠正你所看到的症状：更有可能的是，实际的错误可能与你所观察到的尚有几步之遥，并且可能涉及到许多其他相关的事情。永远要去发掘问题的根本原因，而不仅仅停留在问题的表面现象。

8

提示 31 修代码前先让代码在测试中失败

这是调试最重要的原则。有时，只要强制自己对暴露 Bug 的环境进行隔离，就能获得对如何修 Bug 的洞察力。写测试这个动作，就会揭示出解决方案。

9

提示 43 避免占卜

很多时候，明天看起来会和今天差不多。但不要指望一定会这样。

10

提示 65 尽早重构，经常重构

随着时间的推移，代码中的附带损害有可能致命。重构，和大多数事情一样，在问题很小的时候做起来更容易，要把它当作编码日常活动。你并不需要“用一周时间去重构”一块代码——那是在全面重写。即使重写这种程度的破坏性工作是必要的，也很可能无法立即完成。你要做的是，确保这个过程已被安排在日程表上，确保受影响代码的用户知道重写的计划，以及这么做会对他们有何影响。

11

提示 66 测试和找Bug无关

我们相信，测试获得的主要好处发生在你考虑测试及编写测试的时候，而不是在运行测试的时候。

12

提示 70 要对软件做测试，否则只能留给用户去做

毫无疑问，测试是编程的一部分，不该留给其他部门的人去做。测试、设计、编码——都是在编程。

13

提示 75 无人确切知道自己想要什么

需求很少停留在表面。通常情况下，它们被埋在层层的假设、误解和政治之下。更糟糕的是，需求通常根本不存在。

14

提示 76 程序员帮助人们理解他们想要什么

新手开发人员经常犯的错误是，把这种对需求的声明照单全收，然后实现对应方案。

根据我们的经验，最初对需求的声明，往往并非绝对化的要求。客户可能没有意识到这一点，但一定希望你能一起去探索。

15

提示 81 不要跳出框框思考——找到框框

问题不在于你是在框框里思考还是在框框外思考。问题在于找到框框——识别真正的约束条件。

当面对一个棘手的问题时，把你面前所有可能的解决途径都列举出来。不要忽略任何东西，无论听起来多么无用或愚蠢。现在遍历列出的清单并逐条解释为什么不能选择这条路。你确定吗？你能证明吗？

16

提示 83 敏捷不是个名词，敏捷有关你如何做事

敏捷是一个形容词：它指向你做事情的方式。你可以成为一名敏捷的开发人员。你可以加入一个采用敏捷实践的团队，一个对变化和挫折做出敏捷反应的团队。敏捷指你的风格，并不指你这个人。

17

提示 88 在用户需要时交付

如果交付周期是几年，试着把周期缩短到几个月。如果是几个月，就减少到几周。如果是一个四周的冲刺，那么试一下两周。如果是两周的冲刺，试试一周。然后到每天。最后是即期交付。请注意，能够即期交付并不意味着你必须每天每分钟都交付。只有当这样做在业务上有意义时，才有必要在用户需要时即期交付。

18

提示 94 每个Bug 只找一次

如果有某个Bug 成了现有测试的漏网之鱼，那么就需要添加一个新测试，以保证下一次能将其捕获。

一个Bug 一旦被人类测试员发现，这就应该是它被该人类测试员发现的最后一次。要立即修改自动化测试，以便这个特定的Bug，从此往后每次都被检查到——不能有任何例外，无论它多么琐碎，也无论开发者有多抱怨，或是不停唠叨“哦，永远不会再发生了”。

因为还会再发生的。我们只是没有时间追着Bug 跑，明明可以让自动化测试帮忙将其找出来。我们的时间必须用于编写新的代码——以及新的Bug。

★ 关 于 本 书 ★

▊《程序员修炼之道：通向务实的最高境界（第2版）》

【美】David Thomas，Andrew Hunt 著

云风 译

• 屹立 20 年影响力大作

• 雄踞 “全球程序员读物”顶端

• 面向未来重写全部内容，开发新兵走向卓越领袖

《程序员修炼之道》之所以在全球范围内广泛传播，被一代代开发者奉为圭臬，盖因它可以创造出真正的价值：或编写出更好的软件，或探究出编程的本质，而所有收获均不依赖于特定语言、框架和方法。时隔20年的新版，经过全面的重新选材、组织和编写，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的最佳实践及重大陷阱，以及易于改造、复用的架构技术。本书极具洞察力与趣味性，适合从初学者到架构师的各阶层读者潜心研读或增广见闻。

▼扫码获取本书详情▼

4周精读《程序员修炼之道》报名开启啦

在这里，可以分享自己的学习笔记，了解他人的阅读感悟。与广大读者相互交流、相互促进，掌握本书精髓，共同从开发新兵走向卓越领袖！活动期间还可获取丰厚福利！

7月10日正式开始，第一周任务已发布，扫码进入下方小程序，即刻上车！

博文菌●互动时间

关于毕业

你有哪些难忘的回忆呢？

快来留言去和大家分享吧