最近看到一个问题，叫做「你们会因为代码烂，而入职两三天选择离职吗？」。

其实早先有过一些关于代码质量的讨论，比如「关于烂代码的那些事」，「程序员的日常：哪个蠢蛋写的烂代码？」，「你的代码写的很烂」。这让很多程序员感受到共鸣，大家纷纷出来吐槽。

大家都在抱怨同事的代码写的烂，前同事遗留下来的代码bug多...... 那问题来了，写这些烂代码的人都去哪了？ 好奇怪哎!

遗憾的是，你既可能是那个吐槽别人给你留下了麻烦，也可能是别人嘴里那个制造麻烦的人。

非常有幸，我在维护一些历史超过5年，历经无数代优秀工程师开发迭代的项目。作为一个工作超过2年的「老人」，我有话说。

笔者总结，其实最难的不是自己写代码，而是维护别人写的代码，在复杂的逻辑中找到某一个隐藏得很深的bug，或者在某个（些）位置添加一些代码以实现新的功能。你需要按照最初实现者的思路去理解，这往往是最难的，这个过程中非常让人容易产生挫败感和不良情绪。

如果原作者仍然在职还好，有问题直接去问，但假如他已经离职，你很可能偶然会遇到下面的问题：

原作者设计得太复杂， 一点小的改进都要大费周章，完全掌控他的代码需要不少时间。

代码性能不好。之前因为用户量和访问量太少而相安无事，现在问题突然爆发了，拖慢了整个应用甚至影响到基础设施。

想要修改功能时却发现程序里充斥着各种无法理解的逻辑，改完之后莫名其妙的bug一个接一个。

在程序员这个职业里面，英雄主义实在太普遍了。有无数的理由说服领导、PM和自己，要重新造个轮子，因为大家都认为自己天下无敌了，但是又不好承认看不懂别人的代码。如果你的个人影响力和表达能力有限，没有足够的理由说服其他人选择这个轮子，又不愿意花时间推动和完善，那么最后的结果是，你认为这么美好的东西，真的只是你这么认为。等你不再维护了，离职了，下一个人又会循环这个过程... 等几年之后，项目是越来越大，但是里面大量的代码都是dead code，也就是无作用的代码。而且新人还不敢动，尤其是里面有一些magic number，复杂算法片段。

我对命名这件事做的极为不好，大部分的命名除了惯例，就是从各种开源项目里面学到的用法和套路，所以我建议所有入行的人尽最大的能力学好英语。我之前见过一个英语极好而且非常喜欢阅读英文原著的工程师，但是他写代码很「飘逸」，怎么说呢， 就是他会直接用英文原著的一些词语作为变量名字，逼格极高，但是我经常得谷歌翻译了，因为看变量名完全不懂这是啥啊。有时候还得问他，他总是拽拽的说，这个是因为XXX典故......，恍然大悟。

看代码就可以看到作者的性格和风格，比如有的人喜欢用设计模式，有的人喜欢把新学到的编程技巧强行放到项目里。高级特性齐飞，一眼瞅去：高端。但是对于真的高手来说，其实露怯了，因为用的人根本没懂正确和合理的使用场景呢。 一个真实的故事，在一次代码评审中，我们质疑了一下「为什么在这里要使用装饰器？」，结果对方的回应是：「因为这样显得逼格高...」，我当时心中千万只羊驼呼啸而过，想象下我的心理阴影。

但是不是所有前人写的都比自己差呢？其实不尽然，甚至于是可能会让你不愿意接受的事实。我以前也很唾弃别人的代码。当我看到一段不符合自己价值观的代码，理所当然认为这毋庸置疑的写的烂，于是我删掉了那段代码，用自己认为更好的方法重新写了一遍，心情极好，觉得我挽救了这个项目。当我对这部分业务逻辑熟悉了之后，回头再看，发现我所删掉的那段代码其实用的处理的方式是最恰当的，而我重写的虽然Python语法写的很好，但可扩展性很差。

其实有时候我们不理解的，不是人家用的差，而是我们的格调低。我开始收起我的傲慢，不会一上来就指责别人，对不甚了解的领域保持敬畏，以免看起来像个小丑。

上面的也是在吐槽，我还是说点对写好代码的理解吧。

代码是给人读的，顺便让机器执行

上面这句话我非常认同。好的代码是什么样子的呢？

Bjarne Stroustrup（C++之父）说：

逻辑应该是清晰的，bug难以隐藏。

依赖最少，易于维护。

错误处理完全根据一个明确的策略。

性能接近最佳，避免代码混乱和无原则的优化。

整洁的代码只做一件事。

Michael Feathers（《修改代码的艺术》作者）说：

整洁的代码看起来总是像很在乎代码质量的人写的。

没有明显的需要改善的地方。

代码的作者似乎考虑到了所有的事情。

可以感受到，对好的代码的理解有很多共通的地方：

代码简单，代码意图明确，其他人才容易与你协作。

可读性和可维护性要高。

以最合适的方式解决问题。

和大家共勉，不要做别人嘴里的`蠢蛋`。

--- 分割线 ---

Python语言给外人第一印象就是简单，上手快，有其他开发语言经验的人一周就可上手工作，好像Python就是这么简单似得。可以为啥合适的Python高级开发者这么难找？因为绝大多数开发者都止步于能完成工作这个程度，也就是我们经常自嘲的一个词「码农」。

不记得在哪里看过, 程序员有三种(我重新润色了一下):

拿钱干活，不爽就换 - 程序员只是一份工作。

只要能实现功能就好，学习进步太累了。这年代做技术没有管理挣钱多，技术搞得再好有什么用? 还不是买不起房啊。这年代关键是你认识多少人。你是不是有眼光去一个能上市会让你暴富的公司，能不能唬住粉丝儿和投资人。

热爱程序本身的人, 这些人可能只有1%, 他们有目标的写程序, 他们愿意思考, 愿意听取正确地/更好的方法, 他们会热爱学习新的东西。

现在产品开发迭代非常快，一周要上多个版本，每天要提多个Pull Request，对于前2种人，只能疲于应付工作，怎么样能在天赋不够又不想多花时间进步的前提下完成工作，还能到领导的好评呢？这是一门艺术呢......

优秀的工程师在思考、重构，「其他」工程师在给自己找理由：「怎么组织代码、怎么提升运行效率、原理是什么」这些重要吗？代码能跑起来不就完了。需求这么多，做都做不完，哪有时间考虑怎么做得更好啊？

明年的今天「其他」工程师还写一样的代码, 唯一不一样的是Ta老了一岁。

对于这种「其他」工程师，我也确实没有办法，每个人有自己选择生活和工作的权力，我绝对尊重，本文也不是给这些人看的。假如你不满意现状，希望做得更好，但是苦于不知道自己进阶，我分享下自己的经验。

1. 多看书，多读其他人的博客，阅读优秀的开源项目的代码甚至语言本身的源代码。这是一个长期的、琐碎的、需要学习之后记忆和实践的过程，看代码要思考别人为什么这样写，组织结构为什么这样用，这样写代码为什么快。整个过程就是进阶。

2. 想好了再开始写。大家都知道，核心的、重要的系统的代码上线后改动起来会很麻烦，非常有可能给未来留大坑，甚至于要耗费以年为单位的时间来填。所以前期的数据库表结构设计、工程实现这些东西要先想清楚了再开始写。

3. 给自己提要求。实现过程中不断的提高要求，这个要求就是比你现有的能力要高一点点。一段代码写出来的时候考虑一下会不会有比自己写的好的方法，之前有没有遇到过别人的实现借鉴下等等。

4. 选择更强的队友。遇见什么样的人，就会变成什么样子的人。去一个身边技术水平都比你烂甚至只是相当的环境，你能提高的空间非常有限。遇到一帮厉害的队友，能帮助你坐上进阶直通车，前提是你的心理素质要高，要不然长期的受到别人吐槽会产生大量不良情绪的。

5. 对别人吐槽狠。这是我的个人秘笈。之前我写代码也没有那么高的要求，后来在代码评审的时候，我为了证明比人代码写的烂，不惜花费大量时间找各种证据吐槽别人（不能说人家写的烂，但是又写不出来更好的，做这种嘴炮啊），这个过程对我有极大的能力的提高，也包括搜索信息的能力。而且你吐槽了别人，别人正憋着劲还回来。你总不希望这件事发生吧，所以你只能让自己的代码写的更好，这无形中让你对自己的代码要求要高了很多。

可能有一天， 看到一段代码，骂了句「哪个蠢蛋写的烂代码？」 结果git blame一看原来是自己写的。恭喜你，你进阶了！