發表文章

目前顯示的是 5月, 2019的文章

CodeIgniter 框架擴展:HMVC

圖片
CodeIgniter 框架擴展:HMVC Hierarchical((階層式的))-Model-View-Controller(HMVC)模式,也可以叫做 Layered MVC。 為什麼需要 HMVC 單層 MVC 的限制 原 MVC 架構中只有單層 MVC ,單層 MVC 的設計本身沒問題,但隨著系統功能漸變多變複雜時,程式碼卻只能塞進單層 MVC 裡面,程式碼很快就會變得  巨大、縱錯複雜、互相耦合、難以維護 。試想一下,一個 Controller 內有 7、8 千行程式碼會容易維護嗎。 原 CodeIgniter MVC 架構(單層 MVC)示意圖: application |- controllers |- controllersA.php |- controllersB.php |- ...(所有 Controller 都只能放在同一層) |- models |- models1.php |- models2.php |- ...(所有 Model 都只能放在同一層) |- views |- views1 |- index.php |- footer.php |- ... |- views2 |- index.php |- footer.php HMVC 帶來的解決方案: 擴展 MVC 架構, 讓 MVC 底下可以再擴充一層或多層子 MVC ,讓單層 MVC 變成階層式 MVC,而這些擴充出來的 MVC,又稱作為模組、模塊(Modules)。 使用模組好處是: 使每個功能都可以獨立出來 因模組變得獨立,降低各個功能模組之間的耦合性 提高程式碼複用性 每個模組都有自己的 MVC 結構 HMVC 架構示意圖: CodeIgniter HMVC 擴展模組後,其結構(階層式 MVC)如下: application |- modules |- moduleA

重構的定義與目的

重構定義: 在不改變軟體外部行為的前提下,改變其內部結構,使其更容易理解且易於修改。 目的: 重構的主要目的就是為了提升程式碼品質、 提升程式碼的可讀性 ,以及為了日後有新需求的變化時,程式碼可以 更容易修改或是擴充 (提高可維護性)。 優點: 1. 改進程式碼的設計: 消除重覆的程式碼,每個小功能被歸責到適當的物件中,讓程式碼的職責更清楚就會更容易維護。 將雜亂無序的程式碼,重構成一連串的 精心設計 的流程,讓程式碼更容易擴充。 2. 程式碼更容易被理解: 重構簡單的講,就是整理程式碼,可以透過 Clean Code 的規範 來整理程式碼,提升可讀性。 想想程式碼過一段時間後的第二個讀者,而且這個人常常是你自己。 3. Debug 更容易: 重構的過程中,會透過單一職責原則,依照程式碼的工作責任將程式碼整理至責任相同的類別中。有責任清楚的物件,就能更快釐清問題點,除錯速度自然能夠提升。 什麼時候可以開始重構? 事實上,重構並不是一項需要額外撥出時間來進行的工作, 重構應該是在你的開發過程中持續在發生的事情 。 重構的活動,最理想的情況,就是透過持續不斷的整理,掃除那些有礙程式可讀性及可維護性的程式碼,讓程式碼持續盡可能地保持在一定健康的狀態。 既然重構是一個持續進行的活動,但又不是特意安排、特別撥出時間來做的工作,那麼,在什麼樣明確的時間點,應該觸發重構的進行呢?基本上, 重構的活動應該伴隨著我們一般開發過程中的主要活動來進行。這些主要活動包括了:增加新功能、修正錯誤、以及程式碼審查的時候,還有三次法則 。 三次法則: 同樣的事做三次,犯了 Don’t Repeat Yourself 原則,表示重複的邏輯該被重構成唯一且適當的物件或函式了。 新增功能時重構: 當我們試著增加新功能時,便有可能發現舊有的程式碼可以進行一些調整,而達成了必須重構所想要達成的目的。 但如果你在增加功能的時候,發現原設計就足以優雅地讓你將新功能擴充上去,那麼,這意謂著,還不太需要做什麼重構。 除錯時重構: 除錯的時候,你不僅會接觸到舊有的程式碼,而且,你通常得搞懂它真正的運作邏輯,當你真的懂了之後,就會知道如何用更清晰、簡潔的方式來改寫這段程式碼。 總結: 很多架構良好的程式,

如何處理已經 Push 的 Commit Message!

圖片
這種已經推(push)上來的沒辦法更改 Commit Message 跟內容  怎麼辦! 這種情況我會直接重切一條新的分支,重寫 Commit,底下是主要步驟: 把這幾次 Commit 的異動暫存(stash)起來 從開發前的 Commit 切新分支(for 重寫 commit 用) 把暫存(stash)的檔案套用到新分支 開始重寫 Commit 做完 Commit 就把新切出來這條分支上傳回自己的 Repo,重發 Merge Request。 第一次做可能不熟,所以底下是每個步驟截圖: 步驟看起來很多,但做熟的話其實就只有幾個主要步驟而已,會越做越快! 1. 把這幾次 Commit 的異動暫存(stash)起來 2. 從在開發前的 Commit 切新分支(for 重寫 commit 用) 3. 把暫存(stash)的檔案套用到新分支 4. 開始重寫 Commit ​

Gitlab 合併請求 Merge Request 是什麼?

圖片
Gitlab 合併請求(Merge Request ) 一般在團隊開發的時候,為了避免工程師直接對主要 Repo 進行修改,會要求工程師從 專案的主要 Repo 複製一份這個專案的副本(Fork)回來工程師的電腦進行開發/除錯。 工程師開發完成後,如果要把電腦上最新版本的程式碼上傳回 專案的主要 Repo ,就必須對 專案的主要 Repo 發送一個 合併請求 ,請 專案的主要 Repo 管理員進行程式合併。 當合併請求發送出去後, 專案的主要 Repo 管理員可以在管理頁面上看見你的合併請求,這時管理員會進行一次 Code Review,管理員覺得程式沒問題,就會將工程師的程式合併回主線。 若管理員覺得這段程式碼有問題,也可以 Close 這次的 Merge Request 。 另外 Merge Request 等同於 Github 的 Pull Request   - 可參考:  與其它開發者的互動 - 使用 Pull Request(PR) 上述流程如下圖: ​

Git 開發流程

圖片
Git 實際開發流程 真實開發的時候,除了有 Gitlab 上面的  主要 repo 、 自己的 repo 以外,還會有一份在本機開發的 本地 repo , 這份 本地 repo 是從 自己的 repo Clone 回來的。 注意 :底下步驟 1 除了從主線 pull 最新版本的程式回來,也可以直接從主線切一條分支出來做開發(推薦後者) 推薦後者(直切從主線切出一條分支出來做 issue)的原因是: 實務上開發的過程中,一個工程師可能會同時掛多個 issue。假設突然出現一個緊急的 issue 時,你可以從主線再切一條新分支,用來處理緊急的 issue。把緊急的 issue 處理完成後,在切回原本開發的 issue 分支繼續原來的工作!這是前者辦不到的。 以下是 Git 實際開發的流程: 一般要開始做 issue 前,就會先從主線拉(pull)一份最新版本的程式(code base)回來做開發, 開發的過程可能會有多個檔案被異動,也可能經歷多次 commit。 開發完成後,為了避免與別人 push 回主線的程式碼發生衝突,一定會先做一次 Pull, 注意: 做 Pull 時 Git 會自動幫你 Merge,這時會有以下幾種情況發生 : Git 自動 Merge 成功,不發生衝突。 Git 自動 Merge 失敗,發生衝突,需要你手動處理衝突。 不管有沒有發生衝突,Merge 完後都會有一次合併程式的 Commit((合併程式也算異動))。 做完 Pull & Merge 後,就可以把最新的 commit 推(push)回主線,完成本次 issue 的提交。 ​

Git Commit Message 這樣寫會更好,替專案引入規範與範例

圖片
Commit Message 跟寫程式註解還蠻像的, 最好可以寫下「為什麼」你要作這樣的異動, 而不是單單只記錄下你做了「什麼」異動。 Commit Message 最好兼俱 Why 及 What,讓日後進行維護人員更快進入狀況。 Commit Message 這樣寫會更好: 做 issue 的時候,不應該一次 Commit 所有異動!應該獨立 Commit 每個不同意義的異動,這樣 commit 訊息才會跟異動的程式碼有關聯。 每次 Commit 都是針對異動的檔案做說明:Why & What。這樣的 Commit Message 能讓日後的維護人員更快進入狀況 每次 Commit 都加上 issue 編號,方便追蹤相關的程式異動原因。 若 Commit Message 寫得妥當,在閱讀追蹤程式碼的意圖會相當容易。如果只把 Git 當作版本控制,隨意撰寫 Commit Message 就太可惜了! 不能只把 Git 當作程式碼的 FTP,要把 Git 當作歷史查閱的工具才拿發揮 Git 的功能。 好與不好的真實案例 用一個小插曲證實 Commit 訊息的重要性 上面 PPT 是我在工作中遇到的兩個案例,範例中包含「好的 Commit Message」與「不良的 Commit Message」。 在範例中可見: 良好的 Commit Message: 如何在「一年後」讓維護人員進入狀況 不良的 Commit Message: 如何在「一個月內」讓維護人員找不出程式異動的原因 。 Commit Message 之規範 在撰寫 Git 與 SVN 等版本控制軟體 Commit Message 時,可以參照國外 AngularJS 團隊的規範: AngularJS Git Commit Message Conventions 以下為這套訊息規範的展示與說明: Commit Message 規範範例: Commit Message 規範範例解析: Commit Message 規範組成: Header: < type > ( < scope > ): < subject > - type: 代表 commit 的類別:feat, fix, docs, sty