脚本：一般向上兼容几乎每个版本（自7y开始），我都收到客户打来的电话，告知他们的脚本在新版本中不再起作用。您收到类似的电话吗？
我想知道是否可以对自定义脚本进行更好的向上兼容性检查（而不是内置生成的脚本，我希望我们可以进行此检查）。明确地说，随着软件的自然发展，我不会谈论向后功能（也就是我的JMP 15脚本不能在JMP 13中运行）。但作为消费者/用户，我希望我在JMP 14中编写的脚本仍将在JMP 15中运行。
我知道早期采用者是一种尽早了解并将问题发送到电子邮件列表的方法。但是有一个大问题：用户通常没有时间在早期采用者中进行兼容性检查，尤其是如果有7-9版本的用户则没有。这应该在软件供应商一方完成。这也是大多数时候客户抱怨的地方。“这不是他们的工作”，而且我必须承认我部分同意（对于大多数情况）。
那么，您是否也收到客户的类似投诉？我们目前检查向上兼容性的过程是什么？很高兴在这里收集一些案例和建议可以做什么。（并且可能还会在与相应开发者的启动会议上讨论这个问题-我记得全体会议上的问答环节可以解决这些问题，但我相信最后一次是在3年前-可能只针对2020年的SE吗？）。
谢谢，
马丁
PS：之所以让我成为杰出的，拥有100多个许可证的制造客户，是因为多年来他们考虑从JMP迁移到其他解决方案（甚至是开源），这让他们很不高兴-而且他们多年来确实对JMP友好）。
回复：脚本：一般向上兼容嗨，马丁，
FWIW，我的经验是，缺乏前向兼容性几乎总是与从报表中提取内容以进一步操纵它们有关。您说期望软件“自然进化”是合理的，但是无论是否喜欢，报表结构的更改几乎都是这种愿望的必然结果。我们应该始终不遗余力地向确实大量使用脚本的客户指出这一点。
如您所知，对于“生产”中使用的软件，非常普遍甚至需要在升级阶段“上线”之前对升级的软件进行全面测试的过渡区域。JMP是“只是”台式机软件这一事实可能与该规则相矛盾，但是（如您的消息所示）风险确实存在，我们应该帮助用户在其使用模式要求时以这种方式查看JMP。
简而言之，这种紧张是JMP非常实用的事实的副作用。我认为我们可以并且应该做得更好，以提醒客户注意没有给予重要的JSL代码库良好工业软件工程实践支持的风险和后果。R＆D“可以”提供以独立于报告的方式获取所有必需值的方法，但这并不是我所知道的任何路线图，并且在任何情况下都将消除JSL程序员似乎重视的一些灵活性。高度。
像您一样，我很想听听我们在此方面遇到麻烦的其他示例。。。
干杯，
伊恩
回复：脚本：一般向上兼容嗨，马丁！
TL; DR：
第一点： 版本之间的代码中断通常是因为人们没有遵循JSL最佳实践，也没有防御性地编写脚本。第2点： 客户应负责验证版本之间的任何软件性能（无论是本地开发的还是其他方式）。他们应该像对待其他任何制造工具一样对待它-在将其发布到生产中之前，所有工具都经过了审核。
长版：
只是为了评论 @ian_jmp 制作–大多数情况下，版本之间的代码中断是由于人们没有遵循（或跟上）JSL最佳实践。破坏有效的代码要容易得多，但考虑周全。马克·贝利（Mark Bailey）称其为“防御性脚本”。伊恩（Ian）从现有报告中撤出人员的例子很经典，尤其是如果他们要下标整个显示树。最佳做法是使用轮廓框名称作为本地地标，然后使用下标（因为它们不会经常更改）。
我还遇到了两个实例（人们（包括我自己））构建JSL，该实例依赖于在版本之间进行全面检查的功能。对我来说，JMP 14中对Recode所做的更改破坏了我所维护的插件的一部分。在那种情况下，我做了一些事情，只是使代码正常工作，我为此而被烧死了。另一个（客户）示例是某人在其数据库中使用不符合ODBC的名称。当我们在版本之间实施ODBC时，脚本中断了。在这里有人不遵守标准，他们为此被火烧。得出的结论是，如果客户按照我们编写JSL的最佳实践编写代码，则他们不太可能遇到问题。如果他们这样做，那么JSL会在各个版本之间打断是非常罕见的。我编写的大多数关于防御性脚本的内容都很强大，但是我仍然很明智地检查一切是否正常。我通常会等到最后几个早期采用者版本进行测试（此时，对JMP的更改通常非常稳定）。
伊恩（Ian）也提出了关于在不同版本之间移动的观点。在美国，我们有一些受到严格监管的行业（制药，生物技术，金融以及一些具有军事或国家安全应用的制造业）。这些行业对任何新软件或新版本软件都具有验证要求，这些要求要求用户群记录其已检查软件是否正常运行并在版本之间提供一致的结果。我的其他客户知道他们需要仔细检查版本之间的代码。因此，我认为这确实是该客户（或至少与在那里生成JSL的人员）在公司文化中成熟和纪律的问题。Ian提到的测试工作流程（分期，然后发布到生产中）是我曾经与之合作过的每个行业（在美国，欧盟或亚洲）的标准实践，他们应该比假设的要了解得多。
因此-总结-如果他们的JSL是关键任务，那么他们需要像对待其他生产软件一样对待它，并在将JMP版本投入生产之前验证JMP版本（使用关键任务JSL）。我敢打赌，您的投诉主要来自工程界的一部分，他们对此并不了解。您可以问他们在彻底测试该工具的性能并使其与其他零件匹配之前是否将新设备投入生产，他们会回答“否”。在这一点上，您可以指出软件是一种工具，应该对待一样。
后续思想
如果您遵循JSL最佳做法（使用函数和表达式，作用域，名称空间，大量评论他们的代码等），以便在发生故障（发生故障）时更容易进行调试。 因此，听起来像是有问题的客户有一些格式不正确的脆性JSL，并且随着时间的推移有机地增长了。 它可能遭到了可怕的评论，并且编写它的人已经前进或不知道如何解决它（我称这些为弗兰肯脚本）... 在这种情况下，我建议他们将认识JSL的人员发送到SAS Ed JSL课程，以获取最佳实践的最新知识，然后放开他们以使相关代码现代化，并放置一些SOP来添加相关JSL他们的软件验证测试计划。
回复：脚本：一般向上兼容我同意到目前为止的所有评论。我一直都在看“生产”代码，这太可怕了。我不敢相信它可以在当前版本中使用，更不用说对未来的希望了。这些用户尚未学习如何编写JMP脚本。这不同于一般的计算机编程。这不仅仅是语法。他们只是骇客。（我将“黑客”一词用于崇高礼节。此活动是不同的。）他们不知道自己在做什么。
至于关于阻碍访问报告层的JMP UI更改的评论，许多用户并不练习安全编码。有最小化或消除这些问题的方法，但是它们的方法会产生脆弱的代码。
回复：脚本：一般向上兼容到目前为止，感谢您的评论。我同意您在投入生产之前进行测试以及保存/防御性编码的所有观点（尽管用户可能不喜欢它；））。最终，这是用户和公司使用任何语言的脚本的责任。
但是，我也希望以一种更为批判的观点来推动讨论（-最后，我希望我们充其量能给客户一个共同的信息，以及一个更强大的自动化流程来出售给我们的客户）：
来自一家依赖于该工具所基于的编程语言的软件公司，我感到惊讶的是，我经常知道JSL在各个版本之间都在中断。在我的前世中，我仅遇到了未记录的功能和功能的问题，而没有设置和选项（例如颜色主题以及对象树或方法中的其他内容）的问题。此外，所有功能都被完整记录：可以使用哪些输入和输出，该选项/输入/输出的描述和定义是什么，等等。脚本指南和索引都不是那种。更重要的是，这是基本呼叫，您必须自己了解所有其他可能的选择。
可以说所有未记录的部分都可能更改-这将是一个简单的答案。但是我相信这并不容易。大多数时候，我们至少需要更改“内置功能以下一级”的至少一部分。我们没有提供具体的文档来说明“这是您可以做的”和“其他所有内容均不受支持”（aka现在可以使用，但可能会发生变化）。
编程语言应该具有这样的框架-或者我们说JSL并不是这样的编程语言，并且在我们当前的创建应用程序推广活动中要更加小心，因为它易于构建可再现的代码，但可能不那么可靠对于将来的版本。
我很高兴听到其他人对此有何看法（我承认更多，并以有针对性的观点，再次鼓励潜水员对此主题进行讨论），也可能一个或其他开发人员在当天这样做日基。
回复：脚本：一般向上兼容最后一点很关键-JSL非常强大，但从本质上讲它不是“编程语言”，而是脚本或宏语言。它具有类似于面向对象编程的结构，并且在某种程度上可以以这种方式使用，但是它建立在JMP之上，并且一直旨在使GUI中的任务自动化或扩展GUI。许多人忘记了这一点-这也意味着他们忘记了产品中发生的更改-事情可能会在JSL中中断（特别是如果他们编写的代码不好的话）。我们不应该以C ++等方式谈论JSL。严格来说，即使Python和R与JSL相比，也是更紧密相关的编程语言。也许有些人会感到困惑，因为Excel Macros和VBA使行变得模糊了。但是，很明显，JSL是一种脚本语言，不同于编程语言。
最好，
中号
回复：脚本：一般向上兼容嗨，迈克，
同意，这是一种脚本语言，因此应予以注意。我发现这种讨论很有价值，因为它还突出了一些其他方面，我们应该始终指导人们在开始自动化或编写流程脚本时进行思考。除了JMP JSL培训课程之外，我们是否还有其他有关“防御性”脚本的JMP相关参考资料？
在网络上找到的大多数参考文献都是针对其他语言的，而不是与JMP相关的（尽管您当然也可以使用它们）。Mastering JMP网络广播没有涵盖良好的编程/脚本风格。对于发现演示文稿，可能也是一个有趣的话题吗？
回复：脚本：一般向上兼容我认为这是我们可以改进的领域。关于社区，员工的头脑，书籍和文档，有很多信息，但是我确实没有真正了解的“最佳实践”文档。应该有。我认为，您在该领域遇到的许多担忧可以归结为这一点。
@ian_jmp –也许这将是技术社区在启动时可以做的补充工具。
最好，
中号
回复：脚本：一般向上兼容正如我的答复所暗示的那样，我确实认为这是我们可以做得更好的一个领域，尤其是因为我们通常鼓励将应用程序作为“土地和扩张策略”的“扩张”部分的一部分。
FWIW，我个人认为，除非每个SE都如此精通，否则他们都不应该精通JSL。但是我确实相信，每个SE都应该知道有什么可能，并且伴随着这，好的实践可能看起来像什么，以及不坚持这一点的陷阱。
不幸的是，尽管2020年的启动有一些压缩，而且技术轨道已经组织好了。因此，我们将找到另一种方式来处理此问题。以后再说。
回复：脚本：一般向上兼容我们在几个版本的脚本课程中开始添加明确的“最佳实践”建议。我们会在每次修订中继续扩展和完善这些建议。我们得到学生的积极反馈。好吧，至少是从那些不急于破解的学生那里。
