PDMS-AVEVA-E3D二次開發(fā)教程20收官——PDMS/E3D 二次開發(fā)工具箱與交付體系版本與事實聲明產品錨點AVEVA E3D Design 為官方現(xiàn)名發(fā)布錨點 3.1.4.0 / 3.1.5.0當前版本以官方發(fā)布說明為準AVEVA PDMS自 2024 年 4 月 1 日起停止銷售與技術支持。官方專設 “Minimising Problems for Future Upgrades” 與 “Serious Warning About Software Customisation” 兩節(jié)——軟件定制會影響未來升級這是本篇架構設計的根本約束而非免責聲明。本篇不引入任何新語法全部代碼是前 19 篇已給出來源的標準 PowerShell / PML 組織方式。示例目錄名、版本號、清單條目均為示例性數(shù)據(jù)。一句話結論一個可維護的 E3D 二次開發(fā)工具箱由五層構成——環(huán)境探測層先說清我在哪跑、數(shù)據(jù)訪問層只讀優(yōu)先、規(guī)則層規(guī)則是數(shù)據(jù)不是代碼、批處理層冪等與賬本、交付層產出物必須自證判斷一套工具箱好不好不看功能多少只看三件事能不能整體卸載、能不能一鍵回歸、能不能交給第二個人維護。〇、認知問題Q119 篇寫下來的函數(shù)與腳本憑什么能組成為一個工具箱而不是一堆文件Q2五層架構里為什么環(huán)境探測層必須排在最下面而不是最上面Q3PDMS 已停售停支持遷移期為什么還要做雙軌雙軌怎么做才不失控Q4回歸測試要測什么測多少才夠Q5一份交付清單到底要交什么才能讓接手的人不罵人一、機制解析1.1 五層架構每一層解決一類會變化的東西工具箱的本質不是功能集合而是把會變化的東西分層隔離。五層的劃法如下┌─────────────────────────────────────────────────────────────────┐ │ ⑤ 交付層 Delivery │ │ 圖紙目錄/快照發(fā)布/DQ 報告/交接報告/產出物核驗 │ │ 會變的交付格式、命名規(guī)則、接收方要求 │ ├─────────────────────────────────────────────────────────────────┤ │ ④ 批處理層 Batch │ │ 作業(yè)編排/冪等/賬本/重試/環(huán)境檢查/進度與中斷 │ │ 會變的調度方式、運行時段、并發(fā)策略 │ ├─────────────────────────────────────────────────────────────────┤ │ ③ 規(guī)則層 Rules │ │ 規(guī)則表(CSV/JSON)/數(shù)據(jù)字典/契約表/清單 │ │ 會變的業(yè)務規(guī)定、閾值、依據(jù)文件 │ ├─────────────────────────────────────────────────────────────────┤ │ ② 數(shù)據(jù)訪問層 Access │ │ 只讀校驗器/范圍裁剪/屬性讀寫/三態(tài)契約/現(xiàn)場保護 │ │ 會變的產品版本、屬性名、導航語法、模塊差異 │ ├─────────────────────────────────────────────────────────────────┤ │ ① 環(huán)境探測層 Probe │ │ 產品與版本/PMLLIB/程序集清點/權限與會話/能力清單 │ │ 會變的安裝位置、部署方式、升級節(jié)奏 │ └─────────────────────────────────────────────────────────────────┘ ▲ 全部層都向上依賴這一層的事實為什么環(huán)境探測層排在最下面而不是最上面因為上面四層的一切判斷都建立在它提供的事實上——數(shù)據(jù)訪問層要問這個屬性名在這個版本上存在嗎第 02、06 篇的ATTLIS規(guī)則層要問這條規(guī)則的依據(jù)文件在哪個版本有效第 17 篇的basis列批處理層要問我連的是哪個庫、有沒有 Claim 權限第 09 篇的四段結構第一段交付層要問產出物對應的產品版本是多少第 18、19 篇的元數(shù)據(jù)文件。排在最下面是對依賴方向的物理表達越靠下越穩(wěn)定、越靠上越易變。第 02 篇的e3d_env_inventory.csv、第 13 篇的dotnet_inventory.csv就是這個地基。1.2 判斷工具箱好壞的三條標準前面 19 篇給了一堆最佳實踐但它們都是局部的。用全局視角看一套工具箱只有三條硬標準標準判據(jù)可操作對應篇章能不能整體卸載每一處加都有對應的減菜單項可移除、工具條 gadget 可移除、命令可 Killing、表單可隱藏、字段可釋放第 08 篇官方 Removing/Killing 類機制能不能一鍵回歸有一條命令跑完全部自檢與驗收輸出通過/未通過清單第 08、17 篇MYCO_LibSelfTest、acceptance.ps1能不能交給第二個人維護規(guī)則在 CSV 里、字典在 JSON 里、依據(jù)有列、版本有函數(shù)、卸載有說明第 16、17、19 篇為什么是這三條而不是功能多不多因為工具箱的壽命取決于這三條。功能多但不可卸載的定制產品升級一次就廢不可回歸的定制第二次改動就沒人敢動不可交接的定制作者離職即失傳。官方那句Minimising Problems for Future Upgrades想說的就是這件事。1.3 遷移期雙軌PDMS 與 E3D Design官方事實AVEVA PDMS 已被 AVEVA E3D Design 取代并自 2024 年 4 月 1 日起停止銷售與技術支持“AVEVA Everything3D is now AVEVA E3D Design”。為什么還要做雙軌因為設計院里的存量項目不會因為產品停售而消失——老項目仍要在原環(huán)境上維護新項目按 E3D Design 建設。工具箱必須同時服務兩者否則會出現(xiàn)老項目沒人管或新項目從零重寫。雙軌的三條控制原則控制的是不要讓它失控而不是不要做原則做法失控的表現(xiàn)要避免差異顯式化代碼里凡涉及兩代差異處用統(tǒng)一注釋標記如-- VER-DIFF: PDMS 12.x / E3D Design并在自檢里輸出當前判定靠人記差異 → 每次都在猜公共部分最大化規(guī)則層、字典層、交付層完全共用它們不依賴產品版本僅數(shù)據(jù)訪問層與探測層分叉上下都復制兩份 → 維護量翻倍單點分叉數(shù)據(jù)訪問層里凡有差異的能力導航、寫屬性、文件 I/O收斂到少數(shù)幾個函數(shù)做版本判定差異散落各處 → 無法說清支持哪些版本關鍵洞察五層里只有 ①② 兩層是產品相關的③④⑤ 三層是工程相關的。所以雙軌的實際成本遠低于直覺——只要 ③④⑤ 不復制雙軌就是可承受的。最佳實踐在工具箱自檢里輸出一行當前環(huán)境判定例如env: familyE3DDesign / version實際版本 / runtimedetected讓這套工具箱在某臺機器上以哪條軌運行成為可見事實。1.4 回歸測試測三層不測全部回歸測試不是把每個函數(shù)都測一遍成本太高、維護不了。只需要測三層層次測什么為什么只測這些冒煙層能否加載、版本函數(shù)能否返回、PMLLIB 是否含本工具箱目錄加載失敗是最常見故障且一秒可判契約層核心函數(shù)的返回契約是否符合三態(tài)前綴、字段數(shù)量與位置契約變化會靜默破壞所有下游解析器端到端層一條最小完整流程選一個小范圍 → 跑檢查 → 產出報告 → 核驗報告它覆蓋了 90% 的集成問題且能自動判定不測的部分單個內部函數(shù)的細節(jié)邏輯、UI 的視覺效果、極端輸入組合。理由這些測試的維護成本高于其收益把有限精力放在契約與端到端上回歸才跑得起來、才會有人跑?；貧w的觸發(fā)時機三條工具箱自身改動后產品升級前后各一次這是最重要的一次用于評估影響面交付前作為交付清單的一個必過項。1.5 交付清單交給接手人的東西第 02 篇講了環(huán)境清單、第 08 篇講了升級自查、第 19 篇講了數(shù)據(jù)發(fā)布。交付清單是把這些清單合并成一份交接包類別交付內容為什么必須交環(huán)境事實環(huán)境探測清單產品/版本/路徑/權限/程序集沒有它接手人不知道在哪跑能力邊界支持的產品代際與版本范圍、明確不支持的場景沒有它接手人會以為什么都能干代碼資產五層目錄、生成物、構建腳本、版本函數(shù)代碼本身配置資產規(guī)則表、數(shù)據(jù)字典、契約表、圖紙清單這是業(yè)務可維護的部分最容易被漏交紀律資產鐵律清單、代碼評審要點、卸載說明沒有它接手人會把工具箱改壞驗證資產回歸腳本、驗收腳本、最近一次回歸結果沒有它接手人不敢動運行資產運行賬本、模型/數(shù)據(jù)臺賬、最近發(fā)布記錄用于追溯上次跑到哪最容易被漏交的是配置資產與紀律資產——因為代碼看得見規(guī)則與規(guī)矩看不見。但恰恰是這兩類決定接手人能不能在三個月后還不罵人。1.6 團隊規(guī)范與評審要點濃縮成一張表20 篇下來團隊規(guī)范其實就這些。把它做成評審時的檢查表#評審提問不通過的表現(xiàn)1這段邏輯會被調用第二次嗎是就寫成函數(shù)業(yè)務邏輯寫在宏里2這段代碼改了!!ce嗎改了就在兩個出口都還原只還原正常出口3屬性名從哪來核對過ATTLIS嗎憑記憶寫屬性名4數(shù)值帶單位嗎裸數(shù)值參與比較5判存在用的是Defined()還是值判空用取值判空0 被誤判6批量腳本報了幾個計數(shù)加起來自洽嗎只返回Success7失敗信息里有沒有該怎么辦只有失敗三個字8這個動作在離線副本上驗證過嗎直接在生產庫首次運行9有沒有對應的卸載路徑只加不減10規(guī)則/閾值/依據(jù)寫在哪業(yè)務能改嗎埋在代碼里11這一段是 PML 該做的嗎第 13 篇五條判據(jù)用 .NET 做界面12用了官方還是臆測的語法網(wǎng)上抄來未核對的寫法第 12 條是元規(guī)則它是前 11 條之所以可靠的保證。官方文檔查不到就標注以官方文檔為準并給出章節(jié)定位——這條紀律比任何一條語法規(guī)則都重要因為語法會變、會被記錯而知道去哪查的能力不會。1.7 八條鐵律收官回顧全系列確立的八條鐵律全系列不超過 10 條其余為最佳實踐與經驗法則#鐵律一句話記法1語法只寫官方手冊記載的形態(tài)查不到就指向官方章節(jié)寧缺毋編2單位與屬性必顯式數(shù)值必帶單位3先探測環(huán)境再運行先說清在哪跑4破壞性操作先離線驗證副本先行5對接必聲明邊界與版本寫清誰算哪段6PDMS 與 E3D Design 差異必須顯式標注代際差異不許含糊7不混寫產品能力無PML 內嵌 Python不把 APS 能力安到 E3D 上不張冠李戴8示例數(shù)據(jù)必標注示例不等于規(guī)定二、完整代碼與逐行剖析代碼 20-1工具箱目錄骨架結構即架構e3d_devkit/ ├── README.md # 工具箱總覽能力邊界 / 支持版本 / 安裝步驟 / 卸載步驟 ├── CHANGELOG.md # 每個版本改了什么含規(guī)則表變更 ├── 00_env/ # ① 環(huán)境探測層 │ ├── probe_install.ps1 # 安裝與運行時盤點第 01/02 篇 │ ├── pml_lib_census.ps1 # PMLLIB 內容與命名沖突普查第 02 篇 │ ├── asm_identity.ps1 # .NET 程序集身份清點第 13 篇 │ ├── type_census.ps1 # 公開類型清點第 13 篇 │ └── out/ # 探測產物CSV隨交付一起交 ├── 10_pml/ # ② 數(shù)據(jù)訪問層PML │ ├── lib_version.pmlf # 版本函數(shù)第 08 篇 │ ├── lib_selftest.pmlf # 依賴自檢第 08 篇 │ ├── nav_helpers.pmlf # 導航輔助按官方 DBRM2.03.x 實現(xiàn)第 05 篇 │ ├── lint_core.pmlf # 只讀檢查內核第 06/17 篇 │ ├── ifc_export.pmlf # IFC 導出封裝第 12 篇 │ ├── draw_batch.pmlf # 批量導出作業(yè)第 18 篇 │ └── rules.pmlf # 【生成物】由 30_rules 構建勿手改 ├── 20_ui/ # ② 層的界面部分 │ ├── lint_ui.pmlfrm # 表單第 07 篇 │ └── commands.pmlf # 命令定義與裝配/卸載第 08 篇 ├── 30_rules/ # ③ 規(guī)則層業(yè)務可維護 │ ├── rules.csv # 檢查規(guī)則表第 17 篇 │ ├── data_dictionary.json # 數(shù)據(jù)字典第 19 篇 │ ├── dq_rules.csv # 數(shù)據(jù)質量規(guī)則第 19 篇 │ ├── draw_manifest.csv # 圖紙清單第 18 篇 │ ├── contract.csv # 跨專業(yè)數(shù)據(jù)契約第 16 篇 │ ├── gen_rules.ps1 # 構建腳本CSV - rules.pmlf第 17 篇 │ └── apply_pml.ps1 # 構建物落盤到 PMLLIB 目錄 提示索引重建 ├── 40_run/ # ④ 批處理層 │ ├── run_lint.ps1 # 檢查作業(yè)入口第 09/17 篇 │ ├── run_draw.ps1 # 出圖作業(yè)入口第 18 篇 │ ├── run_snapshot.ps1 # 快照作業(yè)入口第 19 篇 │ ├── job_ledger.ps1 # 作業(yè)賬本第 09 篇 │ └── verify_outputs.ps1 # 產出物核驗第 09/12/18 篇 ├── 50_deliver/ # ⑤ 交付層 │ ├── gen_index.ps1 # 圖紙目錄生成第 18 篇 │ ├── dq_check.ps1 # 數(shù)據(jù)質量檢查第 19 篇 │ ├── snapshot_diff.ps1 # 快照差分與變更集第 19 篇 │ └── release.ps1 # 打包一次發(fā)布字典快照元數(shù)據(jù)DQ ├── test/ │ ├── smoke.ps1 # 冒煙層回歸第 20 篇 1.4 節(jié) │ ├── contract.ps1 # 契約層回歸 │ ├── e2e.ps1 # 端到端回歸 │ └── acceptance.ps1 # 項目級驗收第 17 篇 └── docs/ ├── 交付清單.md # 本篇 1.5 節(jié)的落地交接包索引 ├── 鐵律與評審要點.md # 本篇 1.6 節(jié)的落地 └── 卸載說明.md # 本篇 1.2 節(jié)第 1 條的落地逐行剖析目錄編號00_/10_/20_…直接對應五層順序編號讓依賴方向在文件管理器的排序里就可讀——排在上面的層依賴排在下層的事實。這是結構即架構的最省事表達方式。00_env/out/的探測產物隨交付一起交這是 1.5 節(jié)環(huán)境事實必須是交付物的落地。很多團隊把探測腳本交了、產物留在自己機器上接手人得先跑一遍才知道情況——而這恰恰是最容易卡住的地方。10_pml/rules.pmlf明確標注為生成物且構建腳本在30_rules/生成物與它的源放在不同層源在規(guī)則層產物在數(shù)據(jù)訪問層。這個安排逼著人思考我改的是源還是產物從目錄結構上防止手改生成物第 17 篇報錯 3-2。docs/卸載說明.md是獨立文件卸載路徑不能只寫在代碼注釋里。它是能不能整體卸載這條標準的物理載體1.2 節(jié)。一個沒有卸載說明的定制在產品升級時的處理方式通常是不管它——然后升級出問題。test/分四個腳本對應四個層級冒煙/契約/端到端/驗收分層讓回歸可以只跑需要的部分改了一個 PML 函數(shù)跑冒煙契約改了端到端流程跑全部。一次要跑十分鐘的回歸很快就不會有人跑。代碼 20-2一鍵回歸PowerShell可運行# -*- coding: utf-8 -*-# regress.ps1 —— 工具箱一鍵回歸冒煙 / 契約 / 端到端 / 驗收 設計要點 * 分層執(zhí)行失敗即匯總不中斷最后給出總判定 * 每一層都有可自動判定的成功標準不允許看起來正常 * 結果同時輸出給人看屏幕與給機器看regress_result.csv 用法 .\regress.ps1 -KitRoot . -Level all #param([Parameter(Mandatory$true)][string]$KitRoot,[ValidateSet(smoke,contract,e2e,all)][string]$Levelall,[string]$OutDir.\test\out)$ErrorActionPreferenceSilentlyContinueif(-not(Test-Path-LiteralPath$OutDir)){New-Item-ItemType Directory-Path$OutDir|Out-Null}$resultsNew-ObjectSystem.Collections.Generic.List[object]functionRun-Layer{param([string]$Name,[string]$Script,[int]$ExpectedExit)$rec[pscustomobject]{layer $Name;script $Script;ran $falseexit_code ;verdict ;detail ;seconds 0}$pJoin-Path$KitRoot$Scriptif(-not(Test-Path-LiteralPath$p)){$rec.verdict SKIP_NO_SCRIPT;$rec.detail 未提供$Script$results.Add($rec)|Out-NullWrite-Host([{0}] 跳過腳本不存在-f$Name)return}$sw[System.Diagnostics.Stopwatch]::StartNew()$p-KitRoot$KitRoot-OutDir$OutDir|Out-Host$code$LASTEXITCODE$sw.Stop()$rec.ran $true$rec.exit_code $code$rec.seconds [math]::Round($sw.Elapsed.TotalSeconds,1)$rec.verdict if($code-eq$ExpectedExit){PASS}else{FAIL}$rec.detail if($code-eq$ExpectedExit){}else{(期望退出碼 {0}實際 {1}-f$ExpectedExit,$code)}$results.Add($rec)|Out-NullWrite-Host([{0}] {1}退出碼 {2}耗時 {3}s-f$Name,$rec.verdict,$code,$rec.seconds)}# ---- 冒煙層0 表示工具箱可加載且環(huán)境可判定 ----if($Level-in(smoke,all)){Run-Layersmoketest\smoke.ps10}# ---- 契約層0 表示全部返回契約符合 ----if($Level-in(contract,all)){Run-Layercontracttest\contract.ps10}# ---- 端到端層0 表示最小完整流程產出且核驗通過 ----if($Level-in(e2e,all)){Run-Layere2etest\e2e.ps10}# ---- 驗收層0 表示項目驗收標準全部滿足 ----if($Level-eqall){Run-Layeracceptancetest\acceptance.ps10}$results|Export-Csv-LiteralPath(Join-Path$OutDirregress_result.csv)-NoTypeInformation-Encoding UTF8$failed ($results|Where-Object{$_.verdict-eqFAIL})$skipped ($results|Where-Object{$_.verdict-eqSKIP_NO_SCRIPT})Write-HostWrite-Host(回歸結果通過 {0} / 失敗 {1} / 跳過 {2}-f (($results|Where-Object{$_.verdict-eqPASS}).Count),$failed.Count,$skipped.Count)if($failed.Count-gt0){Write-Host失敗項$failed|ForEach-Object{Write-Host( - {0}: {1}-f$_.layer,$_.detail)}Write-Host★ 回歸未通過禁止交付也禁止在原環(huán)境做進一步修改。exit1}if($skipped.Count-gt0){Write-Host★ 有層被跳過腳本缺失當前結果不能作為交付依據(jù)。exit3}Write-Host回歸全部通過。請把 regress_result.csv 連同交付包一起交接。exit0逐行剖析“失敗即匯總、不中斷”Run-Layer不拋異常也不 return所有層都跑完再匯總。理由回歸的價值在于一次看到全部問題如果第一層失敗就中斷你修完再跑再發(fā)現(xiàn)第二層也壞了——迭代次數(shù)翻倍。每層都有一個顯式的期望退出碼$ExpectedExit把什么叫成功寫成參數(shù)。這是本系列從頭到尾的紀律在回歸層的體現(xiàn)——看起來正常不是判定標準。SKIP_NO_SCRIPT是一個獨立結論而不是 PASS腳本缺失時絕不能算通過。并且專門打印一句當前結果不能作為交付依據(jù)退出碼 3。這是沒測與測過沒問題的區(qū)分——這個區(qū)分在本系列里出現(xiàn)了至少四次第 09 篇 STALE、第 11 篇假空碰撞、第 18 篇 STALE、第 19 篇無變更它是全系列最一致的一條思維習慣。耗時被記錄進結果表seconds列用于監(jiān)控回歸是否在變得太慢。當端到端從 30 秒漲到 10 分鐘時就是該拆分的時候了——否則回歸會先被跳過然后被遺忘。regress_result.csv隨交付包交接1.5 節(jié)驗證資產它是這套工具箱在某臺機器上是好的這一論斷的證據(jù)。結尾那句禁止交付也禁止在原環(huán)境做進一步修改第二條同樣重要——回歸失敗時繼續(xù)改代碼會讓下次回歸也說不清是新改動引入的還是原本就壞的。代碼 20-3交付清單Markdown交接包的索引# 交付清單 · e3d_devkit 版本號 ## A 環(huán)境事實必須交 - [ ] 00_env/out/probe_install.csv安裝與運行時 - [ ] 00_env/out/pml_lib_census.csvPMLLIB 與命名沖突 - [ ] 00_env/out/asm_identity.csv.NET 程序集身份如啟用 .NET 通道 - [ ] 一行結論產品代際與版本 / 模塊 / 權限范圍 ## B 能力邊界必須交 - [ ] 支持的產品與版本范圍填寫 - [ ] 明確不支持逐條填寫 - [ ] 已確認的官方章節(jié)引用清單PML/DBRM/DRAW/IFC 等 ## C 代碼資產 - [ ] 五層目錄10_pml / 20_ui / 30_rules / 40_run / 50_deliver - [ ] 生成物清單及其源rules.pmlf ← rules.csv - [ ] 版本函數(shù)輸出!!MYCO_LibVersion() 實際返回值 ## D 配置資產最易漏交 - [ ] rules.csv / dq_rules.csv / draw_manifest.csv / contract.csv / data_dictionary.json - [ ] 每份配置的負責人 依據(jù)文件 最近變更日期 ## E 紀律資產最易漏交 - [ ] 鐵律與評審要點12 條提問 - [ ] 卸載說明每一處加對應的減 - [ ] 代際差異標注約定-- VER-DIFF: ## F 驗證資產 - [ ] test/regress_result.csv最近一次回歸 - [ ] test/acceptance 結果 - [ ] 已知未通過項及其原因與計劃 ## G 運行資產 - [ ] jobs_ledger.csv作業(yè)賬本 - [ ] model_ledger.csv模型/數(shù)據(jù)臺賬如啟用模型 - [ ] 最近一次發(fā)布記錄發(fā)布版本號 時間 內容逐項剖析A、B 兩組放在最前因為它們是接手人第一天最需要的東西先知道在哪跑、能跑到什么程度代碼才有意義。D、E 兩組標注最易漏交1.5 節(jié)。這是把經驗寫成流程的形態(tài)——漏交這兩組的原因不是疏忽而是代碼看得見、規(guī)則看不見的認知偏差。標注出來評審時就會被專門檢查。B 組第 2 條明確不支持是刻意的一份只寫支持什么的說明會誘導過度期待。寫明不支持什么是專業(yè)交付姿態(tài)的一部分。F 組第 3 條已知未通過項及其原因與計劃允許交付有未通過項但不允許未記錄的未通過項。這條讓交付可以推進現(xiàn)實項目里很難全綠同時保留誠實。G 組的最近一次發(fā)布記錄把第 19 篇的發(fā)布版本概念延伸到整個工具箱——接手人應該能一眼看到這個工具最近產出了什么、什么時候。三、常見報錯與排查報錯 3-1產品升級后工具箱部分功能不好使但不知道影響面?，F(xiàn)象升級后故障。根因沒有升級前后的可比基線第 08、13 篇的清單沒有留存。解法升級前后各跑一次環(huán)境探測與回歸用asm_identity.csv程序集身份、type_census.csv公開類型、pml_lib_census.csvPMLLIB 內容做差分把升級評估作為一條固定流程——對應官方 “Minimising Problems for Future Upgrades” 一節(jié)的立場。報錯 3-2想停用某個功能但菜單里刪不掉、命令還在跑。現(xiàn)象卸不干凈。根因只寫了加沒寫減——官方為此專門提供了 Removing Menu Items、Removing Gadgets from a Toolbar、Killing a Command、Hiding Forms when Exiting Applications 等機制第 08 篇但實現(xiàn)時容易只做一半。解法在開發(fā)階段就把卸載路徑作為該功能的一部分實現(xiàn)并在docs/卸載說明.md里逐項列出回歸里加一項卸載后重裝能正常的檢查。報錯 3-3接手人說看不懂這個規(guī)則為什么這么定?，F(xiàn)象無法維護。根因規(guī)則缺basis依據(jù)列或依據(jù)文件沒有被交接。解法規(guī)則表強制basis與owner非空第 17 篇構建腳本已強制交付時把依據(jù)文件設計規(guī)定、等級管理規(guī)定等的編號與版本一起交不必交全文但必須可追溯評審時把依據(jù)能不能查到作為檢查項。報錯 3-4雙軌維護變成兩份代碼各改一遍。現(xiàn)象維護量翻倍。根因把 ③④⑤ 層也復制成了兩份1.3 節(jié)。解法規(guī)則層、字典層、批處理層、交付層完全共用只在數(shù)據(jù)訪問層做單點分叉版本判定收斂到少數(shù)函數(shù)差異用統(tǒng)一標記-- VER-DIFF:顯式化自檢里輸出當前以哪條軌運行。報錯 3-5回歸越來越慢最后被跳過?，F(xiàn)象回歸失效。根因端到端層把全量模型當測試范圍或者把 UI 相關的檢查都塞了進來。解法端到端用一個極小范圍幾十個元素做冒煙式的全流程驗證只測三層1.4 節(jié)記錄每層耗時代碼 20-2 的seconds列并在超過閾值時告警把回歸必須能在幾分鐘內跑完作為架構約束而不是愿望。四、動手練習練習 1骨架落地按代碼 20-1 建立目錄骨架把前 19 篇你實際完成的腳本按層歸位。判定標準五層目錄都存在且非空30_rules/rules.pmlf被明確標注為生成物docs/下三個文件存在哪怕是初稿。歸位過程中若發(fā)現(xiàn)某個腳本不知道該放哪層把它記下來——這正是你架構還沒想清的地方。練習 2一鍵回歸實現(xiàn)test/smoke.ps1、test/contract.ps1、test/e2e.ps1三個最小版本每個只要 5~20 行能做出一項可自動判定的檢查即可然后用代碼 20-2 跑一次。判定標準三層都執(zhí)行且退出碼符合預期regress_result.csv含layer / exit_code / verdict / seconds四列故意讓契約層失敗改掉一個契約前綴總判定必須為失敗且退出碼為 1。練習 3卸載演練按docs/卸載說明.md完整卸載工具箱移除菜單項、移除工具條 gadget、Killing 命令、隱藏表單然后重新安裝。判定標準卸載后產品原有功能不受影響用任一原有菜單命令驗證重新安裝后工具箱功能全部恢復正常跑一次回歸。兩次操作都要在筆記里記錄實際步驟——卸載說明寫不下去的地方就是卸載實現(xiàn)不完整的地方。練習 4交付清單按代碼 20-3 填一份完整清單A~G 七組。判定標準七組全部有勾選項D、E 組逐項填寫不許寫見代碼F 組注明最近一次回歸的時間與結果G 組包含最近一次發(fā)布記錄。填完后請一名未參與開發(fā)的同事按清單在另一臺機器上只看清單復現(xiàn)一次工具箱的安裝與運行記錄他卡住的每一步。思考題無標準答案為什么能不能交給第二個人維護是判斷工具箱好壞的最終標準而不是功能是否強大驗證要點① 一個功能強大但只有作者能改的工具在作者調崗后的實際處境② 規(guī)則在 CSV、依據(jù)有列、版本有函數(shù)、卸載有說明這四件事分別降低了接手人的哪一類成本③ 如果你現(xiàn)在要交接自己寫的工具最可能被漏交的是哪一類資產對照 20-3 清單自檢。五、小結與全系列收束工具箱的本質是把會變化的東西分層隔離環(huán)境探測層越穩(wěn)定越靠下、數(shù)據(jù)訪問層、規(guī)則層、批處理層、交付層。判斷它好不好只看三條——能不能整體卸載、能不能一鍵回歸、能不能交給第二個人維護。PDMS 已于 2024 年 4 月 1 日停售停支持雙軌的現(xiàn)實成本遠低于直覺因為五層里只有數(shù)據(jù)訪問與探測兩層是產品相關的控制雙軌失控靠三條差異顯式化、公共部分最大化、單點分叉?；貧w只測三層冒煙、契約、端到端并堅持沒測 ≠ 測過沒問題。交付清單七組里配置資產與紀律資產最容易漏交也最決定接手人三個月后是否罵人。全系列回顧三十句三維工廠設計的交付物全部源自模型所以模型側的規(guī)范化會被交付物放大第 01 篇PML 只有兩條官方通道PML 與 .NET APIPML 的能被找到由搜索路徑與索引決定第 02 篇代碼形態(tài)三層遞進、判據(jù)是會不會被調用第二次第 03 篇表達式有類型、單位是語言層面的事、數(shù)組可稀疏且無負下標第 04 篇數(shù)據(jù)是以 WORLD 為根的樹!!CE是會話狀態(tài)必須保護現(xiàn)場第 05 篇屬性分標準/UDA/偽屬性ATTLIS 是區(qū)分沒填與寫錯的唯一手段第 06 篇gadget 不支持自定義成員所以界面必須與邏輯分層第 07 篇每一處加都要有減第 08 篇冪等判據(jù)要放模型里產出物核驗要能識別 STALE第 09 篇目錄數(shù)據(jù)只存一份所以對賬只做待核對清單第 10 篇碰撞判定取決于 OBST 與容差規(guī)則類代碼的頭號陷阱是 RESULT 默認值寫反第 11 篇IFC 導出有完全可編程的官方 PML 對象第 12 篇.NET 通道的正確起點是反射清點而非猜測第 13 篇PMLNETCALLABLE 讓特征契約成為接口第 14 篇接口成功不等于數(shù)據(jù)正確日志里的假設才是真憑據(jù)第 15 篇雙向同步必須先定主屬側第 16 篇只讀內核加外部規(guī)則表是檢查工具的正確形態(tài)第 17 篇圖紙目錄必須由核驗結果生成第 18 篇數(shù)據(jù)字典先行、快照不可變、變更集必須能重建第 19 篇而最后的最后——查不到就標注以官方文檔為準絕不編造。本篇認知問題回顯FAQQ1一堆腳本憑什么能組成工具箱A靠分層。把會變化的東西按穩(wěn)定性分層隔離環(huán)境探測層安裝位置、部署方式、升級節(jié)奏會變、數(shù)據(jù)訪問層產品版本、屬性名、導航語法會變、規(guī)則層業(yè)務規(guī)定與閾值會變、批處理層調度與并發(fā)策略會變、交付層格式與接收方要求會變。越靠下越穩(wěn)定上層依賴下層提供的事實因此結構本身表達了依賴方向。Q2為什么環(huán)境探測層排在最下面A因為上面四層的一切判斷都建立在它提供的事實上數(shù)據(jù)訪問層要確認屬性名是否存在、規(guī)則層要確認依據(jù)文件的版本、批處理層要知道連接了哪個庫與權限范圍、交付層要記錄產出物對應的產品版本。環(huán)境探測清單如 probe_install.csv、pml_lib_census.csv、asm_identity.csv是工具箱的地基而且必須作為交付物隨包交接不能只交腳本。Q3PDMS 已停售停支持為什么還要做雙軌A因為存量項目不會因產品停售而消失老項目仍在原環(huán)境維護、新項目按 E3D Design 建設。雙軌的實際成本遠低于直覺五層里只有環(huán)境探測層與數(shù)據(jù)訪問層是產品相關的規(guī)則層、批處理層與交付層完全共用。控制雙軌失控靠三條原則差異顯式化統(tǒng)一標記并讓自檢輸出當前判定、公共部分最大化上下三層不復制、單點分叉差異收斂到少數(shù)函數(shù)。Q4回歸測試要測什么、測多少A只測三層冒煙層能否加載、版本函數(shù)能否返回、PMLLIB 是否含本工具箱目錄、契約層核心函數(shù)的返回契約是否符合三態(tài)前綴與字段位置、端到端層一條最小完整流程選小范圍、跑檢查、產出報告、核驗報告。不測內部函數(shù)細節(jié)邏輯、UI 視覺效果與極端輸入組合因為維護成本高于收益?；貧w觸發(fā)時機是工具箱改動后、產品升級前后各一次、以及交付前。Q5交付清單要交什么才讓接手人不罵人A七組環(huán)境事實、能力邊界含明確的不支持清單、代碼資產、配置資產規(guī)則表、字典、清單、契約——最易漏交、紀律資產鐵律與評審要點、卸載說明——最易漏交、驗證資產最近一次回歸結果與已知未通過項、運行資產作業(yè)賬本、模型臺賬、最近發(fā)布記錄。判斷標準是接手人能否只看清單在另一臺機器上完成安裝與運行。