加入 LinkedIn
2024 年 3 月 28 日星期四,美國東部時間下午 12:26
隨著 Twitter 的馬斯克化持續進行,我越來越常聽說有更多人使用 LinkedIn 來追蹤新的專業資料。因此,幾週前我設定了我的LinkedIn 帳戶,讓大家可以在該平台上追蹤我。
軟體開發是一個新興的專業領域,我們仍在學習技術,並打造工具以有效地進行開發。我參與這項活動已超過三十年,在過去兩年來,我一直在這個網站上撰寫有關模式和實務的文章,這些模式和實務讓建置有用的軟體變得更容易。這個網站最初是作為放置我個人著作的地方,但我也用它來發布我同事的文章。
2000 年,我加入了 Thoughtworks,我的職責是了解我們為客戶交付軟體時所學到的技術,並將這些技術傳授給更廣泛的軟體產業。由於這個網站已發展成為軟體開發方面備受推崇的平台,我編輯並發布了同事(包括 ThoughtWorkers 和其他人)的文章,以幫助有用的著作接觸到更廣泛的讀者。
照片:Christopher Ferguson
Martin Fowler
如果我的工作和這個網站上的著作有一個主題,那就是敏捷思維的轉變與讓敏捷軟體開發實務化的技術模式和實務之間的交互作用。雖然我們專業領域的技術細節會快速改變,但基本實務和模式卻較為穩定。因此,撰寫這些內容讓我可以在這個網站上發表一些幾年前的文章,但它們仍然與撰寫當時一樣相關。
由於軟體對現代商業越來越重要,軟體需要能夠快速因應變動,讓新功能得以快速構思、開發和投入生產。敏捷軟體開發 的技術始於 1990 年代,並在過去十年中穩步普及。它們專注於靈活的規劃方法,讓軟體產品能夠隨著使用者的需求改變和產品經理更了解如何讓使用者發揮效能而改變方向。雖然現在廣為接受,但敏捷方法並不簡單,需要團隊具備重要的技能,但更重要的是團隊內部和團隊合作夥伴之間的開放協作文化。
這種對變更做出流暢回應的需求,對軟體系統的架構有重要的影響。軟體需要以能夠適應功能上的意外變更的方式來建置。執行此項任務最重要的方式之一,是撰寫清晰的程式碼,讓程式預期要執行的動作容易理解。此程式碼應分為模組,讓開發人員只了解需要變更的系統部分。此製作程式碼應搭配自動化測試,以便在進行變更時偵測任何錯誤,同時提供內部結構如何使用的範例。大型且複雜的軟體工作可能會發現微服務架構樣式有助於團隊部署具有較少糾纏相依性的軟體。
建立具有良好架構的軟體並非一蹴可幾。如同優良的散文,隨著程式設計師更了解產品需要執行的動作,以及如何最佳化設計產品以達成目標,需要定期進行修正。重構是允許安全變更程式的必要技術。它包含不會變更軟體可觀察行為的小變更。透過結合許多小變更,開發人員可以修正軟體結構,支援最初構思系統時未規劃的重大修改。
只在開發人員電腦上執行的軟體,並未為軟體客戶提供價值。傳統上,釋出軟體一直是漫長且複雜的流程,這會阻礙快速演進軟體的需求。持續傳遞使用自動化和協作工作流程來移除此瓶頸,讓團隊可以依照客戶需求的頻率釋出軟體。若要讓持續傳遞成為可能,我們需要建置測試的穩固基礎,並搭配一系列自動化測試,讓我們確信變更並未引入任何錯誤。這讓我們將測試整合到程式設計中,這有助於改善我們的架構。
加州大蘇爾
市面上有許多種軟體,我主要從事的種類是企業應用程式。我們需要在這個世界上解決的持久問題之一,就是資料管理。我在這裡關注的資料管理面向,包括如何隨著應用程式回應變更的需求來移轉資料儲存,因應大型企業中的不同脈絡,NoSQL 資料庫的角色,以及因應龐大且混亂資料的廣泛問題。
複雜軟體系統中常見的問題,在於如何捕捉複雜的領域邏輯,讓程式設計師既能輕鬆操作,又能輕鬆地與領域專家溝通。特定領域語言 (DSL) 為特定問題建立客製化語言,可以使用客製化解析器或主機語言中的慣例。
我寫了七本軟體開發書籍,包括《重構》、《企業應用架構模式》和《精餾 UML》。我也擔任 Addison-Wesley 的簽名系列編輯,其中包括五本 jolt 獎得獎作品。
我經常受邀在大會演講,從中我推論出自己是一位相當不錯的演說家,這很有趣,因為我其實很討厭演講。你可以觀看我的部分大會演講影片,自行評斷我的演講。
我向來是桌遊愛好者,我喜歡能讓我的思緒完全沉浸在遊戲中的遊戲,暫時忘卻所有嚴肅的想法,同時享受與好友相聚的時光。現代桌遊在 1990 年代隨著歐式桌遊的興起而大幅進步,如果有人從未嘗試過這一代的新遊戲,我想他們一定會感到驚訝。我也會定期出現在Heavy Cardboard。
如果你想在我發布新資料時收到通知,請訂閱我的RSS、Twitter或Mastodon動態消息。我也有專門的近期變更頁面。
2024 年 3 月 28 日星期四,美國東部時間下午 12:26
隨著 Twitter 的馬斯克化持續進行,我越來越常聽說有更多人使用 LinkedIn 來追蹤新的專業資料。因此,幾週前我設定了我的LinkedIn 帳戶,讓大家可以在該平台上追蹤我。
2024 年 3 月 27 日星期三,美國東部時間下午 12:48
我珍貴的同事兼好友約翰·科迪巴克上週過世,享年 64 歲。
2024 年 3 月 26 日星期二上午 9:32 EDT
大型主機系統持續執行世界上大部分的運算工作負載,但往往難以新增功能來支援不斷成長的業務需求。此外,讓它們增強功能緩慢的架構挑戰也讓它們難以取代。為了降低所涉及的風險,我們使用漸進式方法來取代舊有系統,逐漸以現代技術的實作取代舊有功能。此策略要求我們在大型主機系統中引入接縫:我們可以在其中將邏輯流程轉移到較新的服務。在最近的專案中,Alessio Ferri 和 Tom Coggrave 調查了幾種方法,以 在長壽的大型主機系統中引入這些接縫。
2024 年 3 月 15 日星期五上午 11:04 EDT
時不時有人要求我提供我在 重構 一書的入門章節中使用的程式碼,以便他們可以自行演練。我基於某些理由不提供此程式碼,特別是因為懶惰。很幸運地,Emily Bache 較為積極,她建立了一個 github 儲存庫,也就是 戲劇玩家重構 Kata,其中包含程式碼和足夠的測試,讓執行重構變得合理。
然而,此儲存庫的進度更進一步,它包含了十幾種語言的類似範例程式碼,包括 C、Java、Rust 和 Python。
她最近在 YouTube 頻道上發布了一段影片,概述了她鼓勵大家在閱讀該章節時使用此程式碼的原因。她的頻道包含許多關於良好程式碼技巧的影片,而且她有一個 Patreon,讓讀者可以支持她的工作。
2024 年 3 月 12 日星期二上午 9:36 EDT
衡量開發人員生產力是一項艱鉅的挑戰。專注於開發週期時間和產出的傳統指標有限,而且對於其他可以轉向的目標並無明顯答案。定性指標提供了一種強大的方式,可以透過從開發人員本身衍生的資料來衡量和了解開發人員生產力。Abi Noda 和 Tim Cochran 在討論一開始便 說明了什麼是定性指標,以及為什麼我們不應因為它們主觀或不可靠而拒絕它們。
2024 年 3 月 6 日星期三,美國東部時間上午 10:33
在配對程式設計中,經常輪換配對很重要,但許多執行配對程式設計的組織都不願意這麼做。Gabriel Robaina 和 Kieran Murphy 提出問題:「如果我們每天輪換配對會怎樣?」並透過每日配對輪換的練習與三個團隊合作。他們開發出一種輕量級方法,以協助團隊反思配對的優點和挑戰,以及如何解決這些問題。團隊克服了最初的恐懼,並發現了頻繁輪換配對的優點。他們了解到,頻繁地輪換配對會大幅提升配對的優點。他們的文章分享他們開發的方法、觀察結果,以及參與團隊成員分享的一些常見恐懼和見解。