10x程序员工作法

程序员解决的问题，大多不是程序问题

程序员是如何思考的？

优秀程序员的开发效率是普通程序员的 10 倍

思考框架

• 我现在什么水平？
• 我想达到什么水平？
• 我怎么达到这个目标？

四项原则

• 以始为终
• 任务分解
• 沟通反馈
• 自动化

以终为始

一种反直觉的思维方式，大多数人不具备

倒逼思想

DoD的价值：你完成了工作，为什么他们还不满意？

在做任何事之前，先定义完成的标准。

Definition of done

接到需求任务，你要先做哪件事？

在做任何需求或任务之前，先定好验收标准。

精益创业：产品经理不靠谱，你该怎么办？

《精益创业》

默认所有需求都不做，直到弄清楚为什么要做这件事。

产品经理——别人有的我们都要有

必杀技——这是老板的需求

好啊，我们一起到老板那里去，看看老板的需求是不是你给我解释得那么不明就里。

持续集成

尽早提交代码去集成。

解决了很多技术问题，为什么你依然在“坑”里？

• 独善其身不是好事
• 扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。

在动手做一件事之前，先推演一番

问一下自己，我的工作是不是可以用数字衡量

如何管理你的上级？

• 管理上级预期

  • 把问题暴露给上级

• 帮助上级丰富知识

• 说出你的想法

抄可以，问题是无脑抄

多写单元测试

测试驱动开发（Test Driven Development）

TDD

在很多人看来，TDD 就是先写测试后写代码。在此我必须澄清一下，这个理解是错的。先写测试，后写代码的实践指的是测试先行开发，而非测试驱动开发。

• "红-绿-重构"

• 红：写了一个新的测试，测试没通过
• 绿：写了功能代码，测试通过
• 重构：完成基本功能调整代码
• 写代码前想想怎么测，我们应该编写可测的代码

《测试驱动开发》

砍需求

用户故事：INVEST原则

• Independent，一个用户故事应该完成一个独立的功能

• Negotiable，可协商的。

• Valuable

• Estimatable

• Small，步子大了，不行。不能在一定时间内完成的用户故事只应该有一个结果，拆

  分。小的用户故事才方便调度，才好安排工作

• Testable

想要管理好需求，先把需求拆小。

当员工想不明白的事，换成老板的视角就全明白了。

尽量做最重要的事

任务分解不了怎么办？

答案很简单，先把它变成你熟悉的技术。

微习惯

将任务拆小，越小越好。

一段旅程（A-TRIP ）

• Automatic，自动化；
• Thorough，全面的；
• Repeatable，可重复的；
• Independent，独立的；
• Professional，专业的。

要想写好测试，就要写简单的测试。

按照完整实现一个需求的顺序去安排分解出来的任务。

沟通反馈

这几乎是很多程序员讲东西的通病：讲东西直奔细节。

通过沟通反馈，不断升级自己的编解码能力。

多面对面沟通，少开会

可视化

做好持续集成的关键在于，快速反馈

• 开发出现问题怎么办？

  • why
  • 定期复盘，找准问题根因，不断改善。

聆听用户声音

并不是所有的技术问题，都是值得解决的技术难题，遇到问题，最好的解决方案是尽早把问题暴露出来。

克服心理障碍

对我们来说，在程序中尽早暴露问题是很容易接受的。但在工作中暴露自己的问题，却是很大的挑战，因为这里还面临着一个心理问题：会不会让别人觉得自己不行。

说实话，这种担心是多余的。因为每个人的能力是强是弱，大家看得清清楚楚。只有你能把问题解决了大家才会高看你，而把问题遮盖住，并不能改善你在别人心目中的形象。

程序员通常都有这种缺点：遇到自己不会的技术后，碍于面子，打心眼里不愿意求助别人，更不想把这种状态让领导知道，因为自认为这是一种低能的表现，导致最后被动的被别人发现。提早的主动暴露问题，确实能规避很多问题，让项目朝良性发展方向，但是这是有前提的，除非你的老板是个开明的人，否则你主动暴露问题，不开明的老板就认为你能力欠缺，最终的绩效评估受伤的还是你自己啊……

糊涂的老板还伺候啥劲

结构化：写文档也是一种学习方式

持续集成的价值在于，它是一条主线，可以将诸多实践贯穿起来

国内程序员真正落后的不是信息，而是观念。

书籍

《代码整洁之道》

用业务的语言写代码。

自动化

懒惰应该是所有程序员的骄傲

• 懒惰，是一种品质，它会使你花很大力气去规避过度的精力消耗，敦促你写出节省体力的程序，别人也能很好地利用，你还会为此写出完善的文档，以免别人来问问题。
• 急躁，是计算机偷懒时，你会感到的一种愤怒。它会促使你写出超越预期的程序，而不只是响应需求。
• 傲慢，极度自信，写出（或维护）别人挑不出毛病的程序。

小心 NIH 综合症

NIH 综合症（Not Invented Here Syndrome）。

NIH 是什么意思？就是有人特别看不上别人做的东西，非要自己做出一套来，原因只是因为那个东西不是我做的，可能存在各种问题。

我们学习自动化，先要知道哪些东西不要自动化，尽最大的努力不做浪费时间的事。一方面，我们要从需求上规避那些没必要做的事；另一方面，我们也从自身防止 NIH 综合症（Not Invented Here Syndrome），争取做一个懒惰的程序员。

对于要自动化的事，我们需要反思一下，在为别人打造自动化工具的同时，我们自己的工作过程有没有很好地自动化。而如果我们想拥有打造良好的自动化工具，我们需要对软件设计有着充分地理解。

请谨慎地将工作自动化

持续交付：有持续集成就够了吗？

《持续交付》：Continuous Delivery

为什么总有人觉得5万块钱可以做一个淘宝？

在客户看来，我要的不就是一个能买东西的网站吗？只要能上线商品，用户能看到能购买不就好了，5 万块钱差不多了。

而你脑中想的却是，“淘宝啊，那得是多大的技术挑战啊，每年一到‘双 11’，那就得考虑各种并发抢购。淘宝得有多少程序员，5 万块你就想做一个，门都没有。

《淘宝技术这十年》

你真的了解重构吗？

《重构》

领域驱动设计（Domain Driven Design，DDD）是 Eric Evans 提出的从系统分析到软件 建模的一套方法论。它要解决什么问题呢？就是将业务概念和业务规则转换成软件系统中概 念和规则，从而降低或隐藏业务复杂性，使系统具有更好的扩展性，以应对复杂多变的现实 业务问题。

比如，我们一直认为电信是一个独特的领域，与 IT 技术是完全独立的，学好CT（Communication Technology，通信技术）就可以高枕无忧了。但随着 IT 技术的不断发展，今天的电信领域也开始打破壁垒，拥抱 IT 技术，提出了 ICT 的概念（Information and Communications Technology，信息通信技术）。

总之，改造遗留系统，一个关键点就是，不要回到老路上。小步改造遗留系统，不要回到老路上。

保持竞争力

• T型人

在学习区工作和成长

为什么程序员都愿意到大厂工作？因为那里有高水平的人和好的问题。但如果只是到大厂去做低水平的事，那就是浪费时间了。所以，即便你真的想到大厂工作，与谁一起工作，做什么事，远比进入大厂本身要重要得多。

先做好DDD再谈微服务吧，那只是一种部署形式

总是在说MVC分层架构，但你真的理解分层吗？

• 数据访问层，按照传统的说法，叫 DAO（Data Access Object，数据访问对象），按照领域驱动开发的术语，称之为 Repository；
• 服务层，提供应用服务；
• 资源层，提供对外访问的资源，采用传统做法就是 Controller。

为什么要分层呢？

原因很简单，当代码复杂到一定程度，人们维护代码的难度就急剧上升。一旦出现任何问题，在所有一切都混在一起的代码中定位问题，本质上就是一个“大海捞针”的活。

你的领域层只依赖于你的领域对象，第三方发过来的内容先做一次转换，转换成你的领域对象。这种做法称为防腐层。

构建好你的领域模型。

代码混乱

把函数写短。

BDD

让验收测试从各自为战的混乱中逐渐有了体系的是行为驱动开发（Behavior Driven Development）这个概念的诞生，也就是很多人知道的 BDD。

如果你想做 BDD，就应该用业务语言进行描述。

重点复习

持续交付

将生产部署纳入了开发的考量。

持续交付的基础设施通常包含持续集成环境、测试环境、预生产环境和生产环境。

构建流水线保证到了下游的交付物一定是通过上游验证的。

随着 Docker 的诞生，交付由发布包变成了 Docker 镜像。

DevOps

将开发和运维结合到一起。

环境配置工具上的进步，让基础设施即代码成了行业共识。

验收测试

验收测试要站在业务的角度编写。

BDD 是一种编写验收测试的方式。

Given…When…Then… 的描述给了一个描述业务的统一方式。

写好验收测试，需要构建测试模型。

SOLID 原则

设计模式背后的道理。

单一职责原则（Single responsibility principle，SRP）。

开放封闭原则（Open–closed principle，OCP）。

Liskov 替换原则（Liskov substitution principle，LSP）。

接口隔离原则（Interface segregation principle，ISP）。

依赖倒置原则（Dependency inversion principle，DIP）。

用好单一职责原则，前提条件是看待问题颗粒度要小。

DDD

它将思考的起点拉到了业务上。

DDD 分为战略设计和战术设计。

微服务

做好微服务的前提是划分好限界上下文。

微服务的第一步，不要划分微服务。在这个模块中，我们还了解了一些重要的思路，让我们把工作做得更好。

程序员的三大美德：懒惰、急躁和傲慢（Laziness, Impatience and hubris）。

小心 NIH 综合症（Not Invented Here Syndrome）。

写好构建脚本，做好项目自动化。

参照 Java 知识体系，学习运维知识。

软件设计最基础的原则是“高内聚、低耦合”。

分层架构是一种设计上的分解。

不同业务量的系统本质上不是一个系统。

采用简单技术解决问题，直到问题变复杂。

书籍推荐

代码实践

如果你想详细学习如何写好代码，我推荐你去读 Robert Martin 的《代码整洁之道》（Clean Code），这本书几乎覆盖了如何把代码写好的方方面面。《实现模式》是一本关于如何写好代码的书，更具体一点是，编写别人能够理解的代码。它的作者 Kent Beck 是许多软件开发实践的开创者。但 Kent Beck 的写作能力一般，他的很多作品被埋没了。只有细细品味，才能体会到 Kent Beck 深厚的功力。

《程序设计实践》（The Practice of Programming）这本书开始的，这本书的作者是 Brian Kernighan 和 Rob Pike，这两个人都出身于大名鼎鼎的贝尔实验室，参与过 Unix 的开发。

如果你想从日常开发中提升自己的效率，可以读一下《卓有成效的程序员》。假如你不曾思考过这个问题，这本书会让看到一些不同的工作方式，我也给这本书写过一篇书评。不过，这本书里的技巧太具体了，所以，有一些已经有些过时了。

设计

SOLID 原则是一种面向对象软件设计原则。早在 1995 年，Robert Martin 就提出了这些设计原则的雏形，然后在他的《敏捷软件开发：原则、实践与模式》这本书中，比较完整地阐述了这五个原则，后来，他有把这些原则进一步整理，成了今天的 “SOLID”。

有了设计原则做基础，这本书后面讲了设计模式，理解起来就容易多了。虽然书名是关于敏捷的，但这是一本讲设计的书。

设计和架构有什么区别？2017 年，Robert Martin 出版了《架构整洁之道》（CleanArchitecture），他在其中告诉我们，二者没有区别。所以，这也是一本关于设计的书，给出了 Robert Martin 对设计的最新理解。你可以把它看成《敏捷软件开发：原则、实践与模式》的修订版。

《设计模式》不推荐阅读，它是设计模式的开山之作，但它的起点是 Erich Gamma 的博士论文，其写作风格偏向学术，而且中文版翻译得也很一般。这里将它罗列出来只是因为其历史重要性。如果你想学习设计模式，现在有一些更容易入门的书，比如《Head First设计模式》。

Martin Fowler 的《企业应用架构模式》将软件开发当时常见的解决方案汇集成模式，今天看来很多模式已经习以为常，但当年出场可是技惊四座的。从这本书的名字你不难看出，它出版的年代是企业级开发盛行的年代。Martin Fowler 一直认为这本书没有写完，希望能够继续更新，但不知道何时能看到这本书的新版。《Unix 编程艺术》也是一本讲软件设计的书，只不过，它选择的切入点是 Unix 中的设计，从中你可以学到“只做一件事，把它做好”、“文本化”等编程理念，有助于你改善日常的工作。这样的书，也就只有 Eric Raymond 这样沉浸编程几十年的人才能写出来。

工程实践

Kent Beck 有一本知名的软件工程之作《解析极限编程》（Extreme ProgrammingExplained），它介绍了一种软件开发方法：极限编程。但更重要的是，今天很多主流的软件开发最佳实践都是从这里出来的。这本书可以理解成诸多最佳工程实践的总纲。

Martin Fowler 在 1999 年写下软件行业的名著《重构：改善既有代码的设计》（Refactoring: mproving the Design of Existing Code），把重构这个小圈子实践带到了大众视野。2018 年底，Martin Fowler 时隔近 20 年后，又写出了《重构》第二版。把他对这些年行业发展的新理解融入到重构实践中。重构应该有个目标，这个目标就是“重构成模式”，而这也是一本专门的书：《重构与模式》（Refactoring to

Patterns）。

《测试驱动开发》是 Kent Beck 为世人展示 TDD 做法的一本书。它好的地方需要自己体会，Kent Beck 并没有显式的讲出来，比如：任务分解。Jez Humble 和 Dave Farley 的《持续交付》（Continuous Delivery）让持续集成再进

一步，将生产环境纳入了考量。乔梁，他是《持续交付》这本书的中文版译者，而且在这本书出版近十年后，他自己写了《持续交付 2.0》，把自己多年来关于持续交付的新理解整理了进去。

说到遗留代码和测试，我推荐一本经典的书：Michael Feathers 的《修改代码的艺术》（Working Effectively with Legacy Code），从它的英文名中，你就不难发现，它就是一本关于遗留代码的书。如果你打算处理遗留代码，也建议你读读这本书。

领域驱动设计

Eric Evans 2003 年写了《领域驱动设计》，向行业介绍一下 DDD 这套方法论，立即在行业中引起广泛的关注。但实话说，Eric 在知识传播上的能力着实一般，这本关于 DDD的开山之作，其写作质量却难以恭维，想要通过它去学好 DDD，是非常困难的。所以，在国外的技术社区中，有很多人是通过各种交流讨论逐渐认识到 DDD 的价值所在，而在国内 ，DDD 几乎没怎么掀起波澜。

2013 年，在 Eric Evans 出版《领域驱动设计》十年之后，DDD 已经不再是当年吴下阿蒙，有了自己一套比较完整的体系。Vaughn Vernon 将十年的精华重新整理，写了一本《实现领域驱动设计》，普通技术人员终于有机会看明白 DDD 到底好在哪里了。所以，你会发现，最近几年，国内的技术社区开始出现了大量关于 DDD 的讨论。因为《实现领域驱动设计》实在太厚，Vaughn Vernon 又出手写了一本精华本《领域驱动设计精粹》，让人可以快速上手 DDD，这本书也是我向其他人推荐学习 DDD 的首选。

产品与需求

精益创业是 Eric Ries 最早总结出来的。他在很多地方分享他的理念，不断提炼，最终在2011 年写成一本同名的书：《精益创业》。如果说精益创业是理论，《精益创业实战》这本书则给了你一个操作流程。

Mike Cohn 是敏捷理念的一个重要传播者，我们在讲测试金字塔时，提到了他的著作《Scrum 敏捷软件开发》（Succeeding with Agile）。敏捷开发有两大流派：一派是工程实践，另一派是管理实践。如果你对 Scrum 这类管理实践感兴趣，可以读一下这本书。

如果你对用户故事这个话题感兴趣，推荐阅读 Mike Cohn 的两本书《用户故事与敏捷方法》（User Stories Applied）和《敏捷软件开发实践 估算与计划》（Agile Estimatingand Planning）。

开发文化

软件行业里有一本名著叫《人月神话》，这算是软件开发领域第一本反思之作。今天，我们讨论的很多词汇都出自这本书，比如，没有银弹、焦油坑等等。虽然这本书出版于1975 年，但其中提到的问题，依然困扰着今天的程序员。

开源概念的提出者 Eric Raymond，他的《大教堂与集市》推开了开源大门。今天开源软件已经成为程序员日常工作的一部分，但如果没有 Eric Raymond 这些人的努力，我们还必须与复杂的企业级软件搏斗。了解一下开源的历程，可以帮助你更好地理解今天的幸福。

程序员应该如何做，Robert Martin 也写了一本书《程序员的职业素养》（Clean Coder），其中对大多数程序员最重要的一点建议是，说“不”。

软件开发拾遗

高德纳的《计算机程序设计艺术》肯定是一套程序员都知道，但没几个人读完的书。算法的讲解经过几十年已经有了很好的发展，如果学算法，肯定有更好的选择。如果你想看图灵奖获得者如何从根上思考问题，不妨找来这套书来翻翻。

《快速软件开发》（Rapid Development），不推荐阅读。在这本书中，作者首次提出了解决集成问题的优秀实践：Daily Build，每日构建。通过这个名字，我们便不难看出它的集成策略，即每天集成一次。它其中很多实践在当时是先进的，但今天看来有些落伍了。如果你只想从中收获一些理念性的东西，可以去读读。

《C 程序设计语言》、《Unix 编程环境》等出自贝尔实验室大师级程序员之手，他们的书都值得一读，其中的内容今天看来可能有些过时，但他们解决问题的方式和手法却值得慢慢品味。

我在讲淘宝技术变迁时，提到了《淘宝技术这十年》，这本书算不上经典，但可以当做休闲读物。

技术之外

管理大师彼得·德鲁克有一本经典著作《卓有成效的管理者》，虽然标题上带着管理者几个字，但在我看来，这是一本告诉我们如何工作的书，每个人都可以读一下。尤瓦尔·赫拉利的《人类简史》或《未来简史》，是我第一次学到“大历史观”这个说法，历史不再是一个个单独的历史事件，而是一个有内在逻辑的发展脉络。《从一到无穷大》是一本著名科普著作，它向我们介绍了 20 世纪以来的科学进展。作者乔治·伽莫夫既是热宇宙大爆炸模型的提出者，也是生物学上最早提出“遗传密码”模型的人。虽然这本书出版自 1947 年，但以现在社会的整体科学素养，还是有必要读读这本书的。

史蒂芬·柯维（Stephen Richards Covey）的《高效能人士的七个习惯》，一个是讲以终为始时，那段关于智力创造的论述，另一个是讲优先级时提到的艾森豪威尔矩阵。这本书值得每个人阅读，很多程序员欠缺的就是这些观念性的东西。

很多程序员都是科幻小说迷，编程和科幻，这两个都是需要想象力的领域。刘慈欣的《三 体》，不说它给 IT 行业带来的丰富的词汇表吧，作为科幻小说来说，它就是一流的，值得阅读。它会让你仰望星空，打开思维。如果你对科幻小说有兴趣，推荐阅读阿西莫夫的《银河帝国》系列，这是科幻小说界的扛鼎之作，你会看到，一部出版于 1942 年的书里就有大数据的身影。

对于程序员来说，最好的工作状态就是进入心流，它会让你忘我工作。如果你对心流的概念感兴趣，可以去读米哈里·契克森米哈赖的著作《心流》，这位作者就是心流概念的提出者。

少做事，才能更有效地工作

《奇思妙想》

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