Datensparsamkeit 是一個德語單字，很難適當地翻譯成英文。它是一種關於我們如何擷取和儲存資料的態度，表示我們應該只處理真正需要的資料。

大多數內部 REST API 都是為單一整合點而建構的一次性 API。在本文中，我將討論非公開 API 的限制和彈性，以及從跨多個團隊進行大規模 RESTful 整合中學到的教訓。

我偶爾會在這個網站上撰寫關於軟體開發專業領域中 DiversityImbalance 的問題，以及我們如何需要採取具體行動來增加代表性不足的群體比例。這些都很好，但自然會引發我們應該關注哪些代表性不足的群體的問題。在 Thoughtworks，我們一直使用「歷史上受到歧視」這個詞來幫助我們專注於擁抱多元性的主要驅動力之一。

幾個月前，我買了一台 Google Nexus 7 平板電腦。我喜歡等到使用一段時間後才發表我的體驗，但這種政策的缺點是，現在我所談論的平板電腦已經被取代了。儘管如此，我還是會傳達我的評論，因為它們可能仍然對其他考慮未來平板電腦選項的人有幫助。

我是歐式桌遊的愛好者，這是一種平易近人且深具思考性的桌上遊戲。我喜歡它們，因為你通常可以在一個晚上學會並玩一場，但它們提供了足夠的策略趣味，可以玩很多次。我偶爾會被問到更多關於它們的問題，以及我的最愛是什麼。因此，這裡有一篇簡短的文章來說明它們，以及我架上遊戲的互動清單。

我參加了一場 20 分鐘的小組討論，討論女性在科技領域參與度下降的問題，以及我們應該如何解決這個問題。

JavaScript 社群中似乎有一個常見的誤解，認為測試非同步程式碼需要一種不同於測試「常規」同步程式碼的方法。在本文中，我將說明為什麼通常情況並非如此。我將重點說明測試支援非同步行為的程式碼單元與本質上非同步的程式碼之間的差異。我也將展示基於承諾的非同步程式碼如何提供乾淨且簡潔的單元測試，這些測試可以在清晰、可讀的方式中進行測試，同時仍然驗證非同步行為。

閾值測試是一種插入到 部署管線 中的測試，它透過將目前建置中的值與閾值進行比較來監控一些可測量的現象。如果目前建置的值通過閾值，則測試失敗，導致建置失敗。

當你針對網頁撰寫測試時，你需要參照該網頁中的元素，才能按一下連結並確定顯示的內容。但是，如果你撰寫的測試直接操作 HTML 元素，則你的測試將會對 UI 變更很脆弱。網頁物件會以特定於應用程式的 API 包裝 HTML 頁面或片段，讓你可以在不深入探究 HTML 的情況下操作網頁元素。

告訴，不要詢問是一個原則，它幫助人們記住物件導向是關於將資料與操作該資料的函數綑綁在一起。它提醒我們，與其詢問物件的資料並對該資料採取行動，我們應該告訴物件該做什麼。這鼓勵將行為移到一個物件中，以配合資料。

我在 2013 年阿姆斯特丹主題演講。像往常一樣，它遵循我的「21 世紀軟體設計」範本，並搭配兩場簡短演講。我從談論無架構資料結構開始，說明為什麼總是有隱含架構以及其後果。其次（在25m24s）我談論敏捷軟體開發的精髓和敏捷流暢模型。

給予-何時-然後是一種表示測試的風格，或者正如其支持者所說，使用範例規格來指定系統的行為。這是Daniel Terhorst-North和 Chris Matts 作為行為驅動開發（BDD）的一部分而開發的方法。它作為許多測試架構（例如 Cucumber）的結構化方法出現。您也可以將其視為四階段測試模式的重新表述。

在接受 InformIT 採訪時，我表達了我喜歡在 Thoughtworks 工作的原因（相當偏頗）。我們談論我如何進入 Thoughtworks、為什麼留下來，以及人們可以採取哪些措施來加入並在我們這家有趣的公司中茁壯成長。

流暢介面的問題之一是它會產生一些奇怪的方法。考慮這個範例

我們需要支持隱私，不是為了那些「沒什麼好隱藏」的人，而是為了調查記者和激進分子等麻煩人物，沒有他們，我們的民主將會崩潰

軟體系統的一項常見功能是允許使用者在資料結構中定義自己的欄位。考慮一個通訊錄 - 有許多事情是你可能想要新增的。隨著每天都有新的社群網路冒出頭，使用者可能想要為他們的聯絡人新增一個 Bunglr ID 的新欄位。

故事點數是敏捷專案中常見的評估故事大小的名稱。結合 XpVelocity，它們提供了一種技術，透過提供故事何時可以完成的預測來協助規劃。

故事計數是一種規劃和估計的技術。與 故事點數 類似，它與 XpVelocity 搭配使用，以協助你找出在固定時間內可以交付多少故事。然而，它的不同之處在於你只考慮每單位時間的故事數量，而（大多數）忽略它們的相對大小。

理想時間是早期 極限編程 中用來協助估計工作量的術語。現在它大多已被 故事點數 或 故事計數 取代。

極限編程 (XP) 是一種軟體開發方法，主要由 Kent Beck 開發。XP 是最早的 敏捷方法 之一，事實上，XP 是 90 年代末期和 00 年代初期 Scrum 成為主流之前的主流敏捷方法。許多人（包括我自己）認為 XP 是引起人們注意敏捷方法的主要催化劑，並且作為開始敏捷開發的基礎，它優於 Scrum。

「雲端」在過去幾年已成為一個炒作過度的術語。炒作過度字詞的一個特徵是它們幾乎沒有定義（是的 NosqlDefinition 我在看著你）。

事實證明，有一個出色的雲端運算定義，來自 NIST。它可用於一份極短且易於理解的 標準文件（不，我不是在開玩笑）。

自動化組態工具（例如 CFEngine、Puppet 或 Chef）允許您指定伺服器的組態方式，並使新舊機器符合規定。這有助於避免脆弱的 SnowflakeServers 問題。此類工具可以建立 PhoenixServers，可以隨意中斷並重建。不可變伺服器是此方法的合乎邏輯的結論，一個伺服器一旦部署，就永遠不會修改，僅用新的更新實例取代。

自動化組態工具（例如 CFEngine、Puppet 或 Chef）允許您透過提供範本來描述伺服器元素的組態，以避免 SnowflakeServers。組態同步會持續套用這些規範，無論是在定期排程或變更時，套用至伺服器實例的整個生命週期。如果有人在工具外變更伺服器，下次伺服器同步時，它會還原至集中指定的組態。如果需要變更某些組態，請在組態規範（範本、清單或特定組態工具稱呼它的任何名稱）中進行變更，然後套用至基礎架構中的所有相關伺服器。

行動裝置在流量上仍小於傳統網路，但其佔有率正在成長，因此我們需要思考開發有效行動應用程式的策略。我們討論思考產品願景，將使用者參與的風格區分為「前傾」、「後傾」和「俯視」風格；同時將它們整合到跨媒體應用程式中。我們討論為何專注於價值比流量更重要，雷射和全面防護平台策略，並認為 Android、iOS 和網路是三種可行的平台選擇。Giles 以我們與一家主要航空公司的合作案例作結。

透過伺服器傳遞 JSON 資料結構流是我這幾天看到的事。JSON 文件可以直接儲存，方法是使用AggregateOrientedDatabase或關係資料庫中的序列化 LOB。JSON 文件也可以直接提供給網路瀏覽器或用於將資料傳輸到伺服器端頁面呈現器。當 JSON 以這種方式使用時，我聽到有人說使用物件導向語言會造成阻礙，因為 JSON 需要轉換成物件才能再次呈現 - 浪費程式設計工作。我同意浪費的觀點，但我認為這不是物件的問題，而是不了解封裝。

持續交付是一種軟體開發守則，您以一種方式建置軟體，讓軟體可以在任何時候發布到生產環境。

您在以下情況進行持續交付

• 您的軟體在其整個生命週期中都可部署
• 您的團隊優先考量讓軟體可部署，而不是開發新功能
• 任何人都可以在有人對系統進行變更時，隨時取得快速且自動化的生產準備狀態回饋
• 您可以按鈕部署任何版本的軟體到任何環境，依需求而定

自動化建置和測試環境的挑戰之一是您希望建置快速，以便能快速獲得回饋，但全面測試需要很長的時間才能執行。部署管線是一種透過將建置分解成階段來處理此問題的方法。每個階段提供越來越高的信心，通常以額外的時間為代價。早期階段可以找到大多數問題，提供更快的回饋，而後續階段則提供更慢且更深入的探查。部署管線是持續交付的核心部分。

依賴反轉原則 (DIP) 自 90 年代初期就已存在，即使如此，在解決問題的過程中似乎很容易忘記。在一些定義之後，我將介紹我在實際專案中親自使用 DIP 的一些應用，這樣您將有一些範例可以形成自己的結論。

速度是一個概念，它有助於透過將工作的廣泛陳述與經過時間聯繫起來來校準計畫。速度是一個陳述，說明團隊（或個人，如果是個人速度）在一段時間內完成了多少工作。您通常應根據過去期間完成的工作量來確定速度，遵循昨日天氣的原則。典型的做法是將過去三個時間段的速度平均，以確定未來時間段的速度。速度最初是作為極限編程的一部分形成的，但後來已廣泛傳播，現在廣泛用於各種敏捷軟體開發中。

使用者旅程測試是一種商業面向測試，旨在模擬典型使用者透過系統的「旅程」。此類測試通常會涵蓋使用者與系統的整個互動，以達成某個目標。它們作為使用案例中的一條路徑。

故事測試是 BusinessFacingTests，用於描述和驗證作為 UserStory 一部分提供的軟體。當故事經過詳細說明後，團隊會建立數個故事測試，作為故事的驗收標準。故事測試可以結合到軟體的回歸套件中，並提供從需求（使用者故事）到測試，以及（透過執行）到系統行為的可追溯性。故事測試通常是 BroadStackTests。

面向業務的測試是一種測試，旨在作為與開發團隊中非程式設計成員（例如客戶、使用者、業務分析師等）溝通的輔助工具。當自動化時，它們會以面向領域的術語描述系統，而忽略系統本身的組件架構。面向業務的測試通常用作驗收標準，通過此類測試表示系統提供了客戶預期的功能。

SCMS PO 是一個應用程式，可協助 Gap Inc. 管理採購訂單。此應用程式的架構深受其開發團隊喜愛，因此成為一個良好的 說明性架構，用於具有豐富 javascript 前端與後端提供 json 服務的系統。有趣的設計功能包括使用表示模型模式的 knockout.js 表單、在客戶端和伺服器上執行的 javascript 驗證器、使用儲存庫封裝資料存取、使用 MongoDB 作為應用程式資料庫，以及測試組合。

聚合是領域驅動設計中的模式。DDD 聚合是可視為單一單位的領域物件叢集。範例可能是訂單及其明細項目，這些將是獨立的物件，但將訂單（連同其明細項目）視為單一聚合很有用。

使用者故事是軟體系統中所需行為的區塊。它們廣泛用於敏捷軟體方法，將大量功能劃分為較小的部分以進行規劃。您也會聽到相同的概念稱為功能，但「故事」或「使用者故事」一詞已成為當今敏捷圈中普遍使用的用語。

元件測試是一種測試，它將測試軟體的範圍限制為受測系統的一部分。這與廣堆疊測試相反，廣堆疊測試的目的是測試系統中合理的部分。

廣堆疊測試是一種測試，它測試大型應用程式的絕大部分。它通常稱為端對端測試或全堆疊測試。它與元件測試相反，元件測試僅測試系統中定義良好的部分。

在 Javascript 中，Promise 是表示非同步操作的待處理結果的物件。您可以透過提供回呼，在非同步操作完成後使用這些物件來安排進一步的活動。

我們對軟體系統的理解不斷增長，其中一個問題是我們看到的範例不夠多。在許多專業領域中，人們透過觀察已完成的工作來學習。範例可用作靈感、好點子的來源，以及困難的警告。長久以來，透過這種方式學習軟體一直困難得多。

Ruby Rogues 是個熱門的播客，由固定小組討論 Ruby 程式設計社群中的主題。他們有固定的讀書會，最近選了EAA 的 P作為他們的精選書籍。因此，他們邀請我擔任他們節目的來賓，討論這本書和它所描述的模式，特別是這些模式與 Rails 框架之間的有趣關係。

我第一次接觸敏捷軟體開發是在極限編程的黎明時期，與 Kent Beck 合作。極限編程專案中令我印象深刻的一件事是我們規劃的方式。這包括一種估算方法，既輕量又比我之前看過的更有效。現在已經過了十多年，現在有經驗的敏捷主義者之間爭論估算是否值得進行，甚至是否積極有害。我認為要回答這個問題，我們必須了解估算將用於什麼目的。

在許多組織中，預期任何持續資料都將儲存在由中央資料庫管理群組管理的關聯式資料庫中。這種中央控制有各種原因，通常集中在使用整合資料庫。中央資料群組擔心排除格式錯誤的資料、可能會減慢重要共用資源速度的查詢，以及整個企業中一致的資料模型。

這些目標可能很值得，但其中一個後果是儲存資料的繁文縟節相當多。我經常聽到關於變更單的抱怨，這些變更單需要數週才能將欄位新增到資料庫中。對於習慣於短週期演化設計的現代應用程式開發人員來說，這種繁文縟節太慢了，更不用說太煩人了。

因此，應用程式開發群組告訴我使用NoSQL 資料庫來繞過資料庫管理員。他們在此使用的是「單純資料儲存庫」，而不是「適當的資料庫」，這很有幫助。這樣一來，資料庫管理員就可以置身事外，通常不會被告知或很樂意不關心。

管理階層熱愛他們的指標。思考方式類似於：「我們需要一個數字來衡量我們的表現。數字會讓大家專注，並幫助我們衡量成功。」儘管本意良好，但數字管理會不直覺地導致有問題的行為，並最終損及更廣泛的專案和組織目標。指標本身並不是壞事；只是通常使用不當。本文說明了管理階層傳統使用指標所造成的許多問題，並提供了解決這些功能障礙的替代方案。

我在舊金山的一場 Thoughtworks 活動中演講，使用我慣用的 演講套組 風格。在這場演講中，各個區段涵蓋如何以及何時使用無模式資料結構、為什麼 NoSQL 資料庫中的一致性不只是 ACID 與 BASE 的比較，以及設計良好的軟體的經濟論證。

銷售佣金幾乎普遍用於軟體業務，就像所有業務部門一樣。它們之所以受到歡迎，是因為它們能讓銷售人員和雇用他們的公司之間的誘因保持一致。儘管如此，銷售佣金模式仍存在嚴重問題，這些問題導致 Thoughtworks 在 2013 年取消了所有銷售佣金。

越來越多的網頁開發人員使用 CoffeeScript 和 SCSS 等語言，編譯成其他在瀏覽器中執行的文字原始碼語言。這種原始碼到原始碼的編譯器（也稱為轉譯器）並非新鮮事，Cfront 在 C++ 早期被廣泛用於產生目標 C 程式碼。但對我來說，有一個差異讓 CoffeeScript 和 SCSS 成為透明編譯器

最近我們回到了世界上最喜歡的地方之一，薩巴 - 加勒比海中的一個非常小的島嶼，靠近聖馬丁。在許多方面，薩巴最好的地方就是它沒有的東西。沒有海灘、沒有高爾夫球場、沒有賭場。遍布加勒比海的大量旅遊和度假村綜合設施忽視了薩巴，因為它太小、太丘陵。因此，這個島嶼非常安靜且放鬆。

「大數據」已迅速躍升為我們產業中最炒作的術語之一，但炒作不應讓人們忽視這是一個關於數據在世界中角色的真正重要轉變。數據來源的數量、速度和價值正在迅速增加。數據管理必須在五個廣泛的領域發生改變：從更廣泛的來源萃取數據、透過新的資料庫和整合方法改變數據管理的後勤、在執行分析專案時使用敏捷原則、強調詮釋數據以區分訊號與雜訊的技術，以及設計良好的視覺化以使訊號更易於理解。總結來說，這表示我們不需要大型分析專案，而是希望新的數據思維滲透到我們的日常工作中。

我在編程時，想在目前輸入位置上方新增一空白列。我使用的編輯器沒有內建這項功能，而我對這項功能的渴望已達到極致，我真的很想要它。我快速搜尋 Google，找到幾行程式碼，將它們貼到我的啟動檔案中，執行它們，然後我就可以使用單一按鍵在上方建立空白列。只花了幾分鐘，我不用安裝任何外掛程式，也不用重新啟動編輯器，這對 emacs 使用者來說是日常業務。

近年來，關於無架構資料優點的討論越來越多。無架構是對NoSQL 資料庫感興趣的主要原因之一。但是，無論是在資料庫或是在記憶體中資料結構，無架構都涉及許多細微差別。這些細微差別存在於無架構的意義，以及使用無架構方法的優缺點中。