使用映射使 JavaScript 对象成员值更具可读性答案

【问题标题】：Making JavaScript object member values more readable with a map使用映射使 JavaScript 对象成员值更具可读性
【发布时间】：2010-12-13 01:45:25
【问题描述】：

所以我有这个 Omniture 对象。它被称为 s。

在 s 内部，我们跟踪“props”和“eVariables”内部的一堆信息。

s.prop5  = 'foo'
s.prop22 = 'baz'
s.var6   = 'bar'

我们选择分配哪些 prop 变量和哪些 eva 取决于我们正在跟踪的页面。例如，在主页上，我们可能希望跟踪 prop5、prop6 和 evar2，但在注册页面上，我们可能希望跟踪 prop4、prop5、prop9、prop10、evar4、evar5。因人而异。

每个变量和每个道具都代表某种关键分析信息。

现在，即使这个解决方案并不理想，因为 prop#s 可以全部混合在一起，我们确实有一个内部保存的主列表，解释哪个变量代表什么。

prop5 表示“页面名称”

prop6 表示“页面类别”

（等等）

现在，这很好，并且运行良好，但我们经常必须将代码传递给第三方，以便他们自己分配值。我们可能让第 3 方创建一个页面，并且我们想对其进行分析，但我们需要他们能够获得适当的信息来进行跟踪。为了使其更具可读性，我们正在考虑实现一些映射代码。

companyName.pageName = 'This is the page name'
companyName.contentType = 'This is the content type'
companyName.campaignId  = 'This is the campaign ID'

这更具可读性。然后，我们将遍历“companyName”对象，并在适当的地方将每个值分配回“s”。

你们怎么看？这是一个好习惯吗？

【问题讨论】：

要添加的另一件事 - 与它引入的错误机会相比，这是否值得？
相对于人们不得不查看列表来确定“prop5”表示“pageName”而导致的错误机会？ ;-)

标签： javascript mapping analytics

【解决方案1】：

老实说，我不明白您为什么首先要使用神秘的属性名称。为什么不在内部也使用您将给第 3 方的名称。这不是让你的生活更轻松吗？

【讨论】：

+1。完全没有理由使用这种难以理解的名称。对“props”和“eVariables”（无论它们可能是什么）的引用表明，这种做法与生成数据在不相关系统的数据结构中具有哪些类型的表示相关，而不是那些数据表示我>。在那里获得一些语义:-)
哦，我多么希望这是可能的！不幸的是，这不是我们的代码，而是最近被 Adobe 收购的分析公司 Omniture。我们最终需要使用“s”对象，并且我们需要相应地命名成员变量。我的问题 - 添加抽象层以提高可读性是否值得？
我很欣赏这种热情，但你能详细说明一下吗？似乎好处是可读性，坏处是它引入了另一个引入错误的场合。
我建议使用不同的分析公司，如果这是他们的系统吐出的那种垃圾。如果这是不可能的，你绝对应该在你的系统和他们的 crud 之间创建一个额外的层来提供一些意义（并且，大概，当走另一条路时，把意义去掉）。
omniture 是一个企业级的跟踪和分析工具，几乎所有真正认真对待这类事情的人都会使用它。变量命名不明确的原因是因为您定义了它们的含义。您决定 s.propX 应该代表 xyz 并在 Site Catalyst 中对其进行标记，并且该标签会显示在报告中。然后，您将功能规范文档 (FSD) 放在一起，以记录每个 prop 和 eVar 的含义、应该使用的时间和地点、应该填充的值/格式等。然后您给出FSD 给必要的人。