文章

目前顯示的是 五月, 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 |- controllers …

重構的定義與目的

重構定義:
在不改變軟體外部行為的前提下,改變其內部結構,使其更容易理解且易於修改。 目的: 重構的主要目的就是為了提升程式碼品質、提升程式碼的可讀性,以及為了日後有新需求的變化時,程式碼可以 更容易修改或是擴充(提高可維護性)。 優點: 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, style, refactor, test, chore,必要欄位。 - scope 代表 commit 影響的範圍,例…