我们可以通过很多标准来做出判断。
代码质量、按时交付、及时解决ticket（注：ticket类似于github中issue的意思，参考这里）是几个可以参考的标准。当然也包括帮助团队其他成员解决ticket。
我认为以上几点都没有提供准确的的量度。为了写出优美的代码而使整个项目延期了两个月，仅仅是由于你想要重构那些没有任何帮助的东西。我们都知道，关闭一个ticket并不意味着什么。
有许多变化的因素需要考虑。假如我问10个不同的程序员——他们觉得是什么成就一个优秀的开发者，我相信我会得到10种不同的回答。
我相信现在你也在思考着关于它的定义。
我曾一度挣扎于思考这个定义，所以我决定尝试并弄清楚。
我想找出所有开发者都会做的一些事情，然后我就可以基于开发者是如何做的，来对开发者的表现做出分类。
对于一个行业的优秀评估只基于一件事过于简单化，但，无论如何我都打算去试一下。
现在你可以持保留态度。
我会试着证明我做了一个不错的选择。它会是所有开发者都会做的，同时又能够将优秀的人从平庸者中筛选出来的一件事。
所有的开发者都会偶尔写出垃圾代码。
让我们正面这件事吧，你和我都会时不时写一些非常垃圾的，可耻的，以致我们永远都不希望被人看见的代码。
我们都有偶尔写出垃圾代码的理由。我不打算去讨论哪些是正当的理由，因为我们每个人都有自己正当的理由。
在展示一些编码的暴行之前，我们先回顾一下我们写垃圾代码的原因。然后我们就可以避免陷入代码气味，苦苦挣扎。
“时间不够”是目前写垃圾代码最多的一个原因。对客户的承诺、紧张的日程安排，以及正在等待的新的发布都可能是造成这个恶果的原因。
现有代码库实在是太垃圾了，让你根本不想努力写出好的代码。你知道自己无论做什么都不可能挽救这份将在某一时刻崩溃的垃圾代码库。
作为开发者，我们有时候是在不同的项目组工作。假如写完最后几行代码你就要转到一个新的项目，这并不是什么影响别人的大事情。
知道自己在这个项目上的时间即将结束，没有人会再review你的代码了。于是你就草草提交、推送，然后指望单元测试来确保没有任何问题。
我们都会偶尔写出垃圾代码。这能说明我们都是糟糕的开发者吗？
当然不能。正因为每个人都会偶尔写出糟糕的代码，所以这件事本身不能说明任何问题。
然而，多年来，我渐渐发现一个关于开发者的令人惊讶的。
在写出垃圾代码后如何表现，就是对我们开发者资质的根本检验。
有点不可思议，但确实是这样。意识到你正在写出垃圾代码，以及为了避免将来再次发生而采取的行动，都反映出你是如何写代码的，以及你一般都是如何对待写代码这件事的。
有很大的关系。
我们举Ron为例。Ron今天写了糟糕的代码，并为此不高兴。因为一个令人讨厌的五级深度的Backbone模型继承链，让Ron根本不能修改一行代码，除了打破一切。
Ron写了一段超级垃圾的代码，绕过了这个问题。每个人都很高兴，因为Ron准时交付了代码。然而除了Ron自己。
他告诉团队老大发生了什么。他们一起反复思考如何解决这个问题。他们明确了一点，打破继承链并划分为水平的组合模块是最佳的解决办法。
Ron于是请求老大给他时间实施自己和老大刚刚讨论的重构方案。
Roger今天也写了很糟糕的代码。他告诉自己的开发伙伴，自己用难以置信的hack手法绕过了一个奇怪的五级深度的Backbone模型继承链。他准备绕过整个整个架构，就这样准时交付。
Roger自己感到非常满意，觉得没有进一步改善的必要。
你可以通过程序员对待写出垃圾代码的态度，将他们分为四类，从差劲到优秀。
告诉我你没有同时遇到所有的这四类开发者。
Barney并不关心自己正在写垃圾代码。他关心的仅仅是能否按时完成工作，其他任何事都无关紧要。代码能正常运行，就没有问题。
Barney写出的垃圾代码，有时也会阻碍整个项目的进展。代码工作时，也会一直带来很多问题，让整个项目进度倒退。Barney却认为自己并不需要学习什么新的东西。
他已经知道了完成工作所需要的关于JavaScript的所有东西。
Bill并没有意识到自己正在写垃圾代码。他遵循着团队的约定和lint规则，认为自己所做的没什么问题。但他并没有花费时间去理解整个项目结构，以及不同组件之间是如何交互的。
最后的结果就是，很不幸，一片混乱。
Bill在做出重大的设计选择之前，没有咨询任何人。他自己怎么想的就怎么做。他读过三篇发表于一年前的博文，它们一直在指导着他的决定。
我经常说走进Bill的代码中，感觉就像地雷战，移动错了一步，所有的东西都会炸到你脸上。
我们前面就提过Roger这种类型。完全意识到自己在写垃圾代码。他知道如果他想好好写的话，代码会是什么样子。他拍拍自己的背，然后继续写出这段垃圾代码。
Roger的主要问题在于没有尝试做一些改变。他做了自己被要求去做的，而且完成的很好。但是他宁愿让事情该怎样就怎样，而不是花点时间，做一些努力让其有所改变。
Ron是一个优秀的程序员，但偶尔他依旧不得不写一些垃圾代码。
让Ron与别人不同的，就是在写那些垃圾代码的时候，他会认真地思考如何让这种情况不会再次发生，既不为自己，也不为任何其他人。Ron会弄清楚需要那种类型的重构，哪一块的技术方案可以改变或提升。
然后，基于这些发现，Ron会行动起来，去推动这些改变。
我必须得忏悔一下。 我就是这里的Roger。 但我也是Ron。 我也相信我曾不止一次的偶然当过Bill而自己不知道。我认为自己没有像Barney那样过，但是，到底有没有，谁知道呢！我们都在走向持久优秀之路上来来回回。有时候我们是普通的，有时候我们是好的又或是优秀的。总是在尝试着不要变成差劲的。
我们最终持续时间最长的那个角色会决定我们是什么样的开发者。
说实话，从普通开发者到好的开发者，相较于其他事情，需要的是积累更多的知识和经验。但是想要从好的跃升到优秀，你只需要改变一样——态度。
“记住，在成为伟大之前，你必须是良好。在你成为良好之前，你必须是差劲。但是，在成为差劲之前，你必须去尝试。——阿特 威廉姆斯
下载本文
