腳本：一般向上兼容幾乎每個版本（自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年的啟動有一些壓縮，而且技術軌道已經組織好了。因此，我們將找到另一種方式來處理此問題。以後再說。
回复：腳本：一般向上兼容幾個版本之前，我們開始在腳本課程中添加明確的“最佳實踐”建議。我們會在每次修訂中繼續擴展和完善這些建議。我們得到學生的積極反饋。好吧，至少是從那些不急於破解的學生那裡。
