Linus 说过，这世界程序员之所以有高下之分，最大的区别就是程序员的“品味”不一样。有品位的程序员和没有品位的程序员，写出来的代码，差距非常大。
为什么这么说呢？举个例子，在一次代码评审中，我注意到了这样一段代码：
public void approve(final long bookId) {...book.setReviewStatus(ReviewStatus.APPROVED);...}
这是在一个服务类里面写的，它的主要逻辑就是从仓库中找出一个作品，然后，将它的状态设置为审核通过，再将它存回去。其中，设置作品评审状态的代码引起了我的注意，于是有了下面这段对话。
我：这个地方为什么要这么写？同事：我要将作品的审核状态设置为审核通过。我：这个我知道，但为什么要在这里写 setter 呢？同事：你的意思是？我：这个审核的状态是作品的一个内部状态，为什么服务需要知道它呢？也就是说，这里通过 setter，将一个类的内部行为暴露了出来，这是一种破坏封装的做法。同事被我说动了，于是这段代码变成了下面这个样子：
public void approve(final long bookId) {...book.approve();...}
之所以我注意到这段代码，完全是因为这里用到了 setter。setter 通常意味着变化，setter 的出现，是对于封装的破坏，把一个类内部的实现细节暴露了出来。
在我看来，setter 就是一个代码的坏味道，其背后隐藏着很多的问题。而所有这些问题，都会让代码在未来的日子变得更加不可维护，这就是软件团队陷入泥潭的开始。
而对个人来说，一个程序员从业余迈向职业的第一步，就是能够把代码写得具有可维护性。
那要怎样编写可维护的代码呢？我建议你从“代码的坏味道”入手。
为什么？想想我们以往学知识，大多都会告诉我们应该怎样做、怎样做是好的，但理解这些内容，需要我们对整洁代码有着深厚的理解，而每个人对同一件事的理解程度是不一样的。
比如说，我们都知道“命名是要有意义的”，但什么样的命名才算是有意义的呢？有的人只理解到不用 xyz 命名，虽然他起出了自认为“有意义”的名字，但这些名字依然很难懂。
如果只知道正面的代码是什么样子，却不知道反面的代码是什么样子，很多问题重重的代码就堂而皇之的留在了眼皮底下，自己都发现不了，这就为未来的开发埋下了无数的隐患。
坏味道是写出好代码的起点。首先你要有对代码坏味道的嗅觉，能够识别出坏味道，接下来，你才有机会去“重构（Refactoring）”，把代码一点点打磨成一个整洁的代码（Clean Code）。
所以，我和极客时间再次合作，推出了这个讲坏味道的专栏《代码之丑》，我总结了一套实用的代码坏味道「自查清单」，25+ 真实代码段反面案例，我会告诉你典型的坏味道是什么，带你分析产生坏味道的本质原因，以及以应对这些坏味道的 25+ 重构手法。
👆扫描上图，免费试读
原价 ¥99，早鸟 + 口令「zhengye66」，
到手价 ¥69，仅限「前 100 人」有效
这里是我整理的一份“坏味道自查表”，把一些明显的“坏味道”信号列了出来，你可以和自己的代码做对比：
我叫郑晔，网名 dreamhead，推文科技技术 VP。一个写代码超过二十年的程序员，做过与软件开发的各种工作：编代码、带团队、做咨询、写开源。我在极客时间已经开设了两个课程《10x 程序员工作法》和《软件设计之美》，曾担任火币网首席架构师、ThoughtWorks 首席咨询师，对代码整洁之道有深入理解，热衷于不断优化代码质量和编码效率。
我是如何讲解代码坏味道的？本课程共分为两个模块：
模块一：13 种典型的坏味道。在这个模块中，我会直接用我们工作中的真实代码作为案例，带你发现潜藏在你的编程中的那些坏味道。除此之外，我还会给你讲支撑这些“坏味道”之所以为“坏味道”的原因。同时，也会提到一些重构的手法，比如，改名（Rename）、提取方法（Extract Method）等等。
模块二：拓展。掌握了什么样的代码是坏味道， 也就有了具体的评判标准。那么，该如何去运用坏味道这把“尺子”呢？这就不得不说一说 Code Review 这件事。在这个模块中，我还邀请了两版《重构》的译者熊节，为你讲解阅读《重构》这本书以及使用重构这门手艺，最关键的问题是什么。另外，我会从专栏的编程练习作业中挑一些典型的作业进行点评，带着你即学即练。
详细内容，可以看看目录：
订阅后生成海报发给好友，每成功邀请 1 位好友，可得 ¥16 返现。
👇扫描下图，免费试读👇
如果你想摆脱平庸的小白状态，成为一个优秀的有“品味”的程序员，先从代码精进开始吧。
