我 2020 年最喜歡的六首新歌

我們渴望透過資料來擴充和改善商業與生活的各個面向，這需要我們在管理大規模資料的方式上進行典範轉移。儘管過去十年的技術進步已解決資料量和資料處理運算的規模問題，但它們並未解決其他面向的規模問題：資料環境的變化、資料來源的擴散、資料使用案例和使用者的多元性，以及對變化的回應速度。資料網格透過四項原則來解決這些面向：以領域為導向的分散式資料所有權和架構、資料作為產品、自助服務資料基礎架構作為平台，以及聯邦運算治理。每項原則都會驅動技術架構和組織結構的新邏輯觀點。

運算筆記本是一個撰寫散文文件的環境，讓作者可以嵌入程式碼，並能輕鬆執行程式碼，同時將結果納入文件。這是一個特別適合資料科學工作的平台。此類環境包括 Jupyter Notebook、R Markdown、Mathematica 和 Emacs 的 org 模式。

我們遇到許多客戶有興趣採用資料科學家開發的運算筆記本，並將它們直接放入生產應用程式的程式碼庫中。資料科學想法確實需要從筆記本轉移到生產，但嘗試將筆記本部署為程式碼工件會破壞許多良好的軟體實務。可以預見，這會造成許多觀察到的痛點。這種行為是更深層問題的徵兆：資料科學家和軟體開發人員之間缺乏合作。

一個誤導性的標題，用來吸引讀者閱讀一個偶爾真實的故事

當出現來源可疑的新聞報導時，社群媒體是否應使用暫時封鎖來減緩其傳播速度？

Google 試算表腳本是與非程式設計師分享簡短腳本的便捷方式。

為什麼反對川普總統及其支持者很重要。

在商業會議中，通常會透過比較群組的平均值來比較群組數字。但這麼做通常會隱藏那些群組中數字分佈的重要資訊。有許多資料視覺化可以闡明這些資訊。這些視覺化包括條形圖、直方圖、密度圖、箱形圖和提琴圖。這些視覺化很容易使用免費軟體產生，適用於小至十幾個、大至數千個的群組。

由於無法前往澳洲參加 2020 年 XConf，我改為與 Thoughtworks 澳洲技術負責人 Scott Shaw 進行視訊對談。我們討論了資料在現代應用程式開發中扮演的角色變化：應用程式開發人員與資料庫之間的鴻溝、大數據（且雜亂無章）出現所帶來的變化、提升資料素養的必要性，以及大量收集推測性資料對社會的影響。

goto conferences 邀請我訪談 Sam Newman，討論他的著作：「從巨石到微服務」。這場訪談演變成關於微服務以及何時使用微服務的一般對話。Sam 認為微服務有三大主要原因：獨立部署性、資料隔離性和反映組織結構。我對第一個原因較為懷疑，但認為資料和人員是軟體開發中複雜的部分。

對 1953 年伊朗政變紀錄片《53 年政變》的簡短評論。

對 Kinesis Advantage2 人體工學鍵盤的簡短評論，我已經使用三年半了。

我們的歐洲「資料女巫」Em Grasmeder 和我計畫在歐洲的 XConf 系列中發表主題演講。由於是 2020 年，我們改用 Zoom，並討論資料科學家的角色：角色的實際內容、他們需要取得的工具，以及他們與其他形式軟體開發的關係。

本文提供明確且簡單的步驟，以協助想要採用威脅建模的團隊。威脅建模是設計安全系統的風險導向方法。它是基於識別威脅，以便開發對策。隨著網路安全風險增加，企業越來越意識到其負債，軟體開發團隊需要有效的方法將安全性建置到軟體中。不幸的是，他們常常難以採用威脅建模。許多方法需要複雜、詳盡的前期分析，這與現代軟體團隊的工作方式不符。因此，我鼓勵團隊從簡單開始，然後逐步擴展，而不是為了建立完美的威脅模型而停止所有事情。

現代原始碼控制系統提供強大的工具，讓在原始碼中建立分支變得容易。但最終這些分支必須合併在一起，許多團隊花費大量時間應付錯綜複雜的分支。有幾個模式可以讓團隊有效地使用分支，專注於整合多個開發人員的工作，並組織通往生產版本的途徑。總體主題是分支應該頻繁整合，並專注於可以輕鬆部署到生產環境的健全主線。

功能分支是一種原始碼分支模式，開發人員在開始開發新功能時開啟分支。她會在此分支上完成所有功能工作，並在功能完成時將變更與團隊其他成員整合。

暗黑啟動功能表示採用新的或已變更的後端行為，並從現有使用者呼叫，而使用者無法得知已呼叫。這麼做是為了在公開宣布新功能之前，評估對系統的額外負載和效能影響。

某些程式元素本質上難以測試，甚至無法測試。這些元素中的任何邏輯因此容易出現錯誤，且難以演進。為了減輕這個問題，請盡可能將邏輯移出難以測試的元素，並移入程式碼庫中其他更友善的部分。透過讓無法測試的物件變得謙遜，我們可以降低它們藏有惡意錯誤的機率。

軟體開發團隊發現，如果他們能盡可能頻繁地整合工作，生活會容易得多。他們也發現頻繁地發佈到生產環境很有價值。但團隊不希望向使用者公開半開發的功能。處理這種緊張關係的一個有用技巧是建立所有後端程式碼，並進行整合，但不要建立使用者介面。可以整合和測試功能，但使用者介面會保留到最後，直到像拱心石一樣，將其加入以完成功能，並向使用者揭露。

領域驅動設計是一種軟體開發方法，其開發中心在於編寫領域模型，該模型深入了解領域的流程和規則。此名稱來自 Eric Evans 於 2003 年撰寫的書籍，透過範例目錄說明此方法。從那時起，實務社群進一步發展了這些想法，衍生出各種其他書籍和訓練課程。此方法特別適合於複雜的領域，其中需要組織大量經常混亂的邏輯。

在本文中，我將逐步介紹一組來自真實程式碼庫的重構。這不是為了展示完美，而是反映現實。

結對程式設計是一種軟體開發實務，讓開發人員以兩人為一組進行工作。所有嚴肅的程式碼都是由兩位程式設計師編寫，通常並排坐在一台顯示器前，通常使用一個鍵盤。當他們新增程式碼時，他們會一起討論每一步驟。

取得良好的音訊品質、使用圖庫檢視、不說話時請靜音，並歡迎貓咪。

關於 Thoughtworks 如何應對 2019 冠狀病毒疾病 (Covid-19) 爆發的第二篇文章

我們和我們的同事經常被要求為我們的客戶執行架構評估。當我們這樣做時，參與這些系統的架構師會談論這些系統的效能、它們對故障的復原力，以及它們如何設計為能輕鬆支援新的功能。然而，很少出現的大象是不同的系統如何為商業價值做出貢獻，以及這個價值如何與這些其他架構屬性互動。

到目前為止，我們從應對 2019 冠狀病毒疾病 (Covid-19) 爆發中學到的經驗

當客戶公司購買軟體產品時，他們通常需要熟練的員工來安裝它們。這些員工通常由服務供應商公司提供，因為軟體產品供應商認為建立自己的服務部門在商業上沒有意義。客戶需要了解產品供應商和服務供應商之間的關係，並應要求與他們合作的供應商公開這種關係。隨著雲端供應商的興起，這些合作夥伴關係的重要性日益提升，公開透明也變得越來越重要。

想像一個團隊為購物網站撰寫軟體。如果我們檢視該團隊的產出，我們可能會考慮他們在最近一季製作了多少新功能，或跨功能衡量標準，例如縮短頁面載入時間。然而，成果衡量標準會考慮增加銷售收入或減少產品支援電話的數量。著重於成果，而非產出，有利於建置更多功能來提升軟體使用者和客戶的效能。

在理想狀態下，產品模式組織由鬆散結合的自主團隊組成，能快速回應明確和不明確的使用者需求。然而，偶爾會出現需要跨多個團隊協調的回應機會。如果沒有有效管理，結果將導致錯失營收、客戶不滿意和團隊產能浪費。我們將回應這些機會的組織性計畫稱為計畫。在本文中，我們將透過一個計畫失敗的範例，分享我們在產品模式組織中管理計畫的經驗。

許多現今從事軟體開發的人聽過配對程式設計的實務，但它在業界的採用仍不普遍。其接受度不一的其中一個原因是它的好處並不明顯，它在中長期會產生較多的回報。而且它也不像「兩個人使用同一台電腦」這麼簡單，因此許多人在覺得不舒服時會快速放棄它。然而，根據我們的經驗，配對程式設計對於協作團隊合作和高品質軟體至關重要。