這段 refactory 簡直就是一個長征，先寫了一個有限狀態機，還久違的把遞回拿出來用了。

這段 refactory 簡直就是一個長征，先寫了一個有限狀態機，還久違的把遞回拿出來用了。 (我一向主張遞回只應天上有，凡人應該用迴圈。) 然後其次是把多重包裝超過一千行的函式重新 inline 解構，牽扯超過10個 entity ，要拆解其中的 one to one / one to many / many to many 的結構。 (隨著時間膨脹起來的中型 god object. ) 這十個 entity 加起來超過一百個欄位，部分是 runtime eval 來的，部分是資料來的。目標是極小化重複運算跟資料庫查詢，所以要小心翼翼的仔細拆出真正的大池(誰是線頭？)。 將欄位緊縮到最小的程度，準備回頭跟 db 直接掛肉粽一串對接，然後順便把某個目標的抽象化接點先準備好，為下一階段的功能準備好。 寫程式的時候，把握一個原則，我們是狗搖尾巴，不是尾巴搖狗，誰是主誰是從區隔要清楚。 另外從程式讀規格，「等價」的思考是很重要的，在數學上，等價必須滿足對稱性。在函式上，我也常取用這個概念。 換言之，我自己對於函式重構的最低標準，假設 A 跟 B 函式重構後，給定任意 input 兩者結果應相同。 (當然，重構過程有可能會是一邊功能修訂一邊進行重構作業，這種時候讀過 refactorying 應該都明白，每個 check point 都應該檢查等價與否，設好 check point ，切換帽子時心中的警報要響的夠大聲。) 最近常發現，把程式重構到新的面貌，原本的規格就能從程式碼上被清楚讀出來了。 我已經很久很久沒有重新打這種每個階段超過三小時，前後目前已經累計四個階段，估計後面還需要三個階段的大型重構戰場了。 印象中前兩次，一次是在我重寫車隊交易程序，讓六到八秒縮短到三秒。另一次是我把清算從要跑一個小時跟偶爾不穩定修成三分鐘內可以清算完畢。 一次花了我六個階段，一次花了我二十個階段。 大型重構考驗的是耐心，耐心，還是耐心，但走過去，真的就能說，結構上的感受會跟新的一樣。 這幾個修正都有一個特色，修之前跟修之後，程式能做到的事情都是一樣的，所以這也是多數人不願意投資時間在這些事情上的理由，但我們身為一個專業人士，什麼是品質，得有自己的羞恥感跟榮譽感。 以前曾經有人信誓旦旦跟我說，某功能某程式已經跑了好幾年，不會是他有問題，但我從外部症狀怎麼看最值得懷疑的都是他，結果我要求 pair 再仔細看了一次細節，結果發現有個資料處理邏輯的盲點，只改了六個字，讓該功能快了十倍，而且如果單指那點，有基本知識的人都不會反對那是問題。 問題在，人往往缺乏對核心事務追根究柢的精神，人看得見已經壞掉的東西，卻看不見平常大掃除的價值。 我不喜歡做這種大規模整理，因為實在是一個苦行，你要反覆推敲每一個零件的組成跟構成，是某種 3d 的空間拼圖，而且平常繁忙到沒有能夠好好想事情的時間也增加很多風險，但該開拔的戰場還是得開拔。 有些問題我的角度都是覺得，我不解決問題，問題就會解決我。一個資料系統，我們真正的戰場並不是老闆的要求，而是系統對資料的 flow ，資料是會有資料壓的，資料壓太強本身就會沖垮系統，所以需要建築提防跟疏通池保持資料完整，系統穩定。 逃避問題是沒有意義的，面對問題才是核心價值。 工作這麼多年，我還是很少碰到抱著相同價值的人，但那無妨，不管到哪我都會堅持下去的。 以前的主管說，我是他看過少數的天才之一，我覺得我不真的是什麼天才，我做的，不過就是把我這輩子多數的時間，都奉獻在產品思考上。我始終在苦思，苦行。 長征的痛苦還是持續的折磨著我，但這種痛苦也持續強大著我，到我們這個層次，問題都在對自我的管理，不是技術能力的實踐......... 我們的專業能力是為了解決問題而存在的，不解決問題，我們的專業就沒有任何價值，這是專業人士的自尊，也是專業人士的自傲。

原始 Facebook 貼文