撰寫關於外部 特定領域語言 的棘手之處之一，在於我踏入的是程式語言社群早已深入探討的領域。程式語言研究一直是學術活動中熱門的領域，我必須承認，我在這個主題上的深度遠不及許多在這領域研究多年的專家。因此，難免會有人質疑，像我這樣的菜鳥憑什麼認為自己可以在這片廣闊的領域中寫書？

不久前，我與一位即將踏上學術生涯的博士後聊天。他向我詢問研究主題，希望我提供意見，因為他覺得我可以告訴他哪些研究具有實用價值。我並沒有提供太多幫助，但我確實提到，最好的方法是花一些時間在業界，了解軟體開發在實際環境中的運作方式，以及哪些問題需要研究。他對此想法的回答令人非常不安。

DSL 是否允許商業人士在不涉及程式設計師的情況下撰寫軟體規則？

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

技術負債 是一個非常有用的概念，但它引發了一個問題：你如何衡量它？遺憾的是，技術負債不像財務負債，因此很難判斷你負債多少（儘管我們似乎最近在衡量財務負債方面遇到了一些問題）。

SOA 噴發者推廣的新服務世界功能之一是註冊表概念。這通常以自動化系統來描述，該系統允許系統在註冊表中自動查找有用的服務，並自行繫結和使用這些服務。

電腦偶爾看起來很聰明，但我並不特別認同這個想法。雖然自動化服務查詢可能會有奇怪的邊緣案例，但我認為在 20 次中會有 22 次是由人類程式設計師在進行查詢。

幾年前，我聽到程式語言人員談論由 Java 造成的語言「核子寒冬」。當時的感覺是，每個人都如此趨同 Java 的運算模型（當時 C# 被視為僅是抄襲），以致於程式語言的創造力消失了。這種感覺現在正在消退，但更重要的解凍可能即將開始——關於資料庫的思考已經凍結了更長的時間，也更深入。

在 2008 年舊金山 QCon 大會上，Rebecca Parsons 和我發表了一場關於敏捷方法如何與企業架構群組合作的演講。目前，敏捷專案團隊和架構群組之間存在許多不信任和衝突。我們深入探討原因，並探索這些群組可以如何合作。

讓我們想像一個 SOA 快樂的美好世界，其中企業的運算需求被分割成許多小型應用程式，這些應用程式彼此提供服務以允許有效協作。某個美好的早晨，消費者服務需要從供應商服務中獲取一些資訊。問題是，儘管供應商服務擁有取得此資訊所需的資料和處理邏輯，但它尚未透過服務介面公開該資訊。供應商有潛在的服務，但實際上尚未存在。

幾年前，我與一位客戶交談，他告訴我他不喜歡我們正在使用的敏捷方法：「在專案這麼早的階段遇到這些困難感覺不對勁」。與他的反應相反，在我看來，這種早期的痛苦是敏捷或任何反覆開發流程的重大優點之一。

奧斯陸是 Microsoft 的一個專案，我們聽聞過許多關於它的消息，但直到本週的 PDC 會議才得知一些細節。我們所知道的是，它與 ModelDrivenSoftwareDevelopment 和 DomainSpecificLanguages 有關。

Microsoft Channel 9 對我、我的同事 Neal Ford 和 Jeffery Snover (PowerShell 的創建者) 的訪談。一般主題是 DSL - Neal 和我剛在 JAOO 2008 完成關於此主題的教學，並與 Jeffery 進行了一些良好的對話。

Thoughtworks 經常舉辦「季度技術簡報會」 - 在我們設有辦公室的城市中針對社群舉辦的公開演講。在多倫多的這場 QTB 中，Scott Shaw 和我討論如何建立 IT 和業務之間的新關係。它說明了我們認為為何應解散 IT 部門的原因。

需求是在開始建置產品之前應該發現的事項。在建置期間或更糟的是，當客戶開始使用您的產品時才發現需求，代價如此昂貴且效率如此低下，我們將假設沒有人會這麼做，並且不再提及它。

-- Suzanne 和 James Robertson

敏捷方法透過打算在建置期間和交付後發現「需求」來違反這個基本假設。但即使如此輕率地忽視上述明智建議，也比不上許多領先網站現在所做的。這些網站透過觀察使用者在網站上的行為來探索需求，並使用這些資訊來產生以下新功能的想法

SOA 能否以敏捷的方法完成？

有人請我為非技術類型的人彙整一份有關 DSL 的討論。也許我讀了太多 Stephen O'Grady 的文章，但我感到一股不可抗拒的衝動，想以問答的方式來完成這項任務。因此，它來了。

語言工作台是我在 2005 年創造的一個術語，用來描述一種新型的軟體開發工具，旨在透過豐富的多重整合 特定領域語言 環境來建置軟體。這些工具距離成為主流還有一段距離，但它們的開發持續進行，而且持續令人感興趣。它們是我認為可以大幅改變程式設計領域的少數事物之一。

模型驅動軟體開發 (MDSD) 和 特定領域語言 (DSL) 之間的關聯是什麼？

在 MDSD 的脈絡中看到「DSL」這個術語相當常見。的確，有些 MDSD 人士似乎認為 DSL 只存在於 MDSD 世界中。我最近為我的書寫了很多關於 DSL 的文章，但到目前為止，我還沒有真正觸及 MDSD 的角度。相反地，我專注於 DSL 在更傳統程式設計中的角色。DSL 存在於文字語言和 MDSD 世界中，並且對兩者都扮演著幾乎相同的角色。

模型驅動軟體開發 (MDSD) 是一種軟體開發風格，認為自己是傳統程式設計風格的替代方案。此方法以建置軟體系統模型為中心。這些模型通常透過圖解設計符號來具體化，UML 是一個選項。這個想法是您使用這些圖表，將您的系統指定給建模工具，然後以傳統程式設計語言產生程式碼。

與任何職業一樣，軟體開發也有一些經常被遺忘的活動，這些活動通常被忽略，但習慣在最不恰當的時刻反撲。其中之一就是資料遷移。

我正在考慮使用敏捷軟體開發，但我應該改用精實軟體開發嗎？

媒體網站最大的問題之一就是處理大量的流量。媒體的重點在於吸引目光，但如果你一次獲得太多點閱，效能低落可能會造成問題並損害你的聲譽。這個問題會因為網路流量的突發性而更加惡化。你可能正在以可控的速度進行，然後突然遇到一個大新聞，導致流量大幅激增。我們的客戶之一在幾分鐘內就看到流量激增了兩個數量級。

在討論特定領域語言（或任何電腦語言）時，一個常見的短語就是雜訊語法。人們可能會說 Ruby 比 Java 的雜訊較少，或外部 DSL 比內部 DSL 的雜訊較少。人們所說的語法雜訊是指不屬於我們真正需要表達內容的額外字元，但它們存在於程式語言定義中。雜訊字元很糟糕，因為它們會模糊我們程式碼的意義，迫使我們費盡心思找出它的作用。

最近我經常和人們討論特定領域語言，而我對外部 DSL 的常見反應是，撰寫解析器很困難。的確，使用 XML 作為外部 DSL 的載體語法的理由之一是「你可以免費取得解析器」。這與我的經驗不符，我認為解析器比大多數人想像的容易撰寫，而且它們並不容易解析 XML。

特定領域語言 (DSL) 的基本概念是一種電腦語言，針對特定類型的問題，而不是針對任何類型的軟體問題的一般用途語言。特定領域語言已經被討論，並且使用時間幾乎和電腦一樣長。

對於第 n 次，而且我確定不是最後一次，我滑入定義實務的對話，將其中一些標籤為「最佳」，而且可能是 C 字（認證）。這是一個熟悉的討論，儘管我們才剛開始，我就可以預測它會如何進行。它是由一個完全合理的渴望推動的，即找出誰是更好的軟體開發人員，以及現有的開發人員如何提升他們的技能。

我的同事吉姆·韋伯以採用輕量級且以業務為導向的方法來整合企業而建立了良好的聲譽。他還以成為一位非常強大且有趣的演講者而聞名。因此，我既緊張又興奮地與他在 QCon 2008 上分享舞台。他結合了一些嚴肅的精華內容，並進行了一場非常有趣的簡報。然後，我們就開始行動了，可能受到演講前一杯啤酒的幫助。我們談論了企業整合的歷史、自認為強大但實際上只是肥胖的系統的增長、敏捷思維的角色、網路的影響（包括吉姆關於網路為何發明的獨特理論），以及這如何導致游擊隊 SOA。

軟體世界中普遍接受的信念之一是有才華的程式設計師生產力更高。由於我們無法衡量生產力，這是一個無法證明的信念，但這似乎是合理的。畢竟，幾乎每個人類的努力都顯示出有些人比其他人更好，通常明顯如此。程式設計師自己也經常觀察到這一點，儘管它似乎總是受到那些認為自己屬於較有才華類別的人的評論。

基於原始碼的程式環境會將系統定義保存在一組原始碼檔案中，這些檔案同時作為系統定義的可編輯和儲存表示。這些原始碼接著會轉換為實際執行的可執行表示。基於原始碼的程式碼是現今最常見的形式，與 投影編輯 相比（我在那裡更詳細地討論這兩者）。

想像一個徵才情境。有兩位候選人都有幾年的經驗。藍方候選人擁有符合你偏好的設計風格的良好廣泛設計技能（就我而言，那會是 DRY、明智地使用模式、TDD、溝通式程式碼等，但實際清單並不重要，只要是你偏好的即可）。然而她對你正在使用的特定平台技術一無所知。紅方候選人對那些議題所知甚少（或興趣缺缺），但非常了解你的平台，例如語言中的邊界情況、有哪些可用函式庫、手指自然地在工具上移動。假設其他所有條件都相同（除了像這樣的思想實驗之外，這永遠不會發生），而且你的團隊沒有這個候選人可能填補的明顯缺口。你會比較偏好哪一位？

替代 原始碼編輯 的想法是，系統的核心定義應保存在模型中，並透過投影進行編輯。