作者:郭任超/ 有勁生物科技

 

隨著科技的進步與雲端數據應用的普及,未來在這個領域,如同英文溝通能力於商務領域那樣,具備基礎的程式撰寫能力也將會是必備的基本技能。學習程式編碼(coding)也是一種訓練利用邏輯進行思考及解決問題的方法。透過良好程式撰寫習慣的養成,不但可大大提高工作效率,也可減少不必要的失誤。

 

1. 事前規劃

    著手撰寫程式之前,先規劃好程式執行的流程,將實際需求拆解成幾個比較小的「User story」;從使用者的角度來建立需要實現的功能,並以此推估所需的時間成本,同時注意各個story之間的相依性。針對比較複雜的數據結構、物件或子程序,則可利用圖形來輔助說明 (ex.使用UML來繪製),比單純用文字描述要好。

 

2. 模組化

    把複雜的大問題拆成數個容易解決的小問題來一一處理,之後再將解決方案彙整,讓大問題變得更容易解決,這整個流程就是模組化的一種過程。

    通常模組化的做法是把處理共同問題、或具有相同行為的函式 (Function) 依照相似性進行分組,集合成一個類別 (class)。各類別皆遵循單一職責原則 (Single Responsibility Principle),一個類別只負責一個responsibility,實作上盡可能依照Robert C. Martin所說的每個類別應該僅有一個可變因素(A class should have only one reason to change)的原則,來進行職責的分配。如此一來,未來針對某一類別進行相應的更新或加入額外需求時,便不會因一個職責相關的改變,而牽連到其他程式碼,破壞了整個系統的運作,從而可達成高內聚、低耦合的目的。當所有職責都有適當的區分時,程式也會變得更容易擴充與維護。

 

3. 不要重新發明輪子

“Don't Reinvent The Wheel”(不要疊床架屋)的意思是說,如果已經有大家都公認不錯的程式碼或函式庫,很多情況下就足以應付多數需求,不需要再重頭建構,以免浪費無謂的時間。

    對於經常出現的問題,我們可利用已有的軟體資源:例如數據資料、程式結構、設計模式、軟體工具與軟體環境等,來提高程式組件的重覆利用性。此外,功能函式也要盡量提取出來,不要全部寫在同一支程式裡。

 

170414_1.png

 

4. 程式碼的可讀性

    程式碼的撰寫原則是要讓使用者在短時間內就能理解並弄懂。但對大部分撰寫者來說,可能覺得程式只要能正常執行就好,而選擇忽視程式碼編排與重要規範,想要留待日後有時間再來整理,但這些都將造成之後維護的困難與耗費許多額外的除錯時間。

    改善程式的可讀性有許多途徑,像縮排分段、名稱命名、註解以及利用區塊及函式組織程式碼等等幾個基本項目都是。

a. 適時調整縮排與斷行,每行程式碼以80個字元為基準。適當的程式碼寬度不但方便閱讀、不用擔心被使用端(terminal) 的編輯器自動換行,還可顯著增加排版上的美觀。 

b. 命名規則要始終一致,並使用有意義的名稱,讓閱讀的人很容易從名稱就可以了解該函式與變數的功用及意圖。

c. 將變數的作用域限縮到最小,只有在需要使用變數時才宣告及初始化,並盡量減少使用全域變數,改採函式閉包 (Closure) 或物件,來降低不同模組及函式引用時,因變數名稱重複所導致的命名污染。

d. 利用註解來描述作者想法、解釋晦澀難懂的演算法、或是紀錄程式碼的缺陷。註解應保持語意的精確與簡潔,使程式碼更容易理解。但若程式碼本身就已足以讓人了解用途,那麼不加註解反而比較恰當;要知道:一個好程式比「壞程式加好註解」更好

e. 透過類別和函式將程式所需的功能切割及封裝,一個函式只做一件事,且函式的語句結構要越簡單越好。有需要運用同樣功能時,只要透過引用類別並呼叫函式便可達到目的,如此才能有效提高重複利用率,並有利於維護。

f. 確立共同的規則和術語,開發中的交流和協作都需要有共同慣例和詞彙基礎,如此便可加快開發速度,並降低維護的困難度。

 

5. 版本控制

    軟體開發過程中,版本控制系統有助追蹤過程、對檔案文件差異進行快照/同步/合併/回復先前狀態,發生問題時,也方便藉由查看時間點或開發者提交的修改項目來找出原因所在。如此,即便是一人開發,也能夠輕鬆維護開發環境。

 版本控制,一般人常見做法就是檔案一有新的變更就複製一份存放,再以不同檔案名稱命名。一開始可能還記得哪裡做了更動,但過了一段時間,程式碼越來越多,甚至連上一次的更動都想不起來了。在許多人共同開發情境下,即使每次都是從共同存放的位置取出檔案修改,可是當修改後上傳時,如何確保同時間沒有其他人也在上傳檔案,這時候互相覆蓋檔案的情況就很可能發生。

    目前流行的分散式版本控制系統,例如Git、Mercurial,開發者可以同時扮演貢獻者,以及擔任接受其他開發者提交程式碼的公共儲存庫;儲存庫之間也能互相傳送,並透過不同的工作流程,靈活協作方式。

    而根據開發需求還可以建立不同分支 (branch),例如:在進行除錯的同時也想添加實驗性的功能特性,那麼就可以建立分支來區隔不同的工作,如此便不必擔心改到同一個檔案。我們可以在不同分支之間反復切換,在確保已完成的分支特性通過測試後,就可將不同分支合併,發佈或進行下一階段的開發。

 

170414_2.png

 

6. 重構

 重構 (refactoring) 主要目的就是為了提升程式碼的可讀性,或簡化結構、清理冗餘無用的組件,這些都是在不影響程式原有行為的原則下進行,讓日後的因應修改或擴充更加容易。

什麼時候該考慮重構?其實,重構是開發過程中隨時隨地都在進行的,為的是讓後續開發更容易進行,而不是特別另外安排時間來做的工作。對於何時進行重構則沒有精確的規範,在開發過程某些適當時機點就可以搭配重構一起進行;例如:

a. 添加功能的時候
當原本的設計方式無法讓我們依照需求添加新功能時,程式碼就必須做調整以改善現有設計。

b. 修復錯誤的時候
程式碼有錯誤,通常代表設計不合理,或是對程式碼誤解所導入的程式錯誤。透過除錯的過程重新理解程式碼之後,就知道如何用更簡單易讀的方式改寫程式碼。

c. 審核程式碼的時候
審核程式碼有其重要性,通常由審核者檢視程式碼,找出開發者思慮不周全的部分,並提出修改建議。

d. 三次法則 (rule of three)
此一法則由Don Roberts所提出,是程式碼重構的經驗法則。其要求是,當程式碼片段重複時,允許直接複製貼上程式碼一次,但如果相同片段重複出現三次以上的時候,就必須將之提取出來做成一個子程式。

 

7. 持續不斷學習

    資訊技術進步非常快,平常可以多參考別人公開的原始碼、學習新語言、了解目前發展趨勢,不要滿足於單一種程式語言及開發環境,藉由持續吸收新知來維持思想上的開放與活力。

 

 

參考文獻:

Robert C. Martin. (2011). The Clean Coder: A Code of Conduct for Professional Programmers. (Prentice Hall)

Dustin Boswell, Trevor Foucher. (2011). The Art of Readable Code. (O'Reilly Media)

Scott Chacon, Ben Straub. (2014). Pro Git , 2nd ed. (Apress)

Martin Fowler, Kent Beck, John Brant, William Opdyke, don Roberts. (1999).  Refactoring: Improving the Design of Existing Code. (Addison-Wesley Professional)

 

官網用CC創用_SA.png

 

 

 

 

arrow
arrow

    Yourgene Health 發表在 痞客邦 留言(0) 人氣()