开发人员能够得到的最好赞扬

38顶
3踩

2011-01-17 09:32 by 见习编辑 jobbole 评论(29) 有17599人浏览

敏捷开发

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

编者按：原文作者Phil Haack 从1997年开始从事软件开发，目前担任微软的ASP.NET MVC框架的高级项目经理，另外也负责ASP.NET的部分特性。Phil认为：开发人员能够获得的最大赞扬，就是其他开发人员的给予的赞扬。即：同行的赞扬！

　　作为软件开发人员，有一个小秘密：不管你写的代码有多么优秀，对另外一位开发人员来说，都毫无用处。

　　如果代码足够“干净”，你都可以吃代码上面的寿司，这没什么。如果每次代码显示在屏幕上时，约翰·卡马克（John Carmack）和Linus
Torvalds都对这些代码都佩服的五体投地，这也没什么。但一些开发人员称这些代码是垃圾，而这些人通常就是你离开之后接手你代码的人。

　　原因有很多，而且比较琐碎：

在方法/函数中，你使用了字符串串联，而不是StringBuilder类。所以，如果这种情况发生，那么做出这样的决定就是有意的，因为一般这样的算法只会串联3到4个字符串。下一个开发人员才不关心这些。

没有按照规定把花括号放到应该放置的那一行，而是放到了同一行（反之亦然）。

使用了switch语句，但大家（包括下一个开发人员）都认为应当将其替换为状态或者策略模式。难道你没读过《设计模式》这本书吗？不要因为只有一个switch语句导致没有代码重复而担心。

在依赖注入（Dependency Injection）技术上，你采用Spring.NET，但下一个开发人员更喜欢使用Windsor。他们认为只有白痴才使用Spring.NET（反之亦然）。

或者你自始至终一直都在采用依赖注入技术。依赖注入到底是什么鬼东西？现在我完全看不懂代码！:(

　　尽管我们为完美代码而努力，但在真正的项目开发中，这是很难实现的。因为代码会受诸如时间压力之类的约束限制。不幸的是，从代码中看不出约束来，看到的只是这些约束造成的影响。当下一个开发人员阅读你的代码时，他们是看不出这些代码是在项目发布前的剩余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　　编译：伯乐在线敏捷翻译组 - 牛冬梅

　　如需转载，但请注明原文/译文出处、译文超链接和译者等信息，否则视为侵权，谢谢合作！

查看图片附件

来自: www.jobbole.com

分享到：

38
顶

3
踩

评论共 29 条请登录后发表评论

29 楼 aochant 2011-03-12 11:12

呃，跟我的看法不一样，
我认为开发人员得到最好的赞扬的是看到用户久旱逢甘霖的表情。
记得有一次我熬了2个通宵满足了用户一个突发并且急迫的需求。
使得他们完成某项任务由2个小时繁琐的操作变成了只需要点几下鼠标。
给他们演示的时候，我看到他们的眼神。。。。久旱逢甘霖啊，不需要语言上的夸奖
唉当时就觉得这两个通宵是多么的值得。

28 楼 yuyuypjk 2011-01-19 14:49

27 楼 lf98287 2011-01-19 13:06

写得真的很实在啊~ 看得我很有感觉

26 楼 madbluesky 2011-01-19 12:28

将约束，限制等加入注释中看起来是个不错的想法，有机会可以尝试一下，不过，这样好象会容易将自己的内心的情绪暴露出来，运气不好被主管看到。。。

25 楼 cobb.chan 2011-01-19 09:37

薪资表扬最实惠，最诱人，最有成就感...

24 楼 yeshaoting 2011-01-19 09:15

sigmazel 写道

做了这么多年，我才明白，什么他妈的理论，傻瓜都能看懂你的代码比一切理论都来得实际！

最近也纠结过理论与实践

23 楼徐风子 2011-01-19 08:38

来晚了，居然没赶上狂欢，唉……

22 楼 yidao620c 2011-01-18 19:26

那一大串的评论怎么不见了啊，我来就是来看那个好长好长好长的评论的啊。

21 楼 feifei_12 2011-01-18 17:44

没有什么比涨工资更实在的啦

20 楼 pouyang 2011-01-18 12:52

19 楼 houzhaowei 2011-01-18 09:56

中国的悲哀。。

18 楼 denger 2011-01-18 09:09

中国技术的悲哀～

17 楼 yinzhao 2011-01-18 08:10

16 楼 wangxiang243 2011-01-17 20:30

15 楼 KimHo 2011-01-17 20:23

搞不懂那些回帖恶搞的人，浪费服务器资源，有意思么？

14 楼 chenandzoff 2011-01-17 20:19

13 楼 marc0658 2011-01-17 17:55

什么情况。。。。

12 楼 lobbychmd 2011-01-17 17:53

11 楼 jesin 2011-01-17 17:16

评论这没网易的好
嘿嘿

10 楼 sigmazel 2011-01-17 15:43

做了这么多年，我才明白，什么他妈的理论，傻瓜都能看懂你的代码比一切理论都来得实际！

发表评论

您还没有登录,请您登录后再发表评论

38顶3踩