为什么你的前任开发者是糟糕的

本文是翻译,版权归原作者所有


为什么你的现任开发者貌似如此优秀

你为正在使用的项目雇佣了一名新开发者,她好像已经解决了所有问题。虽然她只来了3天,她就已经建议升级了5个类库,重新组织了JIRA问题。每一次,她好像在向你证明,雇佣她是正确的选择。她发现了8个明显的、会产生致命崩溃的bug。你的前任开发者是多么地愚蠢呀,竟然一个都没有发现??她不理解他使用XYZ框架的决定,也不理解在这个特定的应用程序中,他为什么选择使用Postgres而不是CouchDB。她向你抱怨,缺乏CDN就是把你的大把时间花在了不必要的内容服务上。你怎么能对此视而不见?好吧,这不是你的职责,对吧?那是你的前任开发者的职责,他好像极度失败了。终于解脱了。

现任的诅咒

不要担心——你的处境远非个例。我一直时不时地看到这一幕,一个新的开发者来了,好像一夜之间改变了一切。她或他建议新的工具、新的流程、新的语言和新的一切。所有这一切都在诅咒前任开发者或团队。我在这出好戏扮演过各个角色。我曾经是新家伙痛骂的“前任开发者”。我曾经是把前任家伙用作替罪羊的新家伙。我雇佣过这两个位置上的开发者。我为公司工作,而公司不能明白,对我而言什么是简单的:这一直都在上演。

我把这称作“现任的诅咒。”做为一名开发者,当你看到用来构建某个应用程序的选择时,你每一次都被错误的决定吹走了。“为什么,啊为什么,在Node.js将是如此优秀的时候,它居然使用Rails?”,或“前任开发者怎么没有预见到,当他们选择MongoDB时,数据库是需要引用完整性的?”但是,你或许没有意识到,你以今天的眼光来看它当初的样子。当前任开发者(或团队)不得不开发的时候,他们不得不处理大量未知因素。他们不得不在信息不对称的前提下做出很多决定。你在现在的情况下被诅咒了,因此系统好像变成了错误决定下的苦差。

停止责备

开发者倾向于责备前任的另一个原因是因为责备比较容易。前任开发者不再需要评判他的行为,也不会在那儿保卫自己。因此责备他是超级容易的。如果一个开发者不想努力工作或解决一个特定问题,责怪系统固有的东西要比懒惰(或不胜任)更容易。当老板问“某个项目的时间点”,说“哦,通常只需要两周,但是由于我们正在处理某个类库的一个老版本,它很可能需要1个月。”老版本花费时间长或许是真的,但你这个开发者当月只是不想工作太辛苦也可能是真的。

辩解

由于某种原因你雇佣了这个新开发者。经过一系列的面试、代码测试以及类似的过程,你最终雇佣了这个人。现在,这个人不得不证明他们是物有所值的。开发者往往认为较好的方式是早些做出重大的改变。实现所有种类的过程,尽管不需要实现;引入所有种类的工具,最好是团队其他人没听到过的工具。我看到过不计其数的这种行为的组合,一个开发者四周转转,说使用Pivotal是多么地不好,我们现在需要使用JIRA,或他们不能相信我们仍然在用Subversion、因此我们应该怎样迁移到Git。这向我们已有的知识辩解,心里希望给你,哦,光荣的老板留下印象。

该结束了

我认为因为某事简单地责备前任开发者或团队是糟糕的实践。给他们怀疑的好处,设想他们在当时受限条件下已经做出了最好的决定。他们不了解这个完全通透的系统。短期看,它或许使你在融入组织的时候打上霸主的印记,但长期看,它伤害了我们所有人。我们一直都是在我们离开之后、因数不清的问题而被指责的开发者——知道这发生在你身上会觉得不舒服,因此为什么要对其他人这样做呢?把道德举高一些。即使是前任开发者的错误,不要那样陷害他。

通过成为一名可靠的团队成员,来做长期的英雄,在任何时候你都能做出好的判断。不要做短期英雄,这会众叛亲离。你很可能已经得手了,但是我们(开发者社区)不会太喜欢你,如果你是这样的话。现在,就算这样,有一些 前任开发者是一个真正糟糕的开发者 的情况。那种情况下,马上让利益相关者注意到这一切,而不是在你不想、或做不到的时候,做为你自己的一个方便的借口。

这是我的夸夸奇谈,我会继续的。

原文地址:https://medium.com/programming-stories/506a06ae35ea

译文:为什么你的前任开发者是糟糕的 》| 腊八粥