外刊IT评论今天抽风，发了很久以前的一篇博文的译文出来：《为什么我们不要.NET程序员》。本文一发，各种口水接踵而至。这篇文章实际上是《CEO Friday: Why we don’t hire .NET programmers》的译文，原文作者在发文后的两天的时间里不断的根据读者反馈对文章进行了更新和补充。但是遗憾的是外刊IT评论却未能翻译完整（不，不，你们不要指望我会翻译剩下的部分，我对此毫无兴趣。），这使得这篇很有闪光点的文章立刻变成了“孰优孰劣”的口水文章了。

看看中文翻译后的评论吧：

有一种人，自己写不出东西，就怪能写出东西的人使用的工具太先进

弱智文章

SB文章，还以为有什么高深的见解，完全是个自以为是的家伙。至多不过是了解了.net之外某一些东西，对自己完全不了解的东西大放厥词还放出优越感来了。

俺作为一名.NET程序员，鉴定结果为，“此文纯属标题党”，一笑而过~~~

我对留下这些评论的程序员感到悲哀……

我们的团队也有着大量的.NET工程师，我每天与他们共处。他们中间有聪明的、优秀的、稳重的工程师；也有躁动的、浮夸的、随意的编码人员。他们能够产生符合设计规范和要求的代码和系统；也会在不经意之间向系统引入致命 bug 而导致生产环境的崩溃。他们其实与依赖其他技术架构的程序员并无多大的不同。

早上，我看到那篇中文翻译的时候，在公司的讨论组里向大家分享了译文和原文。特别提示了，重点看看原文后面的评论。发出去后，我本以为会有人回应支持或者反对。但是没有任何一个人对那些内容进行赞扬或者批评。后来，一个比较了解我的同事私下跟我说“估计一大部分人心里不是滋味”，“一下看到标题，还有你的身份”。好吧，可能许多人心里十分不悦，但是碍于我的“身份”不便表露？我毫不介意的跟大家分享一下，我在国家正式的定义中的身份是“群众”。

我不知道会有多少团队的成员看到本文，我也无从知道他们真实的想法。不过，我可以谈谈什么样的.NET程序员是我们需要.的。

当然为了避免在我的博客上有人指责我由于“根本不了解.NET技术，也不懂windows平台，没有资格来说三道四”。我简要介绍一下我对windows平台和.NET的了解情况。

跟大部分人一样，我对计算机和IT的认识是从windows开始的。win32.hlp 这个帮助文件我想大部分年轻的.NET程序员从来没看过，甚至从来没听过。COM/COM+对于.NET平台就像战国时代的二轮马车一样遥远。PE文件结构就是放在博物馆里的竹简一般，除了历史学家会感兴趣之外毫无用处……我能举的例子还有很多，而这些在我被开源和 Linux 这个魔鬼抓去之前，是每日在学习和探索的东西。哦，忘记说了，.NET 我也不算是毫无认知。至少，在有史可查的范围内，我开源了国内第一个用C#编写的针对性SQL Injection自动化注入工具，如果没记错，那是01还是02年左右的时间。好吧，现在我是否有资格来跟大家探讨这个事情了呢？

事情还是从如何做出一个1.7盎司的汉堡说起……

作为一个.NET程序员，或者特指正在进行互联网开发的.NET程序员，你是否知道我们面对的不仅仅是1.6盎司、1.7盎司的汉堡这么简单的事情？你是否知道互联网这场盛宴不仅仅是做一两个汉堡这么简单？思考的方式有许多种，你是否陷入了做汉堡需要在哪里获得合适的面包、肉饼、洗好的蔬菜、酱料的迷题中，而忘记了手边就有面粉、烤炉，冰箱里有冷藏的鲜肉（你看，已经无需自己杀猪宰牛了），放在窗台的蔬菜上面的泥土和青虫说明菜叶相当的新鲜。

换句话说：你们是否陷入过疯狂的在.NET库中寻找一个合适的类，而忘记去看看开源社区或者第三方是否有提供更好的服务？是否执意要在微软提供的架构体系下实现一些特别的需求，其实那些需求只要一些跳出框架的小小的技巧？是否在看到业内的某些关于技术创新的一句话新闻时，就在心中暗想“这有什么先进的，.NET早有了”，而没有深入的研究为什么这一创新能够成为业内的新闻？

当然，如果对于这些你都有自己可以解释的答案，那么你或许是我们所需要的那种.NET程序员！

如果：你不但能够使用服务器端控件，还能说出其封装的底层原理；不但能够在IIS里建立应用，还能弄明白从客户在浏览器输入你的应用的地址，到他得到满意的结果，这中间每个环节隐含的细节；不但会用WCF来实现功能，也清晰的理解其中的缘由，尤其的，清晰的了解SOA应用于互联网的利弊；不但会在MSDN中查询疑难问题，也会在Google中参考出现在Mono中的类似的解决办法。

那么你应该是我们所需要的那种.NET程序员！

当然，更为优秀的，是那些能够在.NET框架下开发，却从不自称为.NET程序员的家伙们。他们不会将自己限定在某种技术、某种平台；他们热爱技术，热爱生活；他们有着像猫一样的好奇心，即便是这好奇心可能杀死他们也从不畏惧，他们同样有九条命；他们乐于钻研.NET技术，但是也会吸取其他平台的精华……

对于这样的人，我知道是可遇不可求的……

.NET、JAVA、PHP、Python……这些技术难道就没有一点贯通的地方？难道我们在自我介绍的时候不能换个说法：

我，是程序员，在现在这个阶段我对.NET的使用积累的经验更多一些。

是的，我正是这个意思，程序员可以有各种标签，但是别让标签左右了工程师的灵魂。做技术的主人还是奴隶，只是个人的选择而已。

这或许能够阐述我们要什么样的.NET程序员了吧？

我们需要的是熟悉.NET的程序员，我们真得不要“.NET程序员”。

这是典型的“死Coder责任制”和“QA无用论”合体。大家仁者见仁、智者见智吧。个中道理还是得自己参悟啊！

原文在此：http://blogs.forrester.com/mike_gualtieri/11-02-17-want_better_quality_fire_your_qa_team，原作者是Mike Gualtieri，一位应用开发和部署专家。

————翻译分割线————

严肃的说，我近期和一位客户聊天，他咒骂到，当他们去掉QA团队后软件的自量立刻得到改善。他们让软件的开发人员直接承担质量责任，以代替QA对于质量的责任。这看起来有违对于软件质量和开发者一贯的认知：不要相信开发人员，或者借鉴 Ronald Reagan所说，相信但是要验证。

其实这位客户并无懈怠。他们的应用面向金融市场提供了实时的市场数据，而这位客户每年发布超过40款软件。如果某个应用提供的市场数据不可用或发生错误，那么使用它的金融市场将崩溃。信息必须绝对可用和正确。这个应用不能宕掉，也不能发生错误。

为什么这能运作？

这位用户说，能运作的原因是开发者知道他们要100%的为应用负责。如果应用不能工作，开发者不能说“QA没有找出问题”。这里没有QA团队去推卸责任。在应用开发团队这里皮球就停下了。他们最好让一切都正常，否则就要把脑袋当皮球了。

作为英国作家Samuel Johnson幽默的描述，”上了绞刑台的精神最集中（译注：好吧，我不知道这个是不是准确，意思应该没错。原文是：The prospect of being hanged focuses the mind wonderfully.）”。

这个能为你所用吗？

如果应用开发团队对于软件质量负责，这就能运作。糟糕的质量的后果如此严重，以至于应用 团队没有选择，只有在设计、开发，和测试时集中他们的精神。这些年来我开发的多数软件并无QA团队。当你为大型企业开发关键应用做顾问的时候，要么提供更好的质量，要么掉脑袋，得不到报酬。

责任并不够。要想成功，应用开发团队必须建立测试约束，建立测试计划，以及使用测试工具。由于开发者知道代码中哪里是藏尸地，他们可以集中力量针对应用中脆弱的部分。所付出的努力与软件的类型有关。最终的结果将是更好的质量和更快的发布周期。

刚才看到 Fenng 写的这篇博文：大技术团队的危险性。其中的一些东西，确实有一些感触。

维基百科上对于“团队”的定义是这样的（http://zh.wikipedia.org/wiki/%E5%9B%A2%E9%98%9F）：

“团队由若干独立成员共同组建，有临时与长期之分。团队要为某一共同目标而奋斗，这需要团队成员贡献各自不同的专业特长。对团队的管理不同于上下级关系的管理，是横向的交流与沟通而不是纵向的命令与服从。”

虽然不是一个十分正式的定义，不过能说明几个问题。

1. 团队不是一个人在战斗。
2. 团队有统一的目标。
3. 团队成员一定有分工。
4. 团队的工作方式是合作的，而不是管制。

团队成员不光可以是个人，还可以是一个紧凑的组织，部门甚至公司。成员间进行平等的沟通、交流，相互支撑最终达到一个确定的、统一的目标。

由于沟通交流是平等的、横向的，那么就意味着任何沟通都是点对点的。当团队成员增加时，沟通的难度也就加大。

听起来有点像早期没有交换设备的点对点电话。在只有2个端点时有1条通信链路，3个端点就增加到3条，4个端点就增加到6条……那么对于一个有 n 个成员的团队，每个团队成员就需要有 n-1 个沟通链路。当沟通链路数足够大时，整个团队的人都在忙着沟通，而不是真正进行工作。当超过临界，沟通链路超过单个成员所能承受的极限时，为了维持团队正常的运作，有一些沟通链路会被忽略。一些工作关系相对疏远的成员不再进行沟通。这时从行政架构上虽然还是一个大团队，但是这个大团队已经不复存在，由若干个自然形成的小团队取而代之。

4-5个人组成了开发小组。4-5个开发小组组成了技术组。技术组、客服、市场……组成了项目组。项目1组、项目2组……组成了项目部……自最终稳定的团队结构是树形的，是分层的。站在每层去看，每层的团队都是小团队。当某一层上的团队开始有大团队出现时必然会有新的层次出现，将大团队重新划分为小团队。

这或许就是“无为而治”的道理吧。

硬是要将这种很有美感的、自然的组织架构重新排布，徒增本不需要的沟通链路，那么团队的结果或许跟瓦沙一样最终沉没。