代码可维护性差？给你套实用的“代码坏味道”自查清单 ｜ 极客时间

Linus 说过，这世界程序员之所以有高下之分，最大的区别就是程序员的“品味”不一样。有品位的程序员和没有品位的程序员，写出来的代码，差距非常大。

为什么这么说呢？举个例子，在一次代码评审中，我注意到了这样一段代码：

public void approve(final long bookId) {  ...  book.setReviewStatus(ReviewStatus.APPROVED);  ...}

这是在一个服务类里面写的，它的主要逻辑就是从仓库中找出一个作品，然后，将它的状态设置为审核通过，再将它存回去。其中，设置作品评审状态的代码引起了我的注意，于是有了下面这段对话。

同事被我说动了，于是这段代码变成了下面这个样子：

public void approve(final long bookId) {  ...  book.approve();  ...}

之所以我注意到这段代码，完全是因为这里用到了 setter。setter 通常意味着变化，setter 的出现，是对于封装的破坏，把一个类内部的实现细节暴露了出来。

在我看来，setter 就是一个代码的坏味道，其背后隐藏着很多的问题。而所有这些问题，都会让代码在未来的日子变得更加不可维护，这就是软件团队陷入泥潭的开始。

而对个人来说，一个程序员从业余迈向职业的第一步，就是能够把代码写得具有可维护性。

我建议你从“代码的坏味道”入手。

为什么？想想我们以往学知识，大多都会告诉我们应该怎样做、怎样做是好的，但理解这些内容，需要我们对整洁代码有着深厚的理解，而每个人对同一件事的理解程度是不一样的。

比如说，我们都知道“命名是要有意义的”，但什么样的命名才算是有意义的呢？有的人只理解到不用 xyz 命名，虽然他起出了自认为“有意义”的名字，但这些名字依然很难懂。

如果只知道正面的代码是什么样子，却不知道反面的代码是什么样子，很多问题重重的代码就堂而皇之的留在了眼皮底下，自己都发现不了，这就为未来的开发埋下了无数的隐患。

坏味道是写出好代码的起点。首先你要有对代码坏味道的嗅觉，能够识别出坏味道，接下来，你才有机会去“重构（Refactoring）”，把代码一点点打磨成一个整洁的代码（Clean Code）。

所以，我和极客时间再次合作，推出了这个讲坏味道的专栏《代码之丑》，我总结了一套实用的代码坏味道「自查清单」，25+ 真实代码段反面案例，我会告诉你典型的坏味道是什么，带你分析产生坏味道的本质原因，以及以应对这些坏味道的 25+ 重构手法。

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/