內容修剪是搜尋最佳化裡最違反直覺的一件事，因為所有本能都在說，頁面越多流量就該越多。發布內容讓人覺得是在累積資產。刪除內容讓人覺得是把別人花錢買來的成果丟掉。於是刪除一再被往後延，最後只剩下一堆越疊越高的頁面。 讓刪除真正發揮作用的機制，是你自己的頁面彼此在競爭。當你有兩個頁面瞄準同一個搜尋意圖，本來會集中在一個頁面上的訊號就被劈成兩半，而必須在兩者之間做取捨的檢索系統，最後甚至可能一個都不選。解法不是把兩個都做得更好，而是別再同時擁有兩個。 在刪掉任何東西之前，先看清每個頁面各自在做什麼。 一個沒有點擊的頁面，可能仍然承接著一條傳遞權重的反向連結，也可能每月只有一位訪客，卻把這位訪客變成比網站其餘部分加起來還值錢的詢價。流量單獨拿...
文章
在同一頁面瀏覽所有文章。找到關於人工智慧、程式設計、資安、基礎設施與網站開發的教學、深度解析、指南與更新。
關於 API 版本管理的爭論，幾乎總是從錯誤的一端開始：版本號到底要放在哪裡。事實上，那是整個主題裡後果最輕微的一個決定。真正要緊的是究竟哪些變更才需要一個新版本，而多數團隊恰好在這裡判斷失準，而且是往掉以輕心的方向失準。他們發布了自認為純屬新增的東西，然後某個用戶端就壞了。 好用的思考模型是這樣：你的 API 是一份承諾，界定了呼叫端可以倚賴什麼。如果一次變更讓一個講理的呼叫端原本倚賴的東西失效，那它就是破壞性的。而呼叫端倚賴的東西，遠遠多過你的文件明確允許他們倚賴的範圍。 讓所有人都踩到的那種變更： 在回應裡多加一個欄位。它只是新增，照理說弄不壞一個寫得規矩的用戶端，可它偏偏經常弄壞真實世界的用戶端，因為其中有些會嚴格驗證回應，...
軟體 RFP，也就是需求建議書，本來的用途是讓不同廠商變得可以互相比較。可是現實中大多數文件剛好起了反效果：它們把解決方案寫得夠細，細到把回答的空間綁死，卻偏偏漏掉了任何人報價時都會需要的那些資訊。結果就是五份報價，彼此差了一個數量級，形式上每一份都回應了需求，但沒有任何兩份在衡量同一件事。 常見的說法是廠商在打太極。偶爾確實如此。但更常見的情況是，文件要了一個從它本身內容根本推不出來的數字，於是每家廠商都用各自不同的假設去填補空白。假設不同，價格自然不同，這裡並沒有誠不誠實的問題。 判斷你的 RFP 是否有效的檢驗方式： 兩家不同的廠商讀完之後，能不能得出實質上相同的範圍？如果文件裡只寫了「使用者管理」，沒有說明有幾種角色、權限是...
軟體維護成本，就是那個讓一個成功專案在十八個月後變成一場尷尬談話的數字。開發階段有預算、有簽核，也如期交付了。可是上線之後會發生什麼事，被一句「技術支援」草草帶過，再配上一個有人憑感覺喊出來的金額，而那個金額幾乎每次都太小。 原因出在結構，不是誰不用心。開發有一個可以報價的範圍。維護沒有範圍，因為決定它的是還沒發生的事：某個相依套件爆出漏洞、某家供應商改掉自己的介接規格、某位使用者碰上當初誰都沒想到的狀況。 人人都在引用的經驗法則是每年抓開發成本的 15 到 20 個百分點，而它之所以危險，正是因為它離正確答案不遠。 它對的次數多到讓人安心，錯的時候又總是往同一個方向錯：它低估了缺陷集中浮現的第一年，而在有法遵義務或外部介接很多的系...
技術盡職調查不是一場程式碼品質比賽，而準備接受查核的團隊，通常把時間花在最不相干的地方。沒有人是為了替你的抽象層打分數才來買一家公司。買方想弄清楚的其實只有兩件事：擁有這套系統要付出多少代價，以及在資金易主之後，情況可能壞到什麼程度。 換一個角度看待這件事之所以重要，是因為它會改變你該優先處理什麼。醜歸醜但跑得動、團隊看得懂、可以安全修改的程式碼，只是一則輕微的查核結果。反過來說，寫得漂亮卻只有一個人看得懂的程式碼，才是嚴重的查核結果，而真正牽動價格的，向來是後者。 所有問題背後的那個問題： 如果創辦工程師在交割後的隔週離職，這套系統還跑得下去，而且還改得動嗎？幾乎每一項會壓低出價的查核結果，都是對這個問題的具體回答。知識全積在一個...
資料庫效能的排查工作，通常從有人提議換一台更大的執行個體開始，又通常以這樣一個發現收場：每次載入頁面時，有一條查詢都在對 400 萬列做循序掃描。瓶頸從來就不是硬體，瓶頸是執行計畫。 這個模式重複得夠穩定，值得當成預設假設寫下來。當應用很慢而資料庫又很忙時，原因幾乎都是少數幾條特定的查詢，而不是整體容量不足；把機器換大，只能把問題掩蓋到資料表再次長大的那一刻為止。 動手改之前，先量。 憑猜測去最佳化一條查詢，正是團隊花掉整整一週新增索引、結果寫入變慢而讀取一點也沒變快的原因。任何資料庫都能告訴你哪些語句消耗的總時間最多。從那裡開始，修掉排在最前面的那一條，然後再量一次。這樣反覆兩三輪，事故通常就結束了。 資料庫效能始於找出那條查詢總...
實體SEO的起點，是一個大多數最佳化建議至今仍然略過的事實：搜尋引擎早就不再比對字串了。它們比對的是事物。一個頁面拿到什麼分數，並不取決於它是否含有某個詞組，而取決於系統是否相信這個頁面談的是詞組背後的那個概念，以及系統對於那個概念究竟是什麼有多少把握。 這個區別決定了重複關鍵字究竟對你有幫助，還是完全沒有作用。在比對字串的系統裡，重複是一種訊號。在比對實體的系統裡，重複只是雜訊，真正會推動結果的，是機器能不能辨識出你是什麼。 判斷你是否以實體身分存在的測試： 搜尋你的公司名稱，看看在沒有人追問的情況下，搜尋引擎主動端出了關於你的哪些資訊。如果它只回傳首頁，其他什麼都沒有，那麼你只是一串它找得到的字元。如果它回傳了描述、所在地、類別...
談到軟體測試策略，大家幾乎都從覆蓋率說起，而覆蓋率偏偏是整個領域裡資訊量最低的一個數字。一個覆蓋率達到九十的程式碼庫，照樣可能在最常被走到的路徑上把缺陷送上線，因為覆蓋率量的是測試執行期間有哪些程式碼行被跑過，而不是有沒有針對這些行做出任何有意義的斷言。 真正信任自己測試套件的團隊，並不是覆蓋率百分比最高的那一群。他們是這樣的團隊：東西真的壞掉時測試會亮紅燈，其餘時候測試安安靜靜。這個特性，比多數人想像的更難用錢買到。 對任何一個測試都值得問的問題： 如果它失敗了，我知道該怎麼辦嗎？因為行為改變而失敗的測試，會告訴你一些事情。因為某個實作細節換了位置而失敗的測試，只能告訴你有人做了重構。這種失敗累積到一定數量，團隊就不再讀失敗訊息，...
金融科技軟體開發在報價與排程上，跟一般軟體開發沒有兩樣，直到有人問出那句話：到底誰有資格持有這筆錢。從那一刻起，專案就不再是一道工程題，而變成一道帶著工程成分的監理題，你腦中原本的時程也不再站得住腳。 技術很少是難點。搬動資金是一個已經解決的問題，市場上有成熟的服務商、有文件齊全的介面，還有第一天就能用起來的測試環境。真正拖長金融科技專案的，是執照上的身分、面對稽核必須拿得出的軌跡義務，以及好幾個架構決定其實早已由持照方替你做完了。 決定你時程的問題： 你自己持照，還是以代理人身分掛在別人的執照底下營運，或者完全避開受監理業務？這三個答案會產生長度完全不同的專案，而差距是用等待的月數衡量，不是用開發的週數衡量。在做任何範圍規劃之前，...
MVP 軟體開發出錯的地方是範圍會議，不是開發過程本身。有人說出「最小可行產品」這幾個字，大家點頭同意，接著送來的功能清單裡卻寫著使用者帳號、後台管理介面、計費、通知、儀表板，還有一個行動應用程式。那不是最小可行產品。那是一個完整的產品，而它花掉的時間會是你心裡那個數字的三倍。 真正造成損害的字是「可行」。多數團隊把它讀成「好到可以賣給所有人」，但它的本意是「剛好夠用來判斷到底有沒有人想要這個東西」。 最省錢的範圍測試： 對每一項功能，問問自己會因為答案不同而做出什麼不一樣的事。如果一項功能改變不了任何決定，它就不屬於 MVP。後台管理介面不會告訴你人們是否想要這個產品；它只會告訴你，等人們想要之後，這個產品會更好管理。把它放到第二...