WadeHuang的學習迷航記

我的團隊在開發階段中，習慣以 rsync 將本機上的程式碼同步至 測試機 上運行。 因此替功能撰寫測試案例後，必須經過一些設定才能 遠端執行測試案例 。 以下將提供 PHPStorm 遠端執行測試案例 配置步驟，

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

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 的提交。 ​