企业可读性是一种艺术，它使那些没有直接参与的人更容易理解任务及其结果。我将帮助你了解为什么这是一件需要注意的重要事情，以及如何利用它来帮助你的职业生涯。
简介
首先，一些定义。我使用 "公司 "和 "企业 "来指任何商业组织。有多大并不重要，但一般来说，当组织规模超过邓巴数Dunbar --大约150人时，就会发生刻意的可读性努力。
我使用的 "可读性 "是詹姆斯-C-斯科特（James C. Scott）在《像国家一样看待》中使用的，它被用作描述努力让那些参与国家管理的人（行政人员、统治者等）对一个复杂和混乱的世界有意义。
具有一定规模的公司的行为很像（早期现代）国家--一般来说，行政领导团队可以被看作是国家元首，也许董事会是神职人员的高级成员，然后是一个生产某种形式的产出以发展业务的封地网络。
因此，他们采用了类似的国家技术--员工被简化为 "资源 "或 "首脑"，通过抽象的报告和仪表盘来感知世界，类似于地图和棋盘。一些企业领导人甚至似乎从为统治者准备的文学作品中获得灵感，如《普林西比》和《孙子兵法》。
重要的是要记住这些努力并不是为了让你这个工程师直接受益。它们的存在是为了使工作更容易管理，并使工作在产业链上可见，以便公司负责人知道他们雇用的人正在为他们的企业做什么。
这些可读性的努力，尽管对管理者来说是有用的，但往往对从事这项工作的人产生负面影响。我们将探讨 "可读性陷阱"，然后探讨如何将这些努力的负面影响降到最低。
可读性陷阱
在《像国家一样看》中，斯科特给了我们这个强有力的声明。
每一个测量行为都是以权力关系的游戏为标志的行为。
权力是企业环境中所有测量行为的核心，即使其意图是好的。这就是可读性陷阱--一旦某些东西被量化，权力就被赋予了测量者。衡量标准往往成为目标（并违反古德哈特法则），但即使是非目标也可以被用于组织内公开和隐蔽的强制和控制方法。
这方面的一个很好的例子是使用 "开发人员生产力指标 "来帮助管理人员了解工程产出。我对 "代码覆盖率 "这个指标特别有意见。表面上看，经理能够看到代码覆盖率指标，使他们能够了解他们的工程师生产的软件是如何经过测试的，而不需要了解代码本身。当然，这很快就变得毫无用处了--100%的代码覆盖率毫无意义，因为 "测试 "可能只是名义上的，只是为了满足衡量标准而创建的，没有提供真正的价值。
沿着同样的思路，在Kain和Baigent的《地籍图》中有这样一段简短的摘录。
地图是一种控制工具，它既反映又巩固了委托人的权力。
斯科特提供了另一个洞察力，说明为什么陷阱会对工程团队造成伤害。
对官员来说很简单的东西对大多数耕种者来说却很神秘。
这句话的背景是围绕法国殖民时代的越南，在那里，文盲的农村人口和高文盲的行政阶层所产生的不对称性使后者巩固了巨大的权力。在我们的软件工程背景下，我们必须理解，行政人员正在玩一个不同的游戏，而工程师们对游戏规则的理解却很差。
这种不对称性不仅导致了权力的不平衡，也导致了挫折感。我曾在许多团队中经常听到 "为什么我们要<在x中更新/在y中请求批准/在z中提供变更收据>"的反驳。由于某些原因，企业的可读性工具对于那些与之互动的非管理员的人来说往往有很差的用户体验。
然而，这个陷阱是双向的。一个组织中的管理员阶层会很快陷入一种模式，认为地图就是领土，只能通过可读性工具的镜头来感知工作。
关于 "数据驱动 "的工具，人们已经说了很多，但是却对工程师遇到问题空间的内在复杂性和变化无常视而不见，而且可能导致不正当的激励（见：上面的代码覆盖率指标）。
操作陷阱
遗憾的是，这个陷阱似乎无法逃脱。不易读性提供了更多的自主权，但也付出了沉重的代价--被指责为 "难缠 "或 "没有团队精神"，或者更糟糕的是，违反了工作过程必须易读的监管要求（见：SOX、SOC、ISO和许多其他TLA）。
虽然权力主要在于管理员阶层，但工程师们并不是无能为力。通过参与可读性工作，他们有机会使这些措施为他们所用。例如，确保有影响力的工作对能够决定晋升的小组有适当的可见性是很重要的。同样，通过使开发新系统、维护现有系统等的所有努力变得清晰可见，就更容易提出增加人手的理由。
在工程方面，像SLOs这样的努力导致了系统可观察性的增加，这与可读性项目相吻合。这些对工程师和管理员都有好处，没有特别的权力不对称--当然，管理员可以很容易地把这样的目标变成一个粗糙的工具，按照他们认为合适的方式来塑造组织。
从这些可读性的努力中寻求管理人和工程师的共同利益，是使这个陷阱对所有参与者都有效的主要方法，并确保每个人都能参与其中。
总结
企业的可读性工作通常都是出于好意，以使复杂的软件开发世界变得合理。
就像所有这些抽象化的尝试一样，它们导致了权力的转移，这可能会对自治团体造成困扰，在极端的情况下，会对这些团体的效率造成伤害。
通过确保双方的努力，我们可以减少挫折感，并减少导致潜在的不公平权力平衡的不对称性。