程式設計教學

技術盡職調查不是一場程式碼品質比賽，而準備接受查核的團隊，通常把時間花在最不相干的地方。沒有人是為了替你的抽象層打分數才來買一家公司。買方想弄清楚的其實只有兩件事：擁有這套系統要付出多少代價，以及在資金易主之後，情況可能壞到什麼程度。 換一個角度看待這件事之所以重要，是因為它會改變你該優先處理什麼。醜歸醜但跑得動、團隊看得懂、可以安全修改的程式碼，只是一則輕微的查核結果。反過來說，寫得漂亮卻只有一個人看得懂的程式碼，才是嚴重的查核結果，而真正牽動價格的，向來是後者。 所有問題背後的那個問題： 如果創辦工程師在交割後的隔週離職，這套系統還跑得下去，而且還改得動嗎？幾乎每一項會壓低出價的查核結果，都是對這個問題的具體回答。知識全積在一個...

資料庫效能的排查工作，通常從有人提議換一台更大的執行個體開始，又通常以這樣一個發現收場：每次載入頁面時，有一條查詢都在對 400 萬列做循序掃描。瓶頸從來就不是硬體，瓶頸是執行計畫。 這個模式重複得夠穩定，值得當成預設假設寫下來。當應用很慢而資料庫又很忙時，原因幾乎都是少數幾條特定的查詢，而不是整體容量不足；把機器換大，只能把問題掩蓋到資料表再次長大的那一刻為止。 動手改之前，先量。 憑猜測去最佳化一條查詢，正是團隊花掉整整一週新增索引、結果寫入變慢而讀取一點也沒變快的原因。任何資料庫都能告訴你哪些語句消耗的總時間最多。從那裡開始，修掉排在最前面的那一條，然後再量一次。這樣反覆兩三輪，事故通常就結束了。 資料庫效能始於找出那條查詢總...

談到軟體測試策略，大家幾乎都從覆蓋率說起，而覆蓋率偏偏是整個領域裡資訊量最低的一個數字。一個覆蓋率達到九十的程式碼庫，照樣可能在最常被走到的路徑上把缺陷送上線，因為覆蓋率量的是測試執行期間有哪些程式碼行被跑過，而不是有沒有針對這些行做出任何有意義的斷言。 真正信任自己測試套件的團隊，並不是覆蓋率百分比最高的那一群。他們是這樣的團隊：東西真的壞掉時測試會亮紅燈，其餘時候測試安安靜靜。這個特性，比多數人想像的更難用錢買到。 對任何一個測試都值得問的問題： 如果它失敗了，我知道該怎麼辦嗎？因為行為改變而失敗的測試，會告訴你一些事情。因為某個實作細節換了位置而失敗的測試，只能告訴你有人做了重構。這種失敗累積到一定數量，團隊就不再讀失敗訊息，...

金融科技軟體開發在報價與排程上，跟一般軟體開發沒有兩樣，直到有人問出那句話：到底誰有資格持有這筆錢。從那一刻起，專案就不再是一道工程題，而變成一道帶著工程成分的監理題，你腦中原本的時程也不再站得住腳。 技術很少是難點。搬動資金是一個已經解決的問題，市場上有成熟的服務商、有文件齊全的介面，還有第一天就能用起來的測試環境。真正拖長金融科技專案的，是執照上的身分、面對稽核必須拿得出的軌跡義務，以及好幾個架構決定其實早已由持照方替你做完了。 決定你時程的問題： 你自己持照，還是以代理人身分掛在別人的執照底下營運，或者完全避開受監理業務？這三個答案會產生長度完全不同的專案，而差距是用等待的月數衡量，不是用開發的週數衡量。在做任何範圍規劃之前，...

MVP 軟體開發出錯的地方是範圍會議，不是開發過程本身。有人說出「最小可行產品」這幾個字，大家點頭同意，接著送來的功能清單裡卻寫著使用者帳號、後台管理介面、計費、通知、儀表板，還有一個行動應用程式。那不是最小可行產品。那是一個完整的產品，而它花掉的時間會是你心裡那個數字的三倍。 真正造成損害的字是「可行」。多數團隊把它讀成「好到可以賣給所有人」，但它的本意是「剛好夠用來判斷到底有沒有人想要這個東西」。 最省錢的範圍測試： 對每一項功能，問問自己會因為答案不同而做出什麼不一樣的事。如果一項功能改變不了任何決定，它就不屬於 MVP。後台管理介面不會告訴你人們是否想要這個產品；它只會告訴你，等人們想要之後，這個產品會更好管理。把它放到第二...

凡是按端點數量來估算客製化 API 開發成本的人，幾乎都會算錯，而且通常差三倍。端點本身是整件事裡最便宜的部分：十來個端點，只是讀寫你手上已經有的資料，對一位稱職的後端開發者來說不過是兩週的活。 真正花錢的，是把這些端點變成另一家公司願意把生意押上去的東西所需要的一切：經得起安全稽核的驗證、讓你日後還能改主意的版本管理、好到沒人需要寫信問你的說明文件，以及能告訴你哪個客戶今天早上過得不順的維運裝置。有一個 API，和有一個別人靠著它做生意的 API，兩者之間的那道落差，才是預算真正的去處。 價格區間速覽: 只被你自己的應用程式呼叫的內部 API，通常花費 10,000 到 30,000 英鎊。...

採購 COBOL 現代化服務，和買任何其他軟體工作都不一樣。要動的那套系統已經跑了三四十年，公司裡現在沒有一個人完全弄得懂它，而做壞了的代價不是錯過幾個迭代，是法遵申報出問題。與此同時，擺在你桌上的幾份提案承諾的結果一模一樣，報價卻差了好幾倍。 這篇文章講清楚一份認真的合作究竟包含什麼，幾類供應商之間的差別在哪裡，以及哪些問題能把建立在證據上的報價，和建立在樂觀上的報價分開。它假設你就是事後必須為這個決定提出說明的那個人。 該看什麼： 一份可信的 COBOL 現代化提案包含現況盤點、目標架構設計、資料遷移、程式碼轉換或重新託管、以比對為核心的測試計畫、平行運行、切換規劃以及知識移轉。只替程式碼轉換標了價的報價，不是一份專案計畫，它只...

決定聘請一位 C++ 開發者，通常是帶著一個具體問題來的。某個東西必須夠快，或者必須跑在硬體上，或者必須對接一個只提供原生介面的函式庫。隨後展開的招聘流程，往往把 C++ 當成一項單一技能，而這個假設正是大多數失望結果的源頭。 C++ 不是一個職位。一位出色的遊戲引擎程式設計師，在嵌入式韌體上可能真的做不出東西；一位低延遲交易專家，可能這輩子沒交付過一個圖形介面應用。三個人都是優秀的 C++ 開發者，但只有一個適合你的專案。 一句話版本： 在發布職缺之前，先確定五個 C++ 專長方向裡你真正需要哪一個，因為技能的移轉遠比職稱暗示的要少。英國的合約日價按領域大致在每天 400 到 900 英鎊之間，而考察時最有用的訊號，是候選人依靠工...

第三方 API 整合是商用軟體裡被低估得最穩定的一類工作。文件讀起來清清楚楚，供應商提供了用戶端函式庫，於是有人說兩週。六週之後，團隊還在爭論：當一個 Webhook 為一筆已經退款的訂單第二次送達時，究竟應該發生什麼。 這道落差不是能力問題。真正的原因在於，一次整合裡有意思的部分從來不是請求和回應，而是當對方系統做出它的文件從未描述過的行為時，隨之而來的一切。它一定會這麼做，因為它是一個活著的產品，屬於一群有自己路線圖、對你的發布計畫不承擔任何義務的人。 經驗法則： 只從一個服務拉取資料的唯讀整合，通常需要一到三週。會寫入交易的整合需要三到六週。兩邊都允許編輯的系統之間的雙向同步需要六到十二週，而且永遠不會真正結束，因為衝突解決是...

需要聘請 Qt 開發者的公司，通常在做一件必須跑在機器上而不是瀏覽器裡的東西：一塊儀表板、一個診斷工具、一個為別人都不願支援的硬體所寫的控制程式。候選人的池子只有網頁市場的一小部分，詞彙體系不同，平常那些招募捷徑在這裡也不管用。一個只按「C++」篩選的獵才顧問，會送來一批從沒寫過一行 QML 的人。 本文說清一位稱職的 Qt 工程師究竟掌握什麼、這個職位在 2026 年要花多少錢、如何檢驗真正重要的能力，以及在寫下任何程式碼之前就該定下來的授權問題。最後這一點，正是昂貴錯誤最容易發生的地方。 開始之前： Qt 人才稀缺且高度專業化，所以要預期高於一般 C++ 的價位，也要預期更長的招人週期。請先把授權立場定下來，因為在開源版本與商業...