自《重構──改善既有程式的設計》發行過後十幾年來,開發者對重構已耳熟能詳,開發工具也普遍支援重構手法,然而手法是其次,重點在於如何嗅出程式碼的臭味(Bad smell)與重構的方向。除了依賴經驗,若能借重函數式思考,不僅有助於程式碼的重構,有時,獲得的啟發會連帶重構解題方向,從而影響演算法的設計。

無副作用函式分解邏輯泥塊
函數式設計的出發點,多半是將問題分解為子問題,再將子問題分解為更小的子問題,直到子問題容易處理,如此處理子問題的函式,邏輯上就較為簡單,也容易驗證函式的正確性。

處理個別子問題的函式一旦完成,就可以在函式中組合這些子函式,而相關函式又會組合為更複雜的函式,從而解決整個問題。

在《重構》書中第一章的首個影片出租店案例中,率先重構的對象,就是Customer類別中冗長的statement函式。函式中的程式碼越長,就越容易包含複雜邏輯,也越容易包含貫穿函式前後的變數,變數狀態追蹤就越困難,從而越難理解程式碼內容。

Martin Fowler首先處理函式中的邏輯泥塊(Logical clump),重構既然是改善既有程式碼,若將既有程式碼視為問題本身,那麼從函數式角度來看,糾纏數個邏輯泥塊的冗長函式,絕對是值得大卸八塊而後快的對象。

在純函數式語言中,函式要根據引數計算結果,不能有副作用(Side effect)。

將此概念應用在重構上,就是查看某邏輯泥塊前後的變數或物件狀態,泥塊中引用到的變數,可考慮作為新函式的參數,泥塊最後的變數值或物件狀態,可以作為函式傳回值或函式執行結果,將泥塊移至函式中,並根據函式執行目的為函式命名,如此就可使用目的明確的函式,來取代邏輯泥塊。

在不具函數式特徵的語言中,不用強求函式中逐步演算都無副作用,可以函式為單位,僅要求以相同引數呼叫函式多次,都可得到相同的結果。

冗長函式中可重構的邏輯泥塊,明顯的,如if......else或switch組成的區塊、for、while迴圈結構,隱含的,如數句相關陳述句(Statement)組成的程式區塊,因為運算式(Expression)會引用變數計算出結果,有時,一條運算式也可能是提取為函式的對象。

因此,排版良好的程式碼很重要,面對冗長的程式碼,處理縮排於最內層的區塊,會是不錯的開始;兩層以上的縮排,暗示著可能處理了兩個以上的問題。

遞迴地分解迴圈問題

對於重複執行的動作,程式中可使用迴圈來解決。迴圈的本質就是變動的(mutable),也就是說,迴圈必然伴隨著變數值、物件狀態變化、輸入輸出等副作用。

在使用迴圈迭代一組冗長資料時,常容易基於效能等考量,在迴圈中順便作了些其他動作,使得迴圈常運用於同時處理多個問題,造成迴圈中的邏輯過於複雜而不易理解。經常地,迴圈中的程式碼往往是最難分解的邏輯泥塊。

必須使用迴圈解決的問題,基本上都可轉為遞迴來解決。在純函數式語言中,變數或物件狀態不可變動(immutable),因而不存在迴圈語法,重複性問題必須使用遞迴解決,這強制開發者必須思考使用遞迴解決問題時,哪些條件下會停止、哪些單元必須在同一遞迴階段處理、哪些單元必須畫分至下一遞迴階段解決,每個單元需要的資料與傳回值為何,因而強迫開發者,必須將問題中的重複動作為分為子問題。

面對既有程式碼具複雜邏輯的迴圈,改從遞迴角度思考,可讓迴圈中邏輯泥塊間的界線自然浮現。

舉例而言,除了無窮迴圈外,迴圈基本上都有停止條件,轉為遞迴思考時,就必須將迴圈停止條件辨識為遞迴停止條件。如果迴圈中有多個停止條件,遞迴地思考會強制開發者思考,將相關的停止條件群組在一起。

如果歸類出兩組以上的停止條件,通常代表此迴圈可以拆解為兩個以上的迴圈,從而設計出兩個以上的遞迴函式,也就是原先的迴圈中同時處理了兩個以上的子問題。一個函式中的程式碼只處理一個問題,子問題應交由子函式來解決,重構要求達成這個目的,函數式也要求如此思考。

如果可用遞迴來思考迴圈問題,那麼既有程式碼中出現巢狀迴圈,就代表它處理了兩個以上的問題,此時可將內層迴圈重構為函式,然後再以其為基礎將外層迴圈重構為函式。

如果將迴圈重構後,發現兩個遞迴函式間交相呼叫,這暗示著原本演算法較為複雜而可重新設計。

例如:a函式呼叫b函式,b函式計算出某值用以呼叫a函式。由於函數式思考重點,是將問題分解為子問題,既然b函式作了「計算某值」、「呼叫a函式」兩件事,何不重構演算法,設計b函式將a函式需要的值整組計算出來,讓b只作一件事,僅讓a函式針對計算出來的整組值進行遞迴。

分解問題是重構及函數式共同出發點
函數式的重點在於將問題分解為子問題,無副作用與遞迴只是實作時外在的形式。重構的重點在於將程式碼區塊分解為更小的獨立區塊,如此大函式就會生出小函式,如果小函式依舊複雜,運用相同手法就可分解出更多的小函式,這看似簡單的分而治之(Divide and conquer)觀念,其實是重構與函數式的共同出發點。

舉例而言,程式中最難聞的臭味之一,就是重複的程式碼。複製程式碼就是一種訊號,當開發者打算將函式中某段程式碼,複製至另一函式時,就意謂著兩個函式處理了相同的子問題。如果函式早已分解出許多子函式,那麼就可用呼叫子函式來取代程式碼複製。反過來說,既有程式碼中兩個函式具有相同程式碼區塊時,就意謂著當初個別面對問題時,沒有仔細思考是否可分解出子問題。

除了完全相同的程式碼重複外,另一種重複是流程結構的重複。有些流程結構重複較易察覺,有些流程結構就不是那麼容易辨識。例如,從一組學生中取得分數列表,以及從一疊專輯裡面,取得各專輯中長度最短的歌曲名稱列表,兩者間其實存在相同的流程結構。

函數式的思考方式有助於函式更徹底的分解,當子函式處理的問題夠集中,程式碼的流程結構就夠簡潔。有時,在這些夠簡潔的小函式中才能發現,它們具有相同的流程結構,從而讓開發者意識到這些子問題間,在某些抽象層面上是相同的,只是因為面對的子問題略為不同,使得流程中少部份必須具體處理。如果必須具體處理的部份,可以當作函式的引數傳入,那麼這些小函式就可以抽象化為單一函式,獲得更高的重用性,也讓開發者下次面對問題時,可用相同抽象層次來思考解決方式。

函數式地思考,命令式地實作
當面對複雜問題不知如何重構時,函數式思考是一種啟發,因為面對問題時都分解為子問題,使得子問題間的同質性顯露出來,察覺這種同質性才是函數式思考的目的。

如果語言具備函數式語言的特徵,結合函數式思考來重構,可更善加語言中的函數式特徵。在不具備函數式特徵的語言,亦不用勉強在實作上全面採用函數式,只要在以函數式思考獲得啟發後,讓實作具備函數式的精神。

例如,在基於可讀性或效能等考量下,只要區域變數存在於夠精簡的函式中;就不一定得是不可變動;如果物件狀態改變只限於短函式中,物件也可以是可變的;若迴圈簡短且僅處理單一問題,亦不見得要以遞迴取代。

 

作者簡介


Advertisement

更多 iThome相關內容