cjh的博客

在上一讲中，结合着“新入职一家公司”的场景，我给你讲了如何在具体情况下应用我们前面学到的知识。这一讲，我们再来选择一个典型的实际工作场景，将所学综合应用起来。这个场景就是面对遗留系统。代码是会随着时间腐化的，无论是有意，还是无意。即便是最理想的场景，代码设计得很好，维护得也很精心，但随着技术的不断升级进步，系统也需要逐步升级换代。比如，我们一直认为电信是一个独特的领域，与 IT 技术是完全独立的，学好 CT（Communication Technology，通信技术）就可以高枕无忧了。但随着 IT 技术的不

在前面两讲，我给你讲了开发过程的自动化，将我们的程序打成发布包；然后讲了部署过程的自动化，通过各种工具将发布包部署起来。有了这些基础，我们就可以考虑在每次开发完之后，将程序打包部署到环境中。开发完就自动打包，然后自动部署，听起来很像持续集成是不是？但持续集成的讨论只停留在开发环节。有了前面两讲的准备，我们就可以把这个过程再进一步延伸。聪明的你或许已经听出来了，这次我要讲的主题是持续交付。持续交付让持续交付这个概念广为人知的是一本书，Jez Humble 和 Dave Farley 的《持续交付》（Conti

在“自动化”模块的最后，我们来聊一个很多人热衷讨论却没做好的实践：微服务。在今天做后端服务似乎有一种倾向，如果你不说自己做的是微服务，出门都不好意思和人打招呼。一有技术大会，各个大厂也纷纷为微服务出来站台，不断和你强调自己公司做微服务带来的各种收益，下面的听众基本上也是热血沸腾，摩拳擦掌，准备用微服务拯救自己的业务。我就亲眼见过这样的例子，几个参加技术大会的人回到公司，跟人不断地说微服务的好，说服了领导，在接下来大的项目改造中启用了微服务。结果呢？一堆人干了几个月，各自独立开发的微服务无法集成。最后是领导站

今天，我们从软件行业的一个段子说起。甲方想要做个电商网站，作为乙方的程序员问：“你要做个什么样的呢？”甲方说：“像淘宝那样就好。”程序员问：“那你打算出多少钱？”甲方想了想，“5万块钱差不多了吧！”这当然是个调侃客户不懂需求的段子，但你有没有想过，为什么在甲方看来并不复杂的系统，你却觉得困难重重呢？因为你们想的根本不是一个东西。在客户看来，我要的不就是一个能买东西的网站吗？只要能上线商品，用户能看到能购买不就好了，5万块钱差不多了。而你脑中想的却是，“淘宝啊，那得是多大的技术挑战啊，每年一到‘双11’，那就

作为程序员，你一定听说过分层，比如，最常见的 Java 服务端应用的三层结构，我曾提到过：数据访问层，按照传统的说法，叫 DAO（Data Access Object，数据访问对象），按照领域驱动开发的术语，称之为 Repository；服务层，提供应用服务；资源层，提供对外访问的资源，采用传统做法就是 Controller。这几乎成为了写 Java 服务的标准模式。但不知道你有没有想过，为什么要分层呢？设计上的分解其实，分层并不是一个特别符合直觉的做法，符合直觉的做法应该是直接写在一起。在编程框架

前面几讲，我给你讲了开发过程的各种自动化，从构建、验证到上线部署，这些内容都是站在软件外部看的。从这一讲开始，我准备带领大家进入到软件内部。今天的话题就从写代码开始说起。逐步腐化的代码代码是程序员改造世界最直接的武器，却也是程序员抱怨最多的东西。为什么程序员会对代码如此不满呢？你会抱怨写一段代码吗？你肯定不会，毕竟这是你养家糊口的本领，最基本的职业素养我们还是有的。那抱怨的是什么呢？是维护一段代码。为什么维护代码那么难？因为通常来说，你维护的这段代码是有一定年龄的，所以，你总会抱怨前人没有好好写这段代码。好

经过前面三讲的讲解，相信你对一个项目自动化应该是什么样子有了一个相对完整的认识：程序员写好程序，用构建脚本执行检查，提交代码，在服务器上打出一个发布镜像，部署到各个环境进行检查，检查好了，随时可以发布上线。我们在前面的内容中只说了该检查，但怎么检查呢？这就轮到测试发挥作用了。在“任务分解”的模块，我给你完整地介绍了一下开发者测试的概念，但在那个部分讲解的测试基本上还停留在单元测试和集成测试的范畴。对于整个应用该怎么测，我们并没有仔细讨论。今天我们就来说说应用测试的话题：验收测试。验收测试验收测试（Accep

经过前面几个模块的学习，我们分别领略了各个原则在不同场景下的应用，相信你对于这些原则的理解也上了一个台阶。但实际工作并不会清晰地告诉你，到底该运用哪个原则来解决问题。所以，在接下来的三讲中，我挑选了程序员职业生涯中三个非常经典的场景，与你一起看看怎么在实际的工作中运用好已经学习到的这些原则。在综合运用这个模块的第一讲，我们就来谈谈，当你加入一家新公司时，应该怎么做。IT 行业快速发展，无数的机会涌现了出来，程序员频繁流动是这个行业的一个典型特征。频繁换工作，无论是对公司，还是对个人都是成本很高的一件事。所以

在前面两讲，我结合着两个程序员要直接面对的场景，讨论了如何综合运用前面学习到的知识，这一讲的内容可能不涉及到实际的应用场景，但与每个人的发展息息相关。我想谈谈如何走好程序员这条路。焦虑的程序员让我们再次用思考框架分析一下问题。首先，现状是什么？关于这个问题，我并不打算讨论个体，因为每个人的情况千差万别，我准备从整体入手。IT 行业是一个快速发展变化的行业，一方面，我们不断地看到有人快速取得成功，另一方面，我们也听到了许多充满焦虑的声音。获得大的成功总是一个小概率事件，大多数人面对的还是日常的柴米油盐。我们的

在上一讲中，我们讲到了开发过程的自动化，我们的关注点在于如何构建出一个有效的部署包，这个包最终是要上线部署的，那接下来，我们就来关心一下部署的相关工作。零散的运维知识在一些稍具规模的公司，为部署工作设置了一个专有职位，称之为运维。当然，这个岗位的职责远不止部署这一件事，还要维护线上系统的稳定。不过，如果你的团队规模不大，或是项目处于初始阶段，这些工作往往也要由程序员自行完成。对于一个程序员来说，了解自己的程序怎么部署上线，是非常重要的。我们既要了解一个软件的逻辑，也要知道它的物理部署。只有这样，出了问题才知

终于进入到程序员看上去最熟悉的一个主题：自动化。每每提及自动化，我就会想起 Perl 语言的发明人 Larry Wall 一个经典叙述：优秀程序员应该有三大美德：懒惰、急躁和傲慢（Laziness, Impatience and hubris）。有人甚至为此专门打造了一个三大美德的网站，阐释这个初看起来匪夷所思的说法。懒惰，是一种品质，它会使你花很大力气去规避过度的精力消耗，敦促你写出节省体力的程序，别人也能很好地利用，你还会为此写出完善的文档，以免别人来问问题。急躁，是计算机偷懒时，你会感到的一种愤

你写文档吗？我知道，你可能并不喜欢写文档，因为在你眼中，写文档是繁琐的，是旧时代软件工程的产物。最开始我对写文档的印象也不好。我的职业生涯是从一个通过了 CMM 5级认证的大企业开始的。可能今天很多程序员已经对 CMM 感到陌生了，它是能力成熟度模型（Capability Maturity Model for Software）的缩写，用来评估一个组织的软件开发能力，曾在国内风靡一时，许多软件公司都以拥有 CMM 认证为努力方向。在这个极其重视过程的企业里，文档是非常重要的一环。但我看到的真实场景却是，一个

今天我准备讨论一个经常会让很多程序员郁闷的事情，为什么你已经工作得很辛苦了，但依然会被指责。在讨论这个问题之前，我们先来讲一个小故事。程序员小李这天接到了一个新的任务。系统要做性能提升，原先所有的订单都要下到数据库里，由于后来有很多订单都撤了，反复操作数据库，对真正成交过程的性能造成了影响。所以，技术负责人老赵决定把订单先放到缓存里。这就会牵扯到一个技术选型的问题，于是，老赵找了几个可以用作缓存的中间件。为了给大家一个交代，老赵决定让小李给这几个中间件做一个测试，给出测试结果，让大家一起评估。小李高兴了，做

在前面的专栏内容中，我们讨论过几次与产品经理的交流：你应该问问产品经理为什么要做这个产品特性，要用 MVP（最小可行产品）的角度，衡量当前做的产品特性是不是一个好的选择。但还有一个问题可能困扰着我们：怎么判断产品经理说的产品特性是不是用户真的需要的呢？很多时候，产品经理让你实现一个产品特性，你感觉这么做好像不太对，却又说不出哪不对，想提出自己的看法，却不知道从哪下手。之所以会遇到这样的问题，一个重要的原因就是，你少了一个维度：用户视角，你需要来自真实世界的反馈。吃自家的狗粮产品经理无论要做什么，他都必须有一

看过《圣斗士星矢》的同学大多会对其中的一个说法印象颇深：圣斗士不会被同样的招数击败两次。我们多希望自己的研发水平也和圣斗士一样强大，可现实却总不遂人愿：同样的线上故障反复出现，类似的 Bug 在不同的地方一再地惹祸，能力强的同学每天就在“灭火”中消耗人生。我们难道就不能稍微有所改善吗？如果在开发过程中，同样的问题反复出现，说明你的团队没有做好复盘。什么是复盘？复盘，原本是一个围棋术语，就是对弈者下完一盘棋之后，重新把对弈过程摆一遍，看看哪些地方下得好，哪些下得不好，哪些地方可以有不同甚至是更好的下法等等。这

做好持续集成，是很多人真正关心的内容。今天，我们就来谈谈如何做好持续集成。既然我们打算讨论持续集成，不妨停下来先思考一个问题：你对持续集成的第一印象是什么。持续集成？Jenkins？没错，很多人对持续集成第一印象都是持续集成服务器，也就是 CI 服务器，当年是 CruiseControl，今天换成了 Jenkins。也正是因为如此，很多人就把 CI 服务器理解成了持续集成。我就曾经接触过这样的团队，他们恨不得把所有的事情都放在 CI 服务器上做：在 CI 服务器上做了编译，跑了代码检查，运行了单元测试，做了

作为一个程序员，在这个技术快速发展的时代，我们唯有不断学习，才能保证自己不为时代所抛弃。那你是怎么跟上技术发展步伐的呢？就个人经验而言，我会关注一些技术网站，最典型的就是 InfoQ。这样，我可以快速了解到技术发展的动向，比如，什么时候出了个新东西、哪个项目又有了重大的更新、某些技术有了哪些新的应用场景等等。另外，我还有一种更系统地了解新知识的方式：ThoughtWorks 技术雷达。之所以我很喜欢这种方式，因为它是“可视化”的。什么是技术雷达？ThoughtWorks 技术雷达是由 ThoughtWork

今天我们来探讨一个很多程序员日常工作中，经常碰到却会带来困扰的话题：开会。头疼的开会有一次，我听到两个程序员在聊天。一个资深程序员说：“还是晚上好，我可以一门心思写代码”，另一个年轻程序员不解地问：“你白天也可以写啊。”资深程序员很无奈，“我倒是这样想，可是白天参加那么多会，哪有工夫啊！我的代码就只能加班写了。”这段对话听上去让人有点心酸，但这种现象，确确实实广泛存在于程序员的日常工作中，尤其是你经验丰富又在一个大组织中工作，这几乎成了你的宿命。在这些程序员的认知中，开会太多影响了他们写代码。你以为我想讨伐

关于“沟通反馈”的话题，我准备从代码开始讲起，毕竟我们程序员是靠代码与机器进行沟通的。写代码是每个程序员的职责，程序员们都知道要把代码写好。但究竟什么叫写好呢？每个人的理解却是各有差异。编写可维护的代码初涉编程的程序员可能觉得能把功能实现出来的代码，就是好代码，这个阶段主要是基本功的学习，需要掌握的是各种算法、数据结构、典型的处理手法、常用的框架等等。经过一段时间工作，日常工作所需的大多数代码，在你看来都是不在话下的。尤其像搜索和问答网站蓬勃发展之后，你甚至不需要像我初入职场时那样，记住很多常见的代码模式，

我们将要开启一个新的模块：沟通反馈。如果看到沟通反馈几个字，你就以为我打算在这里教一些谈话技巧，那你还真的想错了。在这个模块里，我打算与你讨论的主题是，生活在真实世界中。沟通反馈和生活在真实世界这两个话题是怎么联系到一起的呢？请听我慢慢道来。《大富翁》里的沙隆巴斯有句口头禅：人生不如意的事，十有八九！但是不知道你有没有想过这样的一个问题，为什么人生如此不如意？如果这是一篇鸡汤文，我应该告诉你世事艰辛。但我要说的是，真实的原因往往是因为你想得太美好，用我们做软件的例子来看一下：在我们的愿望中，做出来的产品应

前面我们讲了开发任务的分解和需求管理的分解，这些都是针对“已经确定好要做的事情”的分解策略，今天我们再上一个台阶，聊聊面对那些不确定的产品功能该如何分解。产品经理的想法层出不穷，但是，如果我们一味闷着头实现产品经理的想法，无论你有多大的开发团队都是不够用的。我们要学会用最小的代价做产品。谈到产品这个话题，我们的直觉当然是把所有的东西都实现了再去检验，但是世界不会停下来等着我们。事实也一次又一次教育我们，“憋大招”的瀑布式软件开发已经成为不合时宜的“老古董”。那我们的理想怎么实现呢？唯有分解。我们前面提到，精

上一讲我们讲了需求的分解，我以用户故事为例，给你讲了我们应该把大的需求拆分成小的需求，但是不是只要把需求拆开了就万事大吉了呢？显然不是。今天我们再来探讨另一个与需求强相关的话题：需求管理。需求管理？许多程序员的第一直觉通常是，这要么是产品经理的事，要么是项目经理的事，跟我有什么关系？我知道很多人会这么想，可我想说的是，如果你不了解需求是怎么管理的，即便是进行了需求分解，最终的结果很有可能依然是你深陷泥潭苦苦挣扎而不自知。为什么这么说呢？我给你讲一个发生在我身边的故事。最无脑的需求管理法：老板说的有一次，我们

我们前面讲的任务分解，主要是在讲开发任务的分解。今天我们换个角度，看看需求的分解。是的，需求也要分解。有一次，我和一个做开发的同事聊天，他给我讲了他近期的烦恼。同事：我们现在就是需求太多，开发的人太少，再这么干下去，哪天觉得自己抗不住了，我就拍拍屁股走人。我：你没尝试着砍砍需求？同事：怎么没尝试？产品的人都不同意。这批功能他们都说是关键功能。我：你有没有尝试把需求拆开了再砍呢？同事：还可以这样？同事很惊讶，我一点都不意外。我们都是在说需求，但彼此对需求的理解却是大不相同。我先来问个问题，提到需求

关于测试，我们前面讲了很多，比如：开发者应该写测试；要写可测的代码；要想做好 TDD，先要做好任务分解，我还带你进行了实战操作，完整地分解了一个任务。但有一个关于测试的重要话题，我们始终还没聊，那就是测试应该写成什么样。今天我就来说说怎么把测试写好。你或许会说，这很简单啊，前面不都讲过了吗？不就是用测试框架写代码吗？其实，理论上来说，还真应该就是这么简单，但现实情况却往往相反。我看到过很多团队在测试上出现过各种各样的问题，比如：测试不稳定，这次能过，下次过不了；有时候是一个测试要测的东西很简单，测试周边

前面在讨论 TDD 的时候，我们说任务分解是 TDD 的关键。但这依然是一种感性上的认识。今天，我们就来用一个更加具体的例子，让你看看任务分解到底可以做到什么程度。这个例子就是最简单的用户登录。需求很简单，用户通过用户名密码登录。我相信，实现这个功能对大家来说并不困难，估计在我给出这个题目的时候，很多人脑子里已经开始写代码了。今天主要就是为了带着大家体验一下任务分解的过程，看看怎样将一个待实现的需求一步步拆细，变成一个个具体可执行的任务。要完成这个需求，最基本的任务是用户通过输入用户名和密码登录。用户名和密

前面我和大家分享了 TDD 的来龙去脉，那些尚未将 TDD 烂熟于胸的同学会分为两个派别。一派是摩拳擦掌，准备动手实践一番；另一派是早就自我修炼过，但实践之路不通。所以，市面上经常会听到有人说，TDD 不实用。但是 TDD 真的不实用吗？和任何一门技能一样，TDD 也是需要练习的。更重要的是，你需要打通 TDD 的“任督二脉”，而这关键正是我们这个模块的主题：任务分解。而且，在今天的内容中，我还将带你领略大师级程序员的工作风范。让我们开始吧！TDD从何而来？要学最原汁原味的 TDD ，莫过于从源头学起。从前

在上一讲中，我向你说明了为什么程序员应该写测试，今天我准备与你讨论一下程序员应该在什么阶段写测试。或许你会说，写测试不就是先写代码，然后写测试吗？没错，这是一个符合直觉的答案。但是，这个行业里确实有人探索了一些不同的做法。接下来，我们就将进入不那么直觉的部分。既然自动化测试是程序员应该做的事，那是不是可以做得更极致一些，在写代码之前就把测试先写好呢？有人确实这么做了，于是，形成了一种先写测试，后写代码的实践，这个实践的名字是什么呢？它就是测试先行开发（Test First Development）。我知道，

在“任务分解”这个模块，我准备从一个让我真正深刻理解了任务分解的主题开始，这个主题就是“测试”。这是一个让程序员又爱有恨的主题，爱测试，因为它能让项目的质量有保证；恨测试，因为测试不好写。而实际上，很多人之所以写不好测试，主要是因为他不懂任务分解。在上一个模块，我们提到了一些最佳实践，但都是从“以终为始”这个角度进行讲解的。这次，我准备换个讲法，用五讲的篇幅，完整地讲一下“开发者测试”，让你和我一起，重新认识这个你可能忽视的主题。准备好了吗？我们先从让很多人疑惑的话题开始：程序员该写测试吗？谁要做测试？你是

这次我们从一个宏大的话题开始：银河系中存在多少与我们相近的文明。我想在面对这样一个问题时，大多数人也不知道从何入手。我来做一个科普，给大家介绍一下德雷克公式，这是美国天文学家法兰克·德雷克（Frank Drake）于1960年代提出的一个公式，用来推测“可能与我们接触的银河系内外星球高等文明的数量”。下面，我要放出德雷克公式了，看不懂一点都不重要，反正我也不打算讲解其中的细节，我们一起来感受一下。不知道你看了德雷克公式做何感想，但对于科学家们来说，德雷克公式最大的作用在于：它将一个原本毫无头绪的问题分解了，

今天的分享从日常工作开始。请你回想一下，你每天到岗之后做的第一件事是什么呢？然后你来猜猜我的答案是什么？你可能猜不到，我每天到公司之后，第一件正事是看数字。我现在服务于一家做数字资产的公司，我们提供的是一个24小时运行的服务。从加入这家公司的第一天开始，公司的人就给我不断灌输一个重要理念——看数字。在我座位的正前方，摆着一个巨大的显示器，上面展示着各种不断变换的曲线、柱状图和数字，这些数字反映的是各种系统运行的指标。我们就是每天看着这些指标，来发掘一些线上系统问题的，一旦某些指标出现自己不能理解的异常，就要

你好，我是郑晔。经过前面的学习，想必你已经对“以终为始”这个原则有了自己的理解。你知道接到一个任务后，要做的不是立即埋头苦干，而是要学会思考，找出真正的目标。那目标明确之后，我们是不是就可以马上开始执行了呢？先不着急给出你的答案，今天的内容从一个技术任务开始。一个技术任务你现在在一家发展还不错的公司工作。随着业务的不断发展，原来采用的关系型数据库越发无法满足快速的变化。于是，项目负责人派你去做个技术选型，把一部分业务迁移到更合适的存储方式上。经过认真的调研和思考，你给负责人提出了自己的建议，“我们选择 M.

在前面的内容中，我给你介绍了几个体现“以终为始”原则的实践，包括怎样界定工作是否完成的 DoD、怎样判定需求是否完成的验收标准、还有怎样验证产品经理给出的产品特性是否合理的精益创业理念。了解了这些内容，可能你会想：我为什么要关心这些啊？我是程序员啊！难道我不应该安安静静地写程序吗？为什么要操心其他人的工作做得好坏？如果我管了那么多事，我还是不是一个程序员，到底哪里才是我的“终”呢？今天这一讲，我们就来聊聊这个让许多人困惑的问题。因为只有要跳出程序员的角色看问题，工作才会变得更加高效。“独善其身”不是好事在需

前面谈到验收标准时，我们说的实际上是确定性需求，也就是说，我们已经知道了这个需求要怎么做，就差把它做出来了。而有时候，我们面对的需求却是不确定的，比如，产品经理有了一个新想法，那我们该如何应对呢？今天，我们从 IT 行业一个极为经典的话题开始：程序员如何面对产品经理。我先给你讲一件发生在我身边的事。有一次，我们一大群人在一个大会议室里做一个产品设计评审，来自产品团队和技术团队的很多人都参与到这个评审中。一个产品经理正对着自己的设计稿，给大家讲解一个新的产品特性。这个公司准备将自己的服务变成了一个云服务，允许

上一讲我们探讨了需求的“完成”，你现在知道如何去界定一个需求是否算做完了，这要看它是不是能够满足验收标准，如果没有验收标准，就要先制定验收标准。这一点，对于每一个程序员来说都至关重要。在今天这一讲中，我们假设需求的验收标准已经制定清楚，接下来作为一个优秀的程序员，你就要撸起袖子准备开始写代码了。不过在这里，我要问你一个问题：“是不是写完代码，工作就算完成了呢？”你或许会疑惑，难道不是这样吗？那我再问你：“代码是技术团队的交付物吗？”你是不是发现什么不对劲了。没有人需要这堆文本，人们真正需要的是一个可运行的软

我们书接上文，继续讲程序员小李的故事。这次小李接到一个新的需求，让他开发一个单点登录的服务，经过几天的奋战，他顺利地写完了所有的代码。正好产品经理小王路过他身边，顺便问了他一下。小王：单点登录做得咋样了？小李：做完了，我给你演示一下。小李演示了一遍自己做的功能，小王看上去很满意。小王：不错。不过，怎么没有支持验证码？小李：为什么要做这个？小王：这不就是登录的一部分吗？小李：哪里规定要做验证码了？小王：现在做登录哪有不用验证码的？我想你已经嗅到了双方谈话的火药味，这个时候如果双方都不能很好地

你好，我是郑晔。在开始今天的讨论之前，我们先来看一个小故事。小李是一个程序员，有一天，项目经理老张来到他身边，和他商量一个功能特性的进度：老张：这有一个任务需要完成，你看一下。小李：这个不难，两天就能做完，两天以后就能上线。两天以后，老张又来到小李的身边验收工作：老张：怎么样，做完了吗？今天能上线吗？小李：我的代码写完了。老张：测试人员测过了吗？小李：还没有。老张：那今天能测完吗？小李：那我就不知道了。老张：什么？我可是答应了业务的人，今天一定要上线的！很明显，老张有些愤怒，而小李也.

本章内容的开始，我希望你可以先来思考一个问题：如果让你设计一个登录功能，你会怎么做？我曾在公司内部做过这样一个练习，我扮演客户，让大家帮我设计一个登录功能。同事们一听就高兴了，登录不就是用户名加密码嘛，我熟啊，我还可以设计出验证码、找回密码、第三方登录等等功能。更有个别动作快的同事，甚至已经开始设计数据库表，考虑用Redis做缓存了。整个过程下来，大家彼此讨论得热火朝天，唯一没人理会的就是我这个“客户”。讨论结束，扮演客户的我告诉大家，作为一个“土豪”，我打算做一个打车软件，用户可以通过手机号接收验证码的方

程序员在工作中遇到的很多问题，大多不是程序问题，辛苦而低效的工作，多数是由偶然复杂度导致的。那这个由于偶然复杂度造成的差距会有多大呢？1975年，弗雷德里克·布鲁克斯（Frederick Brooks）出版了软件行业的名著《人月神话》，他给出了一个统计结果，优秀程序员的开发效率是普通程序员的10倍。40多年过去了，这个数字得到了行业的普遍认同。成为10x程序员是很多程序员的追求。但工作产出并不只是由写代码的效率决定的，一些不恰当工作方法很大程度上影响着你的产出。在接下来的这段时间里，我希望通过这个专栏和你一