|
|
作为软件开发人员，有一个小秘密：不管你写的代码有多么优秀，对另外一位开发人员来说，都毫无用处。
如果代码足够“干净”，你都可以吃代码上面的寿司，这没什么。如果每次代码显示在屏幕上时，约翰·卡马克（John Carmack）和LinusTorvalds都对这些代码都佩服的五体投地，这也没什么。但一些开发人员称这些代码是垃圾，而这些人通常就是你离开之后接手你代码的人。
原因有很多，而且比较琐碎：
- 在方法/函数中，你使用了字符串串联，而不是StringBuilder类。所以，如果这种情况发生，那么做出这样的决定就是有意的，因为一般这样的算法只会串联3到4个字符串。下一个开发人员才不关心这些。
- 没有按照规定把花括号放到应该放置的那一行，而是放到了同一行（反之亦然）。
- 使用了switch语句，但大家（包括下一个开发人员）都认为应当将其替换为状态或者策略模式。难道你没读过《设计模式》这本书吗？不要因为只有一个switch语句导致没有代码重复而担心。
- 或者你自始至终一直都在采用依赖注入技术。依赖注入到底是什么鬼东西？现在我完全看不懂代码！:(
尽管我们为完美代码而努力，但在真正的项目开发中，这是很难实现的。因为代码会受诸如时间压力之类的约束限制。不幸的是，从代码中看不出约束来， 看到的只是这些约束造成的影响。当下一个开发人员阅读你的代码时，他们是看不出这些代码是在项目发布前的剩余1小时内完成的。
然而我承认，在被误导性评论中伤之前，很难不先对这类评论采取一些措施，比如通过注释在代码中添加一些约束。例如：
public void SomeMethod()
{
/*
程序中至多有4到5个foo，所以，在这种情况下使用字符串串联是可行的。这里有5篇有关性能讨论的帖子的链接。
让我休息一下，现在是凌晨3点了，我一直忙于Jolt，这个项目已经逾期3个月了，现在我一点社交生活都没有。放我一马吧！...
*/
string result = string.Empty;
foreach(Foo foo in Foos)
{
result += foo;
}
return result;
}
这样的防卫看起来有点过分，不过分？在注释中说明为什么制定一个特殊的、不明显的设计方案，这没什么问题。事实上，这也正是注释的作用所在，而不是为了简单地重述一下代码做了什么。
然而问题是，开发人员有时候彼此之间的制约很大，你用绿色写论述（或者你的集成开发环境中注释对应的任何一个颜色）来标明每一行代码，因为你不知道对下一个开发人员来说，什么才算是明显的。
这也是为什么前几天收到一个开发人员的电子邮件我非常高兴的原因。这个开发人员继承了我写的一些代码，并在邮件中评价了我的解决方案，在这里我引用他的原话：“写的非常棒”。
真的？你不是在愚弄我吧？Ashton，你究竟躲在哪？
这很可能是你从别的开发人员那得到的最高称赞。而且我认为这不是因为我真的是这样一个卓越的开发人员。我认为真正应该赞扬的人是那位给出称赞的开发人员。
我的意思是，当我继承别人的代码时，我的反应很有代表性，他们到底为什么要这样写代码！？难道他们没有学过如何编程么！？除了刚刚离开的那位前任开发人员，还有谁更适合做替罪羊？（编注：伯乐在线在前段时间编译的《程序员：你的代码为谁而写》一文中就说到：“要评判很久以前写出的代码是优是劣很不容易，因为现在已经不知道当时为什么编写这些代码，也不知道为谁编写了这些代码。”所以，这种替罪羊事情比较常见。）
幸好我比较机智，能将这些想法藏在心里。今后，我会在理解事情上更下功夫。当我继承别人代码时，我会假设这些代码是开发人员在72小时内一次编码完成的，他魔兽世界中的角色身边到处都是蜜蜂和劫持的人质，在一切真正开始变糟之前，他只有1个小时，并且是在一台386的机器上来完成编码。
鉴于那些情况，难怪那个笨蛋不使用IDisposable实例附近的代码块。
译文出处：伯乐在线 - 职场博客
译文链接：http://www.jobbole.com/entry.php/452
原文作者：Phil Haack 编译：伯乐在线 敏捷翻译组 - 牛冬梅
如需转载，但请注明原文/译文出处、译文超链接和译者等信息，否则视为侵权，谢谢合作！
it知识库：开发人员能够得到的最好赞扬，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
