商業可讀 DSL

DSL 能否讓業務人員編寫軟體規則，而無需程式設計師參與？

當人們談論 DSL 時，通常會提出業務人員自行編寫程式碼的問題。我喜歡將 COBOL 推論套用於這種思維方式。也就是說，COBOL 最初的目標之一是讓人們在沒有程式設計師的情況下編寫軟體，而我們知道結果如何。因此，當任何計畫都是為了在沒有程式設計師的情況下編寫程式碼時，我必須詢問這次有什麼特別之處，可以在 COBOL（以及許多其他事物）失敗的地方取得成功。

我確實認為程式設計涉及一種特定的思維模式，一種能夠對機器發出精確指令，以及能夠架構大量此類指令以建立可理解程式的能力。這種天賦，以及理解和建構程式所需的時，就是程式設計長期以來一直抵抗中介的原因。這也是許多「非程式設計」環境最終培養出自己的一群實際程式設計師的原因。

話雖如此，我確實認為 DSL 最大的潛在好處在於業務人員直接參與 DSL 程式碼的編寫。然而，關鍵在於讓 DSL 成為業務可讀，而不是業務可寫。如果業務人員能夠查看 DSL 程式碼並理解它，那麼我們就可以在軟體開發和基礎領域之間建立一個深入而豐富的溝通管道。由於這是軟體中的絕望的深淵，因此如果 DSL 能夠幫助解決這個問題，它們將具有很高的價值。

透過可供企業理解的 DSL，程式設計師撰寫程式碼，但他們會經常向能理解其意義的企業人員展示該程式碼。這些客戶接著可以進行變更，也許草擬部分程式碼，但讓程式碼穩固、進行除錯和測試的，還是程式設計師。

這並不是說可供企業撰寫的 DSL 沒有好處。的確，幾年前，我的幾位同事建置了一個包含此功能的系統，而企業非常讚賞。只是，建立一個完善的編輯環境、有意義的錯誤訊息、除錯和測試工具，會大幅提高成本。

雖然我很快就能使用 COBOL 推論來批評許多試圖避免程式設計師的工具，但我也不得不承認一個重大的例外：試算表。令人驚訝的是，全世界有許多大型企業功能都是靠 Excel 執行。認真的程式設計師往往會對這些功能嗤之以鼻，但我們需要更認真看待它們，並試著了解它們為何如此成功。這肯定是一部分原因，驅使許多 LanguageWorkbench 開發人員提供不同的軟體開發願景。