代码看起来越“干净”越好？？？

最近阅读了 Dan Abramov 的一篇博客 Goodbye, Clean Code。读完之后，对自己写过得项目有一些反思，也对未来写代码有一些思考。在这里想和大家分享一下。Dan 本身是 React 的核心开发成员，也是 Redux 的作者，这篇文章建议大家阅读一下原文。这也算是一个经验丰富的老程序员给大家的一个防踩坑指南。

我们在重构代码的时候，有时候过于追求代码的整洁度和封装性，而往往忽略了一些其他重要的东西。

这篇文章大概讲述了 Dan 有一次在和同时合作写代码的时候，发现了同事的代码里面存在大量的重复代码，于是把这些重复的代码抽象成一个个函数。他对代码的重构，直接让代码看起来更加“简洁”，并且代码的数量直接减少了一半。

然而……第二天，Dan 被老板约谈。老板要求它把代码都还原回去。当时他当然是愤愤不平，但是多年以后终于明白了一些很重要的道理。

我们在看到自己做的项目里面复杂纷乱的代码之后，有时候会忍不住去重构，比如把它们抽象出一个个函数或者类。改完代码之后，看到代码量减少了一大半，不禁内心欣喜和自豪——我好厉害，他们好菜。但是这有可能是一场灾难。按照 Dan 的意思

• 首先，我们在修改代码的时候，没有代码的作者或者小组的其他成员商量而擅自作出决定（即使修改的时候认为这件事情是正确的）。这并不是一个健康的团队状态。一个团队应该有足够多的彼此的信任和沟通。

• 第二，天下没有免费的午餐。重构完代码之后代码确实简介了许多。可是，如果今后有些场景需要一些特殊的处理，那这些抽象出来的代码可能会成为一道很大的阻碍。

Dan 在这篇文章中并不是呼吁大家要写出罗嗦冗余的脏代码，而是要让我们在重构代码之前一定要三思而后行。我们不要过度追求代码的整洁度和封装性。我们在修改他人的代码的时候，不妨多一些思考：

• 他当时为什么要这么写？
• 如果我不知道，我是不是要代码的作者或者 leader 讨论一下？
• 如果我改了之后，今后如果有其他的改动怎么办？
• 我这样做是否真的可以提高代码的可维护性？

我们在封装了别人的代码之后有时候会感到自豪，觉得自己十一个资深的开发者。我想在这里把文章的结尾贴在这里与大家共享

But don’t stop there. Don’t be a clean code zealot. Clean code is not a goal. It’s an attempt to make some sense out of the immense complexity of systems we’re dealing with. It’s a defense mechanism when you’re not yet sure how a change would affect the codebase but you need guidance in a sea of unknows.

Let clean code guide you. Then let it go.

不要止步于此。不要成为干净代码的狂热者。干净的代码并不是目的。它可能会让我们在我们正在处理的复杂系统中找到一点意义。但是当你还不确定你的重构和修改会对整个代码结构造成什么影响的时候，它其实是一个防御机制，但是你需要在无尽的未知海洋中寻找一个指引。

所以就让干净的代码指引你，然后扔下它。

Happy Coding!