寫得出來跟寫得好維護是兩件事。這系列每天拆一段真實的code,說明它為什麼難維護,再重構一次,並講清楚改完好在哪、代價是什麼。
主題涵蓋用高階函式取代手寫迴圈、消除可變狀態、攤平巢狀判斷、命名如何傳達意圖,以及什麼時候不該重構。每篇附前後對照與可執行範例。
寫出好維護的程式碼-如何透過高階函式降低程式碼閱讀負擔? 一、重構前 需求:檢查一批請求是不是全部都合法。 let everyRequestValid = tr...
昨天講的是迴圈的巢狀,今天講判斷的巢狀。 這兩件事表面上不一樣,但要解決的是同一個問題:讀程式碼的人,腦中同時要記住幾件事。 一、重構前 需求:算出使用者的折...
前兩天談的是結構——把迴圈的中間狀態拿掉、把巢狀的判斷攤平。今天談的東西沒有結構可以改,但它決定了讀者要不要「打開你的檔案」。 命名很難量化,所以多數文章只能給...
單一職責原則(Single Responsibility Principle) 「一個函式只做一件事」這句話幾乎沒人反對,但反問一句「那『一件事』到底怎麼算」,...
好維護的程式碼-Day04-函式該切多細講函式的邊界該切在哪。切好邊界之後,下一個問題是:這個函式跟外界溝通的窗口——參數列——該長什麼樣子? 今天從一個幾乎每...