事故檢討很容易召開，卻很難做得有用。會開了，文件寫了，四條改善事項記下來了，六個月後同一個故障又發生一次，而某個人正好在找別的東西時翻出那份舊文件。 談到這件事時，注意力幾乎都落在「不究責」這個詞上。這條原則確實重要，但失效的地方並不在那裡。有大量組織把不究責執行得一絲不苟，檢討卻什麼也沒有改變，原因很簡單：他們把檢討本身當成了交付物，而不是當成產出交付物的手段。 判斷你們的檢討是否有效，有一個簡單到令人難堪的測試：過去六個月記錄下來的改善事項，實際完成的比例是多少？ 如果答案是「大部分」，那麼無論流程長什麼樣，它都在發揮作用。如果低於一半，你們是在開會而不是在運行一個流程，換更漂亮的範本也救不了。少數幾條帶負責人與期限的事項，勝過...
程式碼品質
關於程式碼品質的文章、指南和教程，為開發者和企業提供實用知識與技巧。並附真實專案中的具體案例。
技術文件的失敗方式非常具體，也非常好預測。有人在兩週清閒的時間裡寫下一大堆，接著系統變了，沒有人回頭更新，一年之內那份文件就開始信心十足地講著錯誤的內容。到了那個時候，它比什麼都沒有還要糟，因為相信它的讀者會依據早已不成立的資訊去動手。 常見的反應是號召大家多寫一些，而這只會讓同樣的失敗來得更快。有用的反應是少寫，並且認真挑選寫什麼，因為真正的瓶頸不是寫作的工夫，而是維護的工夫。文件從寫完那一刻起，就開始被現實甩在後面。 判斷一份文件該不該存在，唯一經得起時間的檢驗是： 當它變錯的時候，會不會有人察覺？部署指南天天有人用，錯誤立刻就會浮出來。一份二十頁的子系統說明只會被讀一次，它的錯誤要等到十八個月後，有人照著它動手時才浮出來。沒有...
開發者到職通常是用新人訓練花了幾天來衡量的，而那是問題的另一頭。真正重要的數字是另一個：一位新來的工程師要過多久，才能改動某個東西，而且有把握自己沒有弄壞別的地方。在大多數團隊裡，這個數字是以月計算的，而不是以天計算的。 延遲很少出在人身上。它出在系統裡有多少部分只存在於別人的腦袋裡，以及前兩週裡有多大一部分時間，是靠一次次打斷別人，一點一點把這些東西挖出來的。 唯一值得追蹤的指標：從到職到他們的第一次改動進入正式環境，需要多久。 不是第一次提交，提交可以只是改一個錯字，而是一次有意義而且真正上線的改動。如果這個時間超過一週，障礙幾乎從來都不是能力。而是一份最近沒有人從零走過一遍的環境建置流程，或者一份沒有人帶路就找不到入口的程式碼...
關於 API 版本管理的爭論，幾乎總是從錯誤的一端開始：版本號到底要放在哪裡。事實上，那是整個主題裡後果最輕微的一個決定。真正要緊的是究竟哪些變更才需要一個新版本，而多數團隊恰好在這裡判斷失準，而且是往掉以輕心的方向失準。他們發布了自認為純屬新增的東西，然後某個用戶端就壞了。 好用的思考模型是這樣：你的 API 是一份承諾，界定了呼叫端可以倚賴什麼。如果一次變更讓一個講理的呼叫端原本倚賴的東西失效，那它就是破壞性的。而呼叫端倚賴的東西，遠遠多過你的文件明確允許他們倚賴的範圍。 讓所有人都踩到的那種變更： 在回應裡多加一個欄位。它只是新增，照理說弄不壞一個寫得規矩的用戶端，可它偏偏經常弄壞真實世界的用戶端，因為其中有些會嚴格驗證回應，...
技術盡職調查不是一場程式碼品質比賽，而準備接受查核的團隊，通常把時間花在最不相干的地方。沒有人是為了替你的抽象層打分數才來買一家公司。買方想弄清楚的其實只有兩件事：擁有這套系統要付出多少代價，以及在資金易主之後，情況可能壞到什麼程度。 換一個角度看待這件事之所以重要，是因為它會改變你該優先處理什麼。醜歸醜但跑得動、團隊看得懂、可以安全修改的程式碼，只是一則輕微的查核結果。反過來說，寫得漂亮卻只有一個人看得懂的程式碼，才是嚴重的查核結果，而真正牽動價格的，向來是後者。 所有問題背後的那個問題： 如果創辦工程師在交割後的隔週離職，這套系統還跑得下去，而且還改得動嗎？幾乎每一項會壓低出價的查核結果，都是對這個問題的具體回答。知識全積在一個...
資料庫效能的排查工作，通常從有人提議換一台更大的執行個體開始，又通常以這樣一個發現收場：每次載入頁面時，有一條查詢都在對 400 萬列做循序掃描。瓶頸從來就不是硬體，瓶頸是執行計畫。 這個模式重複得夠穩定，值得當成預設假設寫下來。當應用很慢而資料庫又很忙時，原因幾乎都是少數幾條特定的查詢，而不是整體容量不足；把機器換大，只能把問題掩蓋到資料表再次長大的那一刻為止。 動手改之前，先量。 憑猜測去最佳化一條查詢，正是團隊花掉整整一週新增索引、結果寫入變慢而讀取一點也沒變快的原因。任何資料庫都能告訴你哪些語句消耗的總時間最多。從那裡開始，修掉排在最前面的那一條，然後再量一次。這樣反覆兩三輪，事故通常就結束了。 資料庫效能始於找出那條查詢總...
談到軟體測試策略，大家幾乎都從覆蓋率說起，而覆蓋率偏偏是整個領域裡資訊量最低的一個數字。一個覆蓋率達到九十的程式碼庫，照樣可能在最常被走到的路徑上把缺陷送上線，因為覆蓋率量的是測試執行期間有哪些程式碼行被跑過，而不是有沒有針對這些行做出任何有意義的斷言。 真正信任自己測試套件的團隊，並不是覆蓋率百分比最高的那一群。他們是這樣的團隊：東西真的壞掉時測試會亮紅燈，其餘時候測試安安靜靜。這個特性，比多數人想像的更難用錢買到。 對任何一個測試都值得問的問題： 如果它失敗了，我知道該怎麼辦嗎？因為行為改變而失敗的測試，會告訴你一些事情。因為某個實作細節換了位置而失敗的測試，只能告訴你有人做了重構。這種失敗累積到一定數量，團隊就不再讀失敗訊息，...
軟體開發生命週期（通常縮寫為SDLC）是團隊將軟體從一個想法推進到可運行、可維護產品所遵循的結構化流程。無論是開發軟體還是委託開發，理解這個流程都至關重要，因為流程的品質在很大程度上決定了結果的品質、成本和及時性。本指南清晰闡釋軟體開發生命週期：每個階段及其內容、敏捷與瀑布方法的差異、專案通常在哪裡出問題，以及良好的流程如何控制成本和風險。 重點摘要 軟體開發生命週期是規劃、建構、測試、部署和維護軟體的結構化流程 經典階段包括規劃、需求、設計、實作、測試、部署和維護 敏捷和瀑布是通過這些階段的兩種方式：迭代式與循序式 大多數軟體失敗可追溯到薄弱的早期階段，尤其是理解不清晰的需求 良好的SDLC透過在問題還容易修復時及早發現，降低風險...
網路開發最佳實踐是僅僅能運作的網站，與效能出色、排名靠前、經久耐用的網站之間的差距所在。2026年，標準比以往任何時候都要高：使用者期望即時載入速度，搜尋引擎獎勵速度和無障礙性，而安全威脅則持續不斷。好消息是，能產出優質網站的實踐方法已經廣為人知。本指南涵蓋了當今真正重要的網路開發最佳實踐，涉及效能、無障礙性、安全性、SEO、程式碼品質和測試等領域，提供可以實際應用的實用指引，而非抽象原則。 摘要 效能不容妥協：針對 Core Web Vitals 進行最佳化，因為速度同時影響排名和轉換率 無障礙性是基本要求，而非可選附加項，良好的無障礙性能提升所有人的使用體驗 從一開始就建構安全性，而不是在上線後補充 撰寫其他開發者（以及搜尋引...
過去兩年中，「技術債務」的搜尋量增長超過35%，這在很大程度上是由英國工程團隊推動的，他們繼承了在截止日期壓力下構建的遺留系統，如今苦於維護或擴展這些系統。這個術語在Jira待辦清單和迭代回顧中被隨意使用，但大多數開發人員從未見過精確的定義，更別說系統性的應對策略了。 本指南涵蓋技術債務的真正含義、它的來源、如何衡量，以及在英國真實產品團隊中有效的實踐策略。它借鑑了Ward Cunningham的原始比喻和Martin Fowler的四象限模型，並將其與你在本次迭代中可以付諸實踐的日常決策相結合。 摘要 技術債務是選擇當下更快、更簡單的解決方案而非更好方案所產生的隱性返工成本。與金融債務一樣，它會隨著時間的推移累積利息。...