开发者/非开发者阻抗不匹配

大多数软件开发人员可能听说过对象关系阻抗不匹配 （通常使用ORM工具解决 ）， 对象XML阻抗不匹配 （通常使用OXM工具解决），甚至开发人员-DBA阻抗不匹配 ，甚至都有过经验。 我不认为这些阻抗不匹配有时很难做到 ，但是对于那些希望减轻它们的人，我们拥有诸如Java Persistence API实现和JDO实现之类的工具来处理对象关系不匹配（以及某些开发人员与DBA的阻抗不匹配），并且类似地具有JAXB ， XMLBeans ， JiBX和Apache Commons Digester之类的方法来处理对象XML的不匹配（.NET的LINQ处理ORM和OXM的不匹配）。 在我职业生涯的这一点上，我相信开发人员/非开发人员的阻抗不匹配可能是我遇到的最令人沮丧的阻抗不匹配。

尽管有很多工具和方法可用于处理其他类型的阻抗失配，但似乎我们却严重缺乏类似功能强大的工具，方法和行之有效的方法 （我认为“ 最佳方法 ”的新的首选术语本来就是意图指开发人员/非开发人员的不匹配问题。 在本文中，我将介绍一些开发人员/非开发人员不匹配的最常见区域，并推测它们为什么会发生，以及可以采取哪些措施来解决开发人员/非开发人员阻抗不匹配的这些特定领域。

遗憾的是，我们对开发者/非开发者阻抗不匹配的控制要比对对象关系或对象XML阻抗不匹配的控制少得多。 尽管通常来说，改善沟通和教育等方面的工作可以有所帮助，但这些答案并不像我们过去用来处理其他类型的软件开发阻抗不匹配时那样明显。 要解决开发人员/非开发人员的阻抗失配问题非常困难，我们必须这样做，因为在软件开发过程中有许多重要的利益相关者不一定是开发人员（经理，客户，测试人员，客户，业务分析师，销售人员）。人等等）。

DRY原理/模块化

几乎是一个错误，开发人员通常采用（至少在理论上，如果不是经常在实践中）在经常被引用的《实用程序员：从行家到大师》一书中提出的DRY（ 不要重复自己 ）原则。 尽管该术语是在1999年的这本书中创造的，但这种做法已经成为数十年来开发人员在某种程度上已经理解的做法。 无论使用本地口语还是喜欢的编程语言，当今的开发人员都广泛认识到某种程度的干性的优点。 关于应该采用哪种级别可能存在一些争论 （我已经看过了它超越了常识），但是我们大多数人都同意在软件产品的不同级别上重复文档或重复代码的危害（ 复制和粘贴开发 ）。

本杰明·登克拉 （ Benjamin Denckla ）在“ 干燥中的信念； 没有软件的希望 ，”今天写道，“如今，我们通过艰苦而无纪律的过程来生产软件，该过程将许多人的低质量工作与少数人的高品质高质量工作结合在一起。 ……没有足够的人相信DRY和类似的其他良好做法。” 我认为，当考虑非软件开发项目的非开发人员时，尤其如此。 根据我的经验，开发人员通常确实会在一定程度上了解DRY的价值，但非开发人员的利益相关者则几乎看不到DRY原则的价值。

为了便于讨论，我将模块化称为“ DRY”实践。 大多数开发人员知道，有很多原因不会将同一代码复制并粘贴到多个位置。 数十年来，开发人员已经知道将可重用的代码放置在方法，函数，模块或其他允许在多个上下文和情况下使用同一代码的构造中。 很快，这便成为经验丰富的开发人员的第二天性。 令人遗憾的是，许多非开发人员似乎没有意识到与从各地复制的冗余信息相关的风险和问题，或者认为这些风险和问题在理论上比实际要多。 尽管在讨论非开发人员时可能不是在讨论代码（可能是文档，需求，规范，测试过程或许多其他非代码内容），但该原理仍然适用：以多种方式复制任何内容这些地方会导致维护方面的问题，并使许多版本与最新版本和最新版本保持同步。 开发人员似乎本质上是在“获取”它，但是我认为它在许多非开发人员中不太受欢迎。

可读且可维护的代码

许多新的软件开发人员，甚至更多的非开发人员都不认识到更具可读性和可维护性的代码的价值。 年轻的开发人员可能获得的最佳体验是维护和重用他人的代码。 这样做有助于年轻的开发人员尽可能清晰地认识到编写代码的价值。 因为非开发人员从来没有真正获得过这种经验，所以毫不奇怪的是，他们没有像经验丰富的开发人员那样重视清洁性，可维护性和可读性。 许多合理的时间要求重构代码库以提高其将来的可维护性和可读性，这些忽略或立即被取消，因为这种努力的价值对于做出决定的人而言并不明显。

霸道流程和管理决策

我偶尔看到管理角色中的非开发人员试图迫使开发人员采取非常狭窄和特定的行为，他们（经理）认为这是最好的（或更糟的是，他们认为自己赋予了他们权力）。 这些人很少有经验来了解其决策的全部后果。 优秀的管理人员在推出他们拥有的每个“好主意”之前，都要先听他们的开发人员（尤其是那些具有丰富经验并担任技术领导职务的开发人员）。 经验丰富的开发人员通常知道编写高质量软件的过程，但是几乎需要另一位经验丰富的软件开发人员来理解他们的主张。 或者，缺乏软件开发经验的经理有时可以通过选择他或她对技术决策信任的有经验的开发人员来做出更好的决策。 最好的非技术经理会认识到自己缺乏技术知识，因此会与值得信赖的技术专家一起做出明智的决定。

豆计数和铅笔推

大多数软件开发是作为企业投资的一部分完成的，通常不可避免地需要一定程度的计算和推笔 。客户或消费者直接或间接地为软件开发提供资金。 对于这些面向业务的阶段，开发人员可能难以识别和欣赏合法的管理和指标收集。 对于管理人员和其他非开发人员而言，要理解某些事情比表面上的“底线”更为微妙，可能同样困难。 非开发人员可能过分强调短期“底线”注意事项，而牺牲了产品的长期质量和可维护性，而开发人员可能过分忽略了底线注意事项，并创建了需要太多时间和投资来证明其合理性的软件产品可能获得投资回报。

Bean计数器只需要能够对Bean之类的东西进行计数即可。 他或她希望使用代码行，各种状态下的缺陷数量，需求数量等，以使其对正在开发的软件有所了解。 并非均等地创建它们，因此不应将它们视为相等，这并不重要 。

争夺控制权

争夺控制权似乎是人类的天性，并且在人类之间的许多关系中很常见。 当每个小组试图施加控制权时，紧张感可能会增加开发人员与非开发人员之间的关系。 许多非开发人员，尤其是如果他们对开发或编码不太了解的人，会讨厌无法控制添加到基准中的内容。 许多开发人员不满被告知他们可以将基准投入何处，特别是当他们坚信非开发人员会随意打出电话而又缺乏足够的知识和背景进行该调用时，尤其如此。

当双方都是“万事通”时，控制之战将变得非常艰巨。 当任何一方确信自己的优势时，很难让任何一方屈服。 开发人员经常觉得自己的经验和技能最能使他们有资格做出所有软件决策，而客户，经理和其他人常常觉得自己的职位对他们也一样。

编码：是为工匠还是为技术员工作？

优秀的软件开发经理认识到，软件开发是一项极富创造力和挑战性的工作，并需要以其工作为荣的熟练人员。 其他不太好的软件经理认为软件开发是技术人员的工作。 对他们来说，软件开发人员只不过是说一种编程语言的打字员。 对于这些管理人员，应该并且可以由最低薪水的软件开发人员实施一套足够好的要求和高级设计。 某些软件开发比其他软件开发更容易，但是此时简单的技术人员工作已被自动化和代码生成大量取代。

也许是技术人员对工匠的看法解释了为什么非开发人员更倾向于认为所有开发人员都是即插即用的，而经验丰富的开发人员则意识到，任意两个开发人员之间在技能和知识上可能存在很大差异。

赞赏软件开发的细微差别

对于开发人员而言，通常并不需要很长的时间就可以意识到软件开发中相对较少的内容是干脆的。 软件开发通常具有大量的创造力，并且需要做出许多判断。 我们有时称这些设计决策或架构折衷。 不幸的是，许多不是软件开发人员的人并不了解软件开发涉及细微之处和微妙之处，甚至涉及大量的创造力。 不缺少这些细微的阴影，不足为奇的是，许多没有开发经验的人只能在极端情况下思考（技术“ A”很好，必须一直被所有人使用，否则技术“ A”总是错误的，并且无论如何都应绝对避免）。 新开发人员也经常表现出这种特征，但是经验通常会教给他们，他们更愿意根据特定的情况来判断方法和技术，并减少归纳和假设的数量。

开发人员与其他开发人员并没有太大不同，但是

神话般的月刊是软件开发和软件开发管理领域中最常被引用的书籍之一。 在工作的早期（第一版序言的第一句话）就提到了其中的一句话：“在许多方面，管理大型计算机编程项目就像管理任何其他大型企业一样，其方式比大多数程序员认为的要多。 但是在许多其他方面，它是不同的–比大多数专业经理所期望的更多。” 开发商与非开发商经理之间的阻抗失配的关键解释之一似乎在于这一深刻的陈述。 作为一个整体，开发人员可能应该更愿意购买某些行之有效的“传统”管理方法，但是管理人员需要避免陷入一种陷阱，即认为最新业务管理书中概述的策略足以管理软件开发人员。

关于 什么最 有价值的意见

软件开发人员也是人。 因此，他们确实表现出与其他人相同的行为。 但是，由于软件开发人员中那些陈规定型特征的出现频率很高，因此存在一些不完全没有一定基础的软件开发人员总体刻板印象。 在软件开发社区中，就政治见解，利益等方面存在着很大的差异，但是最重要的思想（质量设计和代码，值得骄傲的工作等）在整个行业中是相当普遍的。 。 另一方面，软件开发人员（类似于各种工程学科的工程师）似乎过于琐碎了尊重底线的需要。 他们常常无法理解，出于非技术原因，何时选择了可以说是适当的但不是“最佳”或“完美”的解决方案，而不是选择了更好的技术解决方案。

结论

我们软件开发社区中的人往往一直在处理不匹配问题。 我们通常会花费大量的精力和时间来“粘合”在一起的东西，而这些东西不一定是设计在一起的。 尽管我们拥有使所有不一致的部分一起工作的所有技术经验，但我们似乎仍然很难解决所有问题中最困难和最重要的不匹配：软件开发人员与非软件开发人员之间的不匹配 。 尽管由此带来了一些积极的影响（例如，对“科学博览会项目”的制衡），但由于阻抗不匹配而导致了严重的功能障碍，焦虑，不满和士气低落。

参考：来自JCG合作伙伴 Dustin Marx的“开发人员/非开发人员阻抗不匹配” ，位于Inspired by Actual Events博客上。

翻译自: https://www.javacodegeeks.com/2012/05/developernon-developer-impedance.html