我的公司在開發階段中，習慣以 rsync 將本機上的程式碼同步至 測試機 上運行。

因此替功能撰寫測試案例後，必須經過一些設定才能 遠端執行測試案例。

以下將提供 PHPStorm 遠端執行測試案例 配置步驟。

本篇文章紀錄自己導入 測試驅動開發（Test Driven Design） 過程中，曾經沒辦法分辨自己所寫的測試案例到底是“單元測試”還是“整合測試”，與同儕討論後發現其他人也有相同的困擾，於是看了幾本書與文章才釐清自己的問題所在。

在閱讀經典書籍《設計模式 Design Patterns》中，如果你跳過第 1 章引言，那你可能就錯過了設計模式的核心概念了！作者在引言中花了大篇幅講解 介面 在物件導向設計中的定位，以及設計模式如何透過 介面 來解決問題。

本文將帶領讀者建立 CodeIgniter 3 框架的 PHPUnit 測試環境，給 CodeIgniter 3 一個現代化的機會！

里氏替換原則（Liskov Substitution Principle）

定義

Subtypes must be substitutable for their base types.
-
子類別必須能取代父類別

里式替換原則是從 開放封閉原則 延伸出來的原則，若對開放封閉原則還不了解，建議先去瞭解開放封閉原則如何透過引入抽象來擴充程式碼的行為，再來學習里氏替換原則！

2019 年可以說是既充實又偷懶的一年。為什麼呢？因為花了很多時間在學習理論知識，包含：重構、整潔架構、單元測試、領域驅動開發、行為驅動開發 …等等。雖然每個知識看起來像是完全獨立的領域，但對 2019 的我來說，它們都是應付 Legacy Application 的利器。

為什麼又說偷懶？部落格和作品幾乎停擺！學習知識理論不像學習新技術，能把應用新技術的步驟分享到部落格上。因為理論知識必須經過堆疊和內化才能在真實專案中落地實踐。再加上這一年很榮幸受邀到高雄科技大學，帶領一批資工系的學生學習 PHP 式設計課程，備課與上課的時間幾乎吃掉了三個月的休閒時間，也就是平常能用來自學或練習的時間 …

開放封閉原則（Open-Closed Principle）

定義：

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
--
軟體中的類別、模組、函式等等應該開放擴充，但是封閉修改。

白話版本為：

當系統需要擴充功能時，應該藉由 增加新的程式碼 來擴充系統的功能，而 不是藉由修改原本已經存在的程式碼 來擴充系統的功能。

單一職責原則(Single responsibility principle)

定義：

A class should have only one reason to change.
以一個類別來說，應該只有一個引起它變化的原因。

”等等，這是在說人話嗎？還是我理解能力不夠好？“

這是我第一次讀到 SRP 原則定義的反應，當時覺得 SOLID 每個原則都是文字天書。若你也有跟我一樣的反應，不要緊張，大家都經歷過這個過程。我將會在本文中以自己的體悟來講解觀念，實務經驗演示如何實踐 SOLID 原則。

單一職責原則是 SOLID 原則中看起來最容易明白，卻也是最容易讓人混淆的原則。因為很多人並不清楚 職責 是什麼，甚至誤以為一個類別只能做一件事。接下來的文章中會依序講解原則的目的；解決什麼問題；如何實踐。

上一篇文章 軟體開發中的“無緒” 介紹了無緒的概念，講的是軟體開發的過程中，應該思考如何讓程式的使用者可以無緒。

這篇則是延伸無緒的概念，講解開發人員自學的時候，如何找出新技術背後的知識，並且堆疊知識。

無緒 (Cluelessness) 由 Martin Rinard 提出。他在演講時指出：

在開發和維護軟體系統時，應該避免讓開發人員深入了解系統。

因為人的大腦可以處理的資訊有限。若要建立一個日益變大的應用程式，就必須學習「如何讓每個開發人員在不了解整個應用程式的情況下，也能完成軟體開發」。