当团队中的开发者编写代码时，他们是否应该考虑到团队中技能水平最低的成员？逐渐得出结论，认为他们应该这样做。本文将解释这样想的原因。
是什么让产生了这样的想法呢？最近发布了一个小技巧，是关于创建的一个简单扩展方法，用于将类型化列表转换为CSV字符串。解决方案是100多行的“传统”代码，包含了“for i”循环、大括号“if”语句，并被分解成许多简短而精确的方法。然而，几乎立刻就有回复建议，也许代码应该被重构为一个复杂的一行代码，由LinQ、Lambda和coalesce表达式组成。
并不反对一行代码，回复者显然展示了他对LinQ和lambda表达式的技术知识。但对来说，发现这并不容易阅读，因为个人对lambdas或复杂的LinQ查询并不擅长；而且请记住，已经知道编码者试图解决的问题是什么了！
所以开始想象，如果在支持团队中其他成员编写的应用程序时遇到这样的代码，会是什么样子。有两个选择。如果写代码的人在场，那么得让他一步一步地解释，直到理解为止。如果写代码的人不在场或不可用，那么想下一个选择就是让Resharper将代码“反重构”回for循环和if语句。
这真的让开始思考，这也带来到了写这篇文章的原因...
这个话题肯定会有争议，因为任何开发者的关键驱动力之一就是学习新的编码方式、新技术和新框架，甚至可能是新的编程语言。但想提出的是，在商业开发环境中工作时的一种不同的思考方式，团队中的多个成员最终将支持开发者的代码。以以下情景为例。
一个由五名开发者组成的团队正在为一家名为Company Z的商业公司担任内部开发团队。高级开发者A和高级开发者B是非常技术娴熟的高级开发者，他们总是在推动他们的知识和技术，以及他们在项目中尝试和实现的技术。
开发者C和开发者D是有能力的开发者，虽然不是团队中新编码实践的架构师，但他们可以跟随并支持前两位开发者编写的大部分代码，但有时可能需要大量的阅读和重读。
开发者E是团队中的相对新手，但已经在公司工作多年，为Company Z的许多MS Excel电子表格和MS Excel数据库编写VBA宏和函数。他/她对公司有丰富的业务知识，但在团队首选的开发语言方面，仍然缺乏其他四名开发者的一些高级技能和信心水平。
高级开发者A和开发者C正在一起开发一个新项目，他们想实现他们最近读到的编码架构。他们知道高级开发者B也对在某个时候使用这种新架构感兴趣，并欢迎将其纳入团队的编码组合中。然而，开发者D和开发者E并不熟悉这种架构，通常以更传统的风格编写他们的代码。开发者A和开发者C应该在新项目中实施这种新的代码架构吗？从他们的角度来看，他们当然想要。他们想通过在简历/简历中添加这项新技术来增加他们的知识，也许还有他们的就业能力。更不用说新的代码架构、框架或编程风格总是令人兴奋的。
但团队作为一个整体从这中获得了什么？团队获得了一个不断演变的代码库，由于变化的速度，标准的工作方式永远无法生根。团队中技能较低的成员可能会开始感到被排斥，因为目标在他们有机会达到之前一直在移动。技能差距可能会扩大，他们可能会害怕不得不支持开发者B的另一个应用程序，因为他们知道这意味着要浏览一行又一行的抽象代码，充满了最新的编码时尚，只是为了理解它。
那么Company Z从中获得了什么？并不多。如果允许开发者按照他们的自要求编写代码，而不考虑其他团队成员能够阅读、扩展或支持代码的能力，那么公司除了应用程序的潜在单一故障点之外，什么也得不到，也许还有一半的开发团队感到沮丧和不热情。这可能会导致公司在支持时间上花费更多，这将从底线中扣除，反过来又会影响开发者的预期奖金。
那么是说所有开发者都应该放弃学习新的开发方式吗？不，不是。说的是，如果想学习和尝试新事物，请确保把团队的其他成员也带上旅程。让团队的其他成员参与到尝试新框架或架构的决策中来。确保定期进行“展示和讲述”，或者实验室会议，以确保团队中的每个人都理解为什么和如何实现新的架构。确保代码对所有应该支持它的团队成员来说是可读和可理解的。如果写了一个“神奇的一行代码”，请确保初级开发者能理解它在做什么。如果他不能，也不能很快地训练他理解，那么请把它分解成他能理解的小块。为了工作的业务，请不要让自己和编码自成为应用程序的单一故障点，团队（应该）支持。
别误会，和下一个人一样有罪，试图在项目中尝试那个“惊人的新框架”，并希望团队在缺席时能够支持它！也曾在另一端，例如几年前不得不学习Ninject和依赖注入，以便能够共同开发一个项目，该项目已经由首席开发者放置了框架和方法。觉得永远也得不到（也许这和多年前从过程代码转向面向对象的方法时的感觉一样），感到不知所措，无法理解它们是如何连接在一起的。
但正在尝试改变心态，通过这篇文章，试图帮助改变心态，让生活的编码世界变得更好，特别是对于初级开发者或那些主要工作是支持和扩展遗留代码应用程序的人！
总之...都喜欢努力提高开发技能和知识，绝不是说不应该。但是当在一个团队中工作，团队最终会支持代码，也许应该退后一步，稍微改变一下思考方式。Jimmy初级开发者能够支持这个吗，还是需要向他解释？刚刚写了一个单一的支持故障点，除了没有人能理解吗？
也许以同样的方式，可以要求一个更有经验的开发者审查和批评代码，以技术卓越和可读性为标准，也应该要求初级开发者阅读代码，并向解释他认为代码在做什么。如果他不能轻易解释，那么也许不要包含代码，或者如果它真的必须包含，出于技术或性能原因，承担责任并安排一个知识转移会议，使所有团队成员都能达到代码的同一水平。记住，直到性能成为一个问题，最好的代码是清晰易懂的代码。