工作法：综合运用

阅读整理自《10x程序员工作法》- 郑晔，详细内容请登录 极客时间 官网购买专栏。

---

快速进入状态

IT 行业快速发展，无数的机会涌现了出来，程序员频繁流动是这个行业的一个典型特征。频繁换工作，无论是对公司，还是对个人都是成本很高的一件事。所以，在加入一个新公司时，怎么让自己快速融入，尽快发挥价值，是摆在我们面前的一个重要问题。

运用思考框架

问三个问题：

• Where are we?（我们现在在哪？）
• Where are we going?（我们要到哪儿去？）
• How can we get there?（我们如何到达那里？）

先来看第一个问题，如果刚刚加入一家公司，哪怕我们不是一脸懵，也只是对公司业务有一个简单地了解，这是我们的现状。

第二个问题来看看我们的目标。一般来说，我们都是打算在新公司大展身手，但这个答案太宽泛了，我们还需要进一步细化。在这个公司长远的发展是以后的事，我们还是把第一步的目标制定成能够达到上手工作的程度，比如，能够解决日常的项目问题。

第三个问题了，怎么才能够达到这个目标呢？我们需要做一个分解。

估计大多数人进到项目里，都是一头奔进代码里，然后，从各种细节研究起来。技术肯定是要了解的，但它不应该是第一位的。

技术解决的是“怎么做”的问题，而我们第一个应该了解的问题是“做什么”。一个软件到底在做什么，能够回答这个问题的就是业务。所以，我们排在第一优先级的事情应该是业务。

了解业务和技术都只是让你扮演好你个人的角色，但我们通常都是在一个团队内工作的，所以，还要解决好与其他人协作的问题，这就需要我们了解团队本身是如何运作的。

将大目标做了一个分解，得到了三个小目标：业务、技术、团队运作。

业务

业务，入手新项目时最容易忽略的点。

如果你了解了业务，你自己就可以推演出基本的代码结构。但反过来，如果让你看了代码，从中推演出业务，那几乎是不可能的。

每次了解到一个业务，我都会在脑子中过一下，如果是我做这个业务，我会怎么做。这样一来，我就会先在整体上有一个预判，后面再对应到实际的代码上，就不会那么陌生了。

要了解业务，我一般都会请人给我讲一下，这个业务是做什么的，解决什么样的问题，具体的业务流程是什么样子的，等等。

在初期的了解中，我并不会试图弄懂所有的细节，因为我的目标只是建立起一个基本的框架，有了这个初步的了解，后续再有问题，我就知道该从哪里问起了。

理论上，了解业务是每个程序员都该做的事，但事实上，这也常常是出问题的地方。在请别人给我讲解业务的过程中，我发现，很多人是分不清业务和技术的，经常把二者混在一起讲。如果你跟着他的思路走，很容易就会陷入到对细节的讨论中。

了解业务时，一定要告诉自己，这个阶段，我要了解的只是业务，千万别给我讲技术。

技术

先从宏观内容开始。第一个问题就是这个系统的技术栈，这样，我就可以对用到的工具和框架有个大致的预期。

接下来是系统的业务架构，这个系统包含了哪些模块，与哪些外部系统有交互等等。最好能够有一张或几张图将架构展现出来。现实情况是，不少项目并没有现成的图，那就大家一起讨论，在白板上一起画一张出来，之后再来慢慢整理。

技术，对应着我需要了解分层。

了解一个模块内部分了多少个层，每个层的职责是什么。了解了这些对系统的设计，也就对系统有了一个整体的认识。

设计之后，就到了动手的环节，但还不到写代码的时候。我会先从构建脚本开始，了解项目的常用命令。我预期从版本控制里得到的是一个可以构建成功的脚本，如果不是这样，我就知道哪里需要改进了。

最后才是代码，比如，代码的目录结构、配置文件的位置、模块在源码上的体现等等。作为初步的接触，了解基本的东西就够了，代码是后期会投入大量精力的地方，不用太着急。

团队运作

从外部开始，这个团队有哪些外部接口。

比如，需求是从哪来的，产品最终会由谁使用，团队需要向谁汇报。如果有外部客户，日常沟通是怎么安排的。

内部的活动。

一方面是定期的活动。比如，站会、回顾会议、周会，这些不同活动的时间安排是怎样的；

另一方面是团队的日常活动，比如，是否有每天的代码评审、是否有内部的分享机制等等。

通过了解这些内容，基本上可以大致判断出一个团队的专业程度，也可以知道自己需要帮助的时候，可以找谁帮忙，为自己更好地融入团队打下基础。如果有人很清楚团队现状的话，你可以去请教，也许一天就够了。

小结

大多数程序员习惯的工作方式，往往是从细节入手，很难建立起一个完整的图景，常常是“只见树木不见森林”，而我的方式则是从大到小、由外而内，将要了解的内容层层分解，有了大图景之后，很容易知道自己做的事情到底在整体上处于什么样的位置。

在交流的过程中，学习一点"行话"。这会让人觉得你懂行，让你很快得到信任，尽早融入团队。

另外，了解一个项目，从大图景开始。

---

保持竞争力

在学习区工作和成长。

当有了“一专”，拓展“多能”，就会拥有更宽广的职业道路。

比如，拥有了深厚的技术功底，通晓怎么做软件：

• 如果还能够带着其他人一起做好，就成了技术领导者
• 如果能够分享技术的理解，就有机会成为培训师
• 如果能够在实战中帮助别人解决问题，就可以成为咨询师。

当有了“多能”，也可以拓宽视野，帮认清自己的“一专”怎样更好地发挥价值，而不是狭隘地认为自己有了技术，就已经天下尽在掌握了。视野窄，缺乏大局观，也成为了许多程序员再进一步的阻碍。

只做一个公司的专家，受一个公司的波动影响太大，而成为行业的专家，才会降低自己职业生涯的风险。

所谓的熟悉，只是熟悉别人的思考结果，而后面则是一个没有现成答案的东西。学习微积分是有难度，但同发明微积分相比，难度根本不在一个层次上。当然，不是说要熟悉所有工具的发展过程，而是自己要在一个特定的方面拥有深度的思考。

怎么才能让自己的水平不断提高呢？找一个好问题去解决，解决了一个好的问题能够让你的水平快速得到提升。什么是好问题？就是比你当前能力略高一点的问题，比如：

• 如果还什么都不会，那有一份编程的工作就好
• 如果已经能够写好普通的代码，就应该尝试去编写程序库
• 如果实现一个具体功能都没问题了，那就去做设计，让程序有更好的组织
• 如果已经能完成一个普通的系统设计，那就应该去设计业务量更大的系统。

为什么要选择比自己水平高一点的问题？ “学习区”模型：

• 最内层是舒适区（Comfort Zone），置身其中会让人感觉良好，但也会因为没有挑战，成长甚微，你可以把它理解成做你最熟悉的事情
• 最外层是恐慌区（Panic Zone），这是压力极大的地方，完全超出了你的能力范围，你在其中只会感到无比的焦虑
• 中间的是学习区（Learning Zone），事情有难度，又刚好是你努力一下可以完成的，这才是成长最快的区域。

---

工作中推行新观念

在一个地方看到了一些好东西：技术、实践，或是想法，然后想把它运用在自己的项目中，希望项目越做越好，越来越顺利。

但在实际情况中，想在一个组织内推广一些不一样的东西，都会面临层层阻力。

想做事，只需要一个理由就够了，不想做，理由有一万个。

劝那些不想改变的人改变是异常耗时而且收效甚微。最好的办法是，找到愿意和你一起改变的人，做一件具体的事。

"Talk is cheap. Show me the code. "

讲道理很容易，但也难以让人真正的信服。同样，做事很难，但成果摆在那里，让人不得不信服。

---

网友经验

工作中不要满足当前需求，要经常从自己上级主管甚至老板角度来审视自己的工作，思考业务的终极目标，持续琢磨扩展边界，挑战工作难度。

平时多看书多思考，除了钻研某个领域，还要多有涉猎，拓展领域，成为终身学习者。

适当运动维持健康，你有更多体力和更强抗压能力的时候，就可以超过不少人。

保持竞争力除了上述之外，要保持乐观，相信大多数事都有解决方法，在多数人都容易放弃的时候，你的坚持，就是竞争力。

---

有效工作

插入排序并不会因为干的活多，就比快速排序得到更高的评价，因为它们比的是谁排得快。

工作效率高，不是因为代码写得多，而是有效工作做得多。

有效工作，需要我们把力量聚焦到正确的地方，做本质复杂度（Essential Complexity）的事情，少做无意义的事情。

• 拓展自己的上下文，看到真正的目标，更好地对准靶子，比如，多了解用户，才不至于做错了方向；站在公司的层面上，才知道哪个任务优先级更高；站在行业的角度，而不局限于只在公司内成为高手，等等。
• 去掉不必要的内容，减少浪费，比如，花时间分析需求，不做非必要的功能；花时间做好领域设计，别围着特定技术打转；花时间做好自动化，把精力集中在编码上，等等。

要想有效工作：

• 一方面，意识上要注意自己工作中无效的部分。
• 另一方面，要构建自己关于软件开发的知识体系。有很多最佳实践，在某些方面，有人已经做得很好了，花时间学习积累，比自己从头摸索好很多。

---