您应该以团队中最低的技能水平进行开发吗？

本文探讨了我在团队中开发代码时的一些想法：你是否应该以团队中最低的技能水平来开发？我开始认为是应该的。请继续阅读，了解我背后的思考……

引言

最近，我开始思考一个问题：当一个开发人员在团队中编写代码时，他们是否应该以团队中最低的技能水平为基准？我开始得出的结论是，他们应该这样做，本文将解释我这么想的原因。

背景

那么，是什么让我产生这种想法的呢？嗯，最近我发布了一个小技巧，是关于我创建的一个简单的扩展方法，用于将一个类型化列表转换为 CSV 字符串。

我的解决方案是一百多行的“传统”代码，包含“for i”循环、带大括号的“if”语句，并分解成许多简短精炼的方法。然而，几乎立刻就有回复出现，建议将代码重构为由 LinQ、Lambda 和合并表达式组成的复杂单行代码。

现在，我对单行代码没有任何意见，而且回复者显然炫耀了他在 LinQ 和 Lambda 表达式方面的技术知识。对我来说，问题在于我发现它不易阅读，因为我个人不擅长 Lambda 或复杂的 LinQ 查询；而且请记住，我已经知道这位编码者试图解决的是什么问题！

于是我开始想象，如果我在维护公司团队里其他成员开发的应用时遇到这样的代码，会是怎样的情景。我将有两个选择。如果写这段代码的同事在，我就得让他一步一步地给我讲解，直到我明白为止。但如果写代码的人不在或联系不上，我想我的下一个选择就是让 Resharper 把代码“反重构”回 for 循环和 if 语句。

这真的让我开始思考，也引出了我写这篇文章的原因……

我们为什么要以最低技能水平编写代码？

毫无疑问，这个话题会引起争议，因为任何开发人员的一个关键驱动力就是学习新的编码方式、新技术和新框架，甚至可能是新的编程语言。但我想提出的是，在商业开发环境中工作时，可以换一种思维方式，因为在这种环境下，团队中的多名成员最终都会维护一个开发人员的代码。以下面的情景为例。

场景

一个由五名开发人员组成的团队，在一家名为 Z 公司 的商业公司担任内部开发团队。高级开发人员 A 和高级开发人员 B 是技术非常娴熟的资深开发人员，他们总是在知识和技术上不断进取，并在项目中试验和实施新技术。开发人员 C 和开发人员 D 是称职的开发人员，虽然他们不是团队中新编码实践的开创者，但他们能够理解并维护前两位开发人员写的大部分代码，不过有时可能需要经过大量的阅读和反复阅读。开发人员 E 是团队的一位新人，但已在公司工作多年，为 Z 公司的许多 MS Excel 电子表格和 MS Excel 数据库编写 VBA 宏和函数。他/她对公司有丰富的业务知识，但在团队首选的开发语言方面，其高级技能和自信心水平仍不及其他四位开发人员。

高级开发人员 A 和开发人员 C 正在合作一个新项目，并希望实施一种他们最近读到的编码架构。他们知道高级开发人员 B 也有兴趣在某个时候使用这个新架构，并欢迎将其纳入团队的编码资产库中。然而，开发人员 D 和开发人员 E 都没有跟上这个架构的步伐，他们通常以更传统的风格编写代码。那么，开发 A 和开发 C 是否应该就这么继续下去，在新项目中实施这个新的代码架构？从他们的角度来看，他们当然想这么做。他们希望增加自己的知识，也可能通过将这项新技术添加到未来的简历中来提高自己的就业能力。更不用说，新的代码架构、框架或编程风格总是令人兴奋的。

但整个团队从中能得到什么呢？团队得到的是一个不断演进的代码库，由于变化速度太快，标准的工作方式永远无法扎根。技能较低的团队成员可能会开始感到被疏远，因为每次他们还没来得及赶上，目标就又变了。技能差距可能会扩大，他们可能会害怕不得不维护开发人员 B 的又一个应用，因为他们知道那将意味着要费力地阅读一行又一行充满了最新编码潮流的抽象代码，才能理解它。

那么 Z 公司又能从中得到什么呢？好处不多。如果允许开发人员写出他们个人自负所要求的代码，而不考虑其他团队成员阅读、扩展或维护代码的能力，那么公司除了为应用程序埋下一个潜在的单点故障之外，一无所获，还可能让半个开发团队感到沮丧和缺乏热情。这还可能增加公司的维护时间成本，这将影响到公司的利润，并进而影响到开发人员的预期奖金。

那么我到底在说什么？

那么我是说所有开发人员都应该放弃学习新的开发方式吗？不，我不是。我想说的是，如果你确实想学习和尝试新事物，请确保你带领团队的其他成员一同踏上这段旅程。让团队其他成员参与到尝试新框架或架构的决策中来。确保你定期进行演示分享或实验性会议，以确保团队中的每个人都理解新架构为何以及如何实施。确保你的代码对于所有应该维护它的团队成员来说都是可读和可理解的。如果你写了一个神奇的单行代码，请确保你的初级开发人员能明白它到底在做什么。如果他不能理解，而你又不能很快地教会他，那么就把它分解成他能理解的小块。为了你所效力的公司，不要让你和你的编码自负成为你的团队（本应）维护的应用程序的单点故障。

坦白

别误会，我和其他人一样，也曾在一个项目中尝试过那个了不起的新框架，并只是希望在我不在的时候团队能够维护它！我也曾站在另一端，比如几年前，为了能够在一个项目中进行协同开发，我不得不学习 Ninject 和依赖注入，而那个框架和方法论已经由首席开发人员部署好了。我当时感觉自己永远也学不会（也许这和我多年前从过程式代码转向面向对象方法时的感觉一样），感到不知所措，无法理解这一切是如何组合在一起的。

但我正在努力改变我的思维方式，通过这篇文章，我也试图帮助你改变你的思维方式，这样我们生活的编码世界会变得更美好，特别是对于初级开发人员或那些工作职责主要集中在维护和扩展遗留代码应用程序的人们！

摘要

总结一下……我们都喜欢努力提升我们的开发技能和知识，我绝不是说我们不应该这样做。但是，当在一个团队中工作，处理团队最终需要维护的代码时，也许我们应该退后一步，换个角度思考。初级开发小吉能维护这个吗？还是我需要向他解释？我是否刚刚写下了一个除了我之外没人能懂的单点维护故障？

也许同样地，你可能会请一位经验更丰富的开发人员来审查和评判你的代码的技术卓越性和可读性，你也应该请初级开发人员阅读你的代码，并向你解释他认为代码在做什么。如果他不能轻松地解释，那么也许就不要包含这段代码，或者如果出于技术或性能原因真的必须包含，那就承担起责任，安排一次知识转移会议，让所有团队成员在该代码元素上达到同一水平。请记住，在性能成为问题之前，最好的代码是清晰易懂的代码。

反馈

我非常希望听到社区对我就“为最低技能水平编写代码”这一想法的看法和感受。我想听听双方的意见：从那些阅读最新博客并在第二天就将最新编码潮流应用到生产代码中的技术先进的架构大师，到那些拼命试图维护他们几乎看不懂的代码，这些代码似乎模拟了他们几乎无法理解的某种抽象概念的初级开发人员。

历史

• 2015-10-18 初稿