企業架構群組經常與日常開發脫節。這可能會導致他們對開發工作的知識過時，而開發團隊也無法從廣泛的公司角度來考量。我的同事（Thoughtworks 技術長）Rebecca 經常看到這種情況，她認為企業架構師透過加入開發團隊可以發揮更大的效用。

表格驅動技術，讓系統可以在不進行重大程式碼變更的情況下進行變更。

咖啡師不會進行同步處理 - 他們的原因可能是您也改用非同步的原因。

清晰的程式碼很好，但您應該為了可測試性而犧牲清晰度嗎？

如果軟體要往南走，Jim 在這篇專欄中說明了它應該盡可能快地崩潰。

每個人都有自己的一份重要設計指南清單。Scott 專注於介面，以及如何設計介面，讓它們易於正確使用，且難以錯誤使用。

在 2003 年的 OOPSLA 中，OTI 創辦人 Dave Thomas 對模型驅動架構提出了深思熟慮且有力的批評。在此專欄中，他說明了為何他認為通用的模型驅動方法可能會失敗，並指出 UML 和特定領域語言仍有價值。

重構、JUnit 等工具以及極限程式設計 (XP) 等敏捷方法的日益普及，帶來了一種新的設計風格。持續設計是使用重構持續改善程式設計的過程。在此專欄中，Jim 討論了他對持續設計的經驗，特別是國際化和交易等看似棘手的設計問題。

封裝的常見部分，特別是在物件導向系統中，是隱藏資料結構。然而，將這些資料的大部分暴露在資料存取常式背後也很常見。在此專欄中，我介紹了一些撰寫資料存取常式的準則。不過，別忘了，如果你可以讓資料保持隱藏，通常會更好。

什麼是架構，誰才是真正的架構師？這些問題似乎讓所有人都很激動。因此，在此 IEEE 軟體專欄中，我讓 Ralph Johnson 說明架構：以一種沒有人同意的方式，符合所有其他定義。我也談到了架構師的兩個亞種：Architectus Reloadus 和 Architectus Oryzus。

當我們思考軟體架構時，我們通常會想到它的技術架構。但還有一個重要的架構，我們用它來與軟體的客戶溝通：行銷架構。忽視這個「行銷架構」及其與「技術架構」的關係，可能會讓開發專案陷入許多麻煩。

混亂理論為何表明元件組裝可能不如想像中那麼容易。

我在 IEEE 專欄中提到模式對了解軟體設計的寶貴貢獻。

關於何時為值建立新的使用者定義類型 (或類別) 的指南。

您可以使用基於元資料的方法來消除繁瑣的資料導向任務。

Jim 和 Alexei 在開發 NUnit 的新版本中扮演領導角色。從中，他們反思新 .NET 語言功能屬性如何影響設計。

許多關於效能最佳化的既定原則鮮為人知，這總是讓我感到驚訝。本文是再次嘗試涵蓋這些原則。

許多現代語言會區分模組中的公開和私人功能。公開和已發布功能之間的區別並未如此常見：而這可能是更重要的區別。

避免軟體中重複這個簡單規則有時會如何引導出良好的設計，這相當值得注意

我學到的第一個教訓之一是，永遠讓使用者介面程式碼與其他任何程式碼分開。這不僅仍然是好的建議，而且令人驚訝的是，這項建議經常被遺忘。

Craig 在專欄中的位置探討了開放-封閉原則和受保護變異的重要性，以及 Parnas 的資訊隱藏不只是封裝。他也提供了一些實作受保護變異的方法提示。

思考如何視覺化和降低耦合。

設計技術通常用於讓系統更靈活，但最後卻變得更難以使用。原因之一是，明確性是一個在設計中經常被遺忘的屬性。

可測試性是一個如此重要的優點，您應該做出架構決策來改善系統的可測試性。

模組化程式設計不只是針對介面進行程式設計，它也關於在沒有各種模組知道它們正在與哪些具體模組對話的情況下將模組組裝在一起。

您繪製的模型類型取決於您希望將它們用於的目的。約翰描述了概念模型、規格模型和實作模型之間有用的區別。