2019 回顧工作與學習歷程

2019 回顧前言

2019 年可以說是既充實又偷懶的一年。為什麼呢？因為花了很多時間在學習理論知識，包含：重構、整潔架構、單元測試、領域驅動開發、行為驅動開發 …等等。雖然每個知識看起來像是完全獨立的領域，但對 2019 的我來說，它們都是應付 Legacy Application 的利器。
為什麼又說偷懶？部落格和作品幾乎停擺！學習知識理論不像學習新技術，能把應用新技術的步驟分享到部落格上。因為理論知識必須經過堆疊和內化才能在真實專案中落地實踐。再加上這一年很榮幸受邀到高雄科技大學，帶領一批資工系的學生學習 PHP 式設計課程，備課與上課的時間幾乎吃掉了三個月的休閒時間，也就是平常能用來自學或練習的時間 …
。
至於工作呢？這份工作是我搬來高雄的第一份工作，工作內容主要是維護一個大型的 Legacy Application。雖然說是維護，但仍不斷有新需求一直進來。這也是為什麼我必須花費很多時間閱讀如何處理 Legacy Application 的相關書籍和技術。很慶幸我也有機會將學到的知識導入專案中，增加部分功能的彈性；或是阻止部分功能繼續腐敗。改善程式碼品質的成就感讓我更多的動力繼續學習。
可惜 2019 對我來說是一眨眼就結束，到年尾了還來不及紀錄下學習與實踐的東西。所以想先以流水帳的形式紀錄一下 2019 年所學的知識和工作中實踐的技術。
　　

自學主題

DDD《領域驅動設計》

在 1 月準備系統重構流程的過程中，覺得自己對於「領域模型」不夠瞭解，因此決定拜讀一下《領域驅動設計》，增進自己對領域模型的認知。
DDD 是一個開發論，涵蓋的領域很多，可以說是納入各個程式設計層次的最佳實踐，包含：設計模式、DDD 四層架構（戰術設計）到多個系統間如何劃分邊界（戰略設計）。也因為 DDD 以多種層次來探討程式應該如何「設計」，讓我的思維直接上升好幾個層次，看待程式碼的視角變得更廣、更高階。
DDD 四層架構，透過隔離每一層讓程式碼可以適應變化
DDD 可以說是繼 SOLID 原則後影響我很深的知識，以前的思維只停留在物件與物件之間， DDD 讓我見識到系統架構如何應用「良好的程式設計」來應對變化，引起了我對系統架構的興趣。不過 DDD 對當時的我來說仍然有很多看不懂的部分（尤其是戰略設計），目前規劃 2020 年會再回來鑽研一次！
　　 　　

《Clean Architecture》

《Clean Architecture》本來並不在 2019 的書單裡面，但是在學習 DDD 的過程中發現不斷有人拿 Clean Architecture 的架構來跟 DDDLite 架構做比較，這才引起我對 Clean Architecture 的興趣。
很幸運地，這又是一本可以讓程式設計思維提升好幾個層次的好書！Clean Architecture 可以說是物件導向設計 SOLID 原則的延伸，如果說 SOLID 是指導開發人員如何設計物件，那麼 Clean Architecture 就是指導開發人員如何將多個物件組織起來，並且用一套清晰易懂的規則讓物件與物件彼此協作，完成系統需求所需的功能。
Clean-Architecture-graph
整潔架構中，依照程式的重要程度來劃分層級：
越核心的邏輯越往內圈靠，容易變化的附加邏輯則越往外層靠。
越內圈的邏輯層次就越高（層次高表示彈性高），最內圈屬於業務規則的核心策略；外圈則是圍繞著核心業務規則並隨著需求不斷變化的 機制。這樣劃分的原因是，系統必須保持核心業務邏輯的彈性來因應多變的需求。內圈的程式碼彈為了保持彈性，也會引入較多的抽象；外圈的程式碼則是按需求所需，透過實作內圈公開的抽象來存取或擴充核心業務規則，以完成需求所需的功能。
除了分層以外，還需要遵循「相依性規則」：
原始碼依賴關係只能指向內部，朝向更高層級的策略。
這裏指的是，內圈不能知道外圈的存在。包含外圈的變數、類別、函式。只要在內圈看到 import 或是 using 引入外圈的東西就代表違反了規定。這樣的好處是可以將 策略 與 機制 隔離開來。身為一個開發人員必須意識到，將 策略 和 機制 寫在一起是很致命的錯誤！因為 機制（如 UI 介面）的需求變動頻率很大，而且有很大的機率修改到 策略（核心業務邏輯）的程式碼。為了避免 策略 被影響，應該隔離 策略 與 機制，這麼一來被隔離開的程式碼會以不同的速率和原因被修改，並且不會影響到彼此的程式碼。
另外，Clean Architecture 架構的同心圓並不一定要是 4 圈，4 圈只是作者為了方便講解層次而已。
最重要的是要做到「隔離策略與機制」和「遵循相依性規則」!

開發人員必須防止程式碼腐敗

手頭上的 Legacy Application 到處都可以看見“參數很多且內容包含大量 if 或 switch 的大函式”，例如：
class StudentModel extends Model
{
    private $db;

    /** 取得學生列表 */
    public function studentList($classId, $homeworkId = null, $bicyclePassYear = null, /** ... 省略 */)
    {
        $this->db->select('*');
        $this->db->join('homeworks', 'students.id = homeworks.studentId');
        $this->db->leftJoin('bicyclePass', 'students.id = bicyclePass.studentId');
        $this->db->from('students');

        // 回家作業繳交狀況列表
        if ($homeworkId != null) {
            $this->where('homework.id', $homeworkId);
            $this->where('homeworks.status', 'done');
        }

        // 腳踏車證繳費記錄列表
        if ($bicyclePassYear != null) {
            $this->db->where('bicyclePass.year', $bicyclePassYear);
            $this->db->where('bicyclePass.payStatus', false);
        }

        /** ...省略 */
        $this->db->where('students.classId', $classId);

        return $this->db->get()->resultArray();
    }
}
StudentModel->studentList() 是一個正在腐敗的程式碼，因為它的 策略 與 機制 被寫在一起了。這種安排程式的方式往往會在遇到新需求時，就替函式新增幾個參數或 if 來完成新需求的功能。雖然這個案例看起來很小又不複雜，但是，如果開發人員不懂得將策略與機制隔離，不用一下子專案中就會充滿又臭又長的大函式！而且這些大函式常常又是 策略 與 機制 完全攪在一起，開發人員根本難以辨認函式最原始的邏輯是什麼！

隔離策略與機制，防止程式碼腐敗

在我維護的專案中，有一個核心功能為「簽核公文」。使用者需要有一個「簽核歷史紀錄」的畫面來追蹤公文狀態：
顯示簽核紀錄功能
「簽核歷史紀錄」功能的資料是經由 Workflow 類別的 process() 函式撈取的：
class Workflow
{
    /** @var array 所有簽核 */
    protected $process = array();
    /** @var Workflow_repository 資料庫操作層 */
    private $repo;

    /**
     * 取得 所有簽核資料
     *
     * @return array
     */
    public function process()
    {
        return $this->repo->get_process($this->workflow_id)
    }
    // ... 省略
但是目前 Workflow->process() 只有撈取「簽核資料」是不夠的，因為客戶要求「簽核歷史紀錄」畫面需要更多的資訊：
  1. 隱藏匿名簽核成員的名稱
  2. 異常的流程須標記成紅色
  3. 顯示異常流程的原因
到目前為止可以看到，「簽核歷史紀錄」是屬於與 UI 相關的新需求。在 Clean Architecture 架構的同心圓中，UI 被分類在外圈，也就是 機制。Workflow 類別則是系統的核心功能，故屬於同心圓的內圈，也就是 策略。
如果開發人員直接擴充 Workflow->process() 的程式碼來完成「簽核歷史紀錄」的功能，等同於“把機制的程式碼寫進策略中”，不但使程式碼變得不易維護，還讓系統中其他調用 Workflow->process() 的功能都被迫執行「簽核歷史紀錄」的程式碼！
因此應該遵循 Clean Architecture 的「隔離策略與機制」原則，我們必須隔離 Workflow->process() 與「簽核歷史紀錄」的程式碼。做法很簡單，只需要讓 Workflow 引入一個抽象介面，讓外部可以注入 機制 的程式碼，就是做到隔離 機制 和 策略：
/**
 * Interface Decorator
 *
 * 用於擴充領域模型撈取資料邏輯 for UI 介面
 */
interface Decorator {
    /**
     * 擴充領域模型的資料
     *
     * 先利用領域模型取得資料，
     * 再取得 UI 層的所需資料
     *
     * @param $domain_object
     * @return mixed
     */
    public function decorator($domain_object);
}

class Workflow
{
    /** @var Decorator[] 資料裝飾器 */
    private $decorators = [];
    /** @var array 所有簽核 */
    protected $process = array();
    /** @var Workflow_repository 資料庫操作層 */
    private $repo;

    /**
     * 引入資料裝飾器，讓資料可以隨著需求擴充
     *
     * @param Decorator $decorator 資料裝飾器
     */
    public function add_decorator(Decorator $decorator)
    {
        $this->decorators[] = $decorator;
    }

    /**
     * 取得 簽核流程
     *
     * @return array
     */
    public function process()
    {
        $this->process = $this->repo->get_process($this->workflow_id);

        // 如果有配置裝飾器，則執行裝飾器擴充資料邏輯
        foreach ($this->decorators as $decorator) {
            $this->process = $decorator->decorator($this->process);
        }

        return $this->process;
    }
上面這段範例程式碼，已經完全將策略和機制隔離了：
  1. 新增了一個用來擴充資料的抽象介面 Decorator
  2. 在 Workflow 新增一個公開的 add_decorator() 函式，提供外部將實作 Decorator 抽象介面的實體物件注入 Workflow。
  3. 調整 Workflow->process() 函式，調用被注入的 Decorator 實體物件來擴充資料。
這一個步驟的核心觀念是 策略必須開放擴充點，讓機制從外部擴充策略的邏輯，只有這麼做才能讓策略應對千變萬化的需求。
開放擴充點後，只需要依照「簽核歷史紀錄」的需求，並新增 實作 Decorator 的類別 來擴充 Workflow 的邏輯就好了：
由 Controller 注入 UI 所需的機制，擴充策略的邏輯
從上圖可以發現，Workflow 只能透過抽象介面來使用 機制，換句話說 Workflow 根本不知道 Hide_anonymous_user_name.php 和 Mark_error_process.php 的存在！這正是「相依性規則」所謂的“內圈不能知道外圈的存在”。抽象介面就像一道邊界，隔離了策略與機制。而邊界的兩邊將以不同的速率和原因被改變。

一直都是開放封閉原則

策略與機制只能透過抽象介面存取彼此
較有經驗的開發人員應該會發現這不正是 開放封閉原則 嗎？沒錯，Uncle bob 在書中也說了：
事實上，軟體開發技術的歷史就是「如何方便地建立 Plugin 來奠定可擴展和可維護的系統架構」的故事 -《Clean Architecture》
《Clean Architecture》一書揭露了軟體開發從設計物件到組織架構，其實都是應用「隔離策略與機制」的思維來控制軟體複雜度，至於如何做到隔w離策略和機制則是按照不同的情境有不同的作法。
　　

工作實踐經驗

替專案導入 Commit Message 規範

打開新公司的程式碼，發現這裡的開發人員沒有統一撰寫 Git Commit Message 的格式，這對一個長期維護的系統來說並不是一件好事！打開 Git History 幾乎找不出程式碼異動的意圖與原因，往往只有原作者知道自己的程式碼在做什麼…。
為了解決這個問題，我向開發團隊提議可以導入 Commit Message 規範，規範的詳細內容已經被記錄在「Git Commit Message 這樣寫會更好，替專案引入規範與範例 」 文章中。

實際案例

1. 同仁導入規範前的 Commit Message：
2. 導入規範後，開始會紀錄異動原因與內容：
雖然過了好幾個月才讓大部分的開發人員確實按規範撰寫 Commit Message，但是開發團隊中已經養成一個優良的文化！當良好 Commit Message 持續被 Commit 進程式庫，新進人員也會乖乖遵循前人的格式撰寫 Commit Message。
　　

替專案導入單元測試

時間拉回到剛搬到高雄的 2018 末。當時我才剛學會重構和單元測試。面試時，公司的技術顧問說公司想要導入單元測試和重構，希望我一定要進公司幫忙。我也答應了！真的很感謝有這個機會可以實踐導入重構與單元測試（讓我成長很多）。
這間公司的專案使用 CodeIgniter 3 框架（後面簡稱 CI3)，CI3 本身並不是倡導物件導向開發風格的框架，專案的程式碼自然也是偏向義大利麵風格。加上專案是維護多年的大系統，在這樣的環境下導入單元測試變得很困難！
雖然說導入單元測試很困難，但說真的，除非專案使用物件導向風格開發以及有持續重構的習慣，不然不可能輕易導入單元測試吧！而且從身邊碼農朋友的經驗看來，幾乎 100% 的專案沒辦法輕易導入單元測試。所以我把這次的困難當作挑戰，練習如何讓單元測試在一個 Legacy Application 落地。

建立測試框架

由於 CI3 架構內建的單元測試功能很少，所以我選用整合了 PHPUnit 的 ci-phpunit-test 來當作專案的測試框架。建立測試框架其實是導入單元測試最快最簡單的步驟，因為其他開發人員並不懂單元測試的相關知識，所以一定要盡可能地簡化撰寫單元測試的複雜度，才能讓單元測試“較有機會”導入開發團隊…

隔離測試環境對 DB 的副作用

為了避免測試環境的行為污染 DB 的資料，因此要隔離單元測試與 DB。當時第一個想法是：”在測試環境下一律使用 SQLite”，因為 SQLite 可開啟 In Memory 模式，在記憶體中操作資料庫。當程式關閉後，記憶體內的 SQLite 資料庫也會清空，相當適合測試環境使用（無副作用）。
做法很簡單，只要把 MySQL 的備份檔案轉成 SQLite，再到 CI3 的設定檔案中將測試環境的 DB 驅動器改成 SQLite 就可以了…。
但是實際運作起來，總有一些功能會發生錯誤。原本以為是 MySQL 的資料在轉換成 SQLite 的過程中有失真。經過百般測試後發現，原來是專案很多功能是用手寫的字串來組織 SQL 指令，而不是透過 CI3 的 QueryBuilder 來建立 SQL 指令。手寫的 MySQL 指令讓測試環境中的 SQLite 驅動器編譯失敗。我也因此學到一個教訓：
專案應該盡可能用 QueryBuilder 或 ORM 等資料庫操作層來編寫 SQL，否則專案要切換資料庫種類的時候，會有很高的機率遇到編譯失敗的窘境。
若您的專案也經常使用手寫字串組織 SQL 指令，請不要花時間研究如何使用 SQLite 當作測試環境的資料庫了！

利用 DB 交易機制避免副作用

SQLite In Memory 的方式失敗了，只好找用第二方案：資料庫交易處理機制（Transaction），在測試案例中加入交易機制，測試一結束就執行滾回（Rollback）。為了引入交易機制，建立一個客製化的類別，並繼承 TestCase 類別來銜接 CI3 內建的 DB 交易邏輯，如此一來測試環境的行為就不會對資料庫造成影響了：
    /**
     * 功能三：將目前帳號加入至設備可切換帳號
     * 1. 將帳號加至 DB 中，where token = Cookie.token
     */
    public function test_add_switchable_account()
    {
        $this->trans_begin();

        // @given admin 帳號
        $this->init_switcher(self::COOKIE_STATE);
        $account = 'admin';

        // @when 將 admin 帳號加入至設備可切換帳號
        $this->switcher->add_switchable_account($account);

        // @then 帳號 admin 已存至設備可切換帳號 DB 中
        $switchable_account = $this->get_switchable_account_from_db($this->state->token);
        $this->assertEquals(json_encode([$account]), $switchable_account['switchable_account']);

        $this->trans_rollback();
    }
當然，這個方案不夠好，要是資料庫裡面沒有我需要的測試資料呢？更何況單元測試本來就不應該依賴外部環境（如資料庫）不是嗎？因此後來我嘗試了好幾種建立測試資料的方案，例如 Seeds 或 Faker 等等…。但是公司專案的資料其實非常難建立，若為了測試環境而花費大把時間維護 Seeds 或 Faker 似乎也不是一個好辦法。最後終於在《Specification By Example》這本書找到最佳解決方案！

拷貝「具有象徵性的真實資料」當作測試資料

《Specification By Example》中提及，若專案的較難建立就可以拷貝「具有象徵性的真實資料」，並且把被拷貝的資料存放在某個檔案中，進行測試的時候再將這些檔案轉譯成測試資料。這個方法讓我不再煩惱如何建立測試資料，現在只需要透過 PHP 的 var_export() 或 json_encode() 就可以將需要多道程序才能建立的資料拷貝起來，然後將拷貝的資料放在專門提供單元測試資料的類別(Test Data Provider)，供測試案例使用：
/**
 * feat: 表單填寫頁面，選擇題允許輸入文字時，必填時也要檢查輸入文字 input
 */
public function test_check_form_with_options_that_text_writable()
{
    $this->describe('必填「多選題」允許輸入文字，沒有填寫 **所有已挑選選項** 的文字時，不可通過必填檢查', function () {
        // @given 必填「多選題」允許輸入文字
        // @given 尚未填寫所有已挑選的選項之文字方塊
        list($question_block, $input, $ai_id, $role_id) = $this->data_provider->form_with_checkbox_that_text_writable_and_not_filled_all_text();

        // @when 進行表單必填檢查
        $required_notice = $this->answer_checker->check_form($ai_id, $question_block, $input, $role_id);

        // @then 不過表單必填檢查
        $this->assertEquals(1, count($required_notice));
    });
    $this->describe('必填「多選題」允許輸入文字，有填寫 **所有已挑選選項** 的文字時，可通過必填檢查', function () {
        // @given 必填「多選題」允許輸入文字
        // @given 有填寫所有已挑選的選項之文字方塊
        list($question_block, $input, $ai_id, $role_id) = $this->data_provider->form_with_checkbox_that_text_writable_and_filled_all_text();

        // @when 進行表單必填檢查
        $required_notice = $this->answer_checker->check_form($ai_id, $question_block, $input, $role_id);

        // @then 通過表單必填檢查
        $this->assertEquals(0, count($required_notice));
    });
}

替 Bug 撰寫測試案例

值得一提的是，拷貝資料的做法除了提供 TDD 或 BDD 測試資料以外，也可以應用在 Debug。每當遇到 Bug 時，就可以把具有「Bug 特徵的輸入值」Copy 起來，並且為這個測試資料建立一個 Bug fix 測試案例。
接著我們要修正程式碼讓 Bug fix 的測試案例通過。當測試案例通過的時候，表示我們把 Bug 修正了。之後遇到新的問題的時候，不但要通過新的 Bug fix 測試案例，也需要通過所有「舊的 Bug fix 測試案例」，才能確保新的 Bug fix 不會破壞原本正常運作的邏輯！
　　

提出系統重構流程

“導入系統重構”是技術顧問在面試中拜託我要幫忙的事項。
由於公司早期的開發人員沒有重構的習慣，所以平常有非常大量的技術債可以讓我進行重構，小至意義不明的變數名稱，大至超多層巢狀 if、foreach，有時候看到巨獸等級的義大利麵還會被嚇到心頭揪一下呢！
雖然平常我都會隨手進行重構一下 issue 會觸及的程式碼，但是一個團隊中只有一個人進行重構，對多年累積下來的 技術債 來說是不痛不癢的。所以我開始在公司內部的 Wiki 分享重構的知識；觀察專案中的核心功能有哪些；制定重構的 SOP 流程。最後將這些資訊整理一份簡易的簡報，用來跟經理和技術顧問討論要怎麼讓重構落地：

簡報大綱

指出系統現有的問題：
  1. 專案使用的 MVC 框架在面對數量龐大的模組和多變的需求下，容易變得耦合與臃腫。
  2. 專案中充滿著重複的程式碼邏輯，開發人員難以學習系統。
提出的解決方案：
  1. 導入領域模型層，讓程式碼抽象化，降低開發人員學習系統的難度，以及更容易應變變化。
  2. 導入 Wiki 文件系統，讓開發人員共同維護文件。
也提供實際操作範例：
  1. 如何撰寫整合測試案例，供重構時回歸測試用。
  2. 如何利用重構建立領域模型。
  3. 如何撰寫領域模型的單元測試。
這份簡報的原意只是想用來討論 SOP，不過技術顧問看完後就開始調動人員準備執行了！

持續重構，利用設計模式”擁抱變化“

基本型別偏執(Primitive Obsession)

手頭上的專案每次遇到要匯出 Excel 的需求都會很頭痛，因為必須透過大量且複雜的 Array 來建立匯出資料。這是 Primitive Obsession（基本型別偏執）的壞味道，大量使用基本型別（如 Array）來組織一個有意義的結構。但是大量的基本型別閱讀起來跟大泥團沒什麼兩樣，因此做了 Replace Array with Object 重構：
引入物件，簡化建立 Excel 資料複雜度
這次重構簡直是一勞永逸，之後遇到匯出 Excel 都是小菜一碟！其他開發人員也用得開心^^。

Flyweight 享元模式

在 Excel 解決了 基本型別偏執 臭味道後，又引入了新的問題：記憶體耗盡（memory exhausted）。為什麼會發生記憶體耗盡呢？因為對 Excel 物件來說，一欄一列都需要產生一個 Row 或 Cell 物件來乘載資料。一旦要匯出資料量很大，就有可能發生記憶體耗盡的問題：
建立太多 Row 與 Cell 物件造成記憶體耗盡
為了避免記憶體耗盡的問題，導入了享元模式。享元模式的核心思想其實就是建立快取(Cache)。所有要匯出的資料只需通過快取的 Row 或 Cell 物件來渲染資料即可，不必再為每個 Row 與 Cell 建立獨立的物件。
class Excel
{
    /**
     * Excel Row 物件
     *
     * 使用享元模式，避免 new 太多列物件
     *
     * @var Row $row
     */
    private $row;

    /**
     * 新增一列
     *
     * @param Cell|string|array $cells 欄位內容（可複數）
     * @param array $styles
     */
    public function addRow(array $cells, $styles = array())
    {
        $this->flyweightRow();

        $this->row->clearCells();

        foreach ($cells as $cell) {
            $this->row->addCell($cell, $styles);
        }

        $this->stack($this->row);
        return $this;
    }

    /**
     * 建立享元 Row 物件
     *
     * @return Row;
     */
    private function flyweightRow(): void
    {
        if (!$this->row) {
            $this->row = new Row();
        }
    }
加入快取機制後，即使要建立一個上萬筆資料的 Excel 活頁，也只需要一個 Row 與 Cell 物件就好了！
引入享元模式後，建立一個 Excel 活頁只需要一個 Row 與 Cell 物件即可。
（雖然後來發現其實是迴圈邏輯寫錯才造成記憶體耗盡，但享元模式仍被保留下來了。）

State 狀態模式

使用者希望系統提供「切換帳號功能」，讓使用者不必登出重打帳號密碼即可切換同一設備上曾經登入過的帳號，。
原先的設計是建立一個 Switcher 類別，讓每個設備產生獨立的 Token 並儲存在 Cookie 裡面，系統再由 Cookie 的 Token 撈取設備曾經登入過哪些帳號。
但是過沒多久，另一個客戶希望可以藉由 user_id 從舊系統的人事資料庫撈取多個可切換的帳號，但這個切換帳號的需求較適合用 Session 來實現。
為了讓系統可以同時使用 Cookie 與 Session 來切換帳號，我在 Switcher 類別中引入 Switchable_state 介面，並把原本 Cookie 的邏輯全部搬移至新類別 Cookie_storage：
重構 Switcher 類別，引入 Switchable_state 介面以便操作多種資料來源的需求。
現在 Switcher 是透過 Switchable_state 介面來存取資料來源，因此我只需新增一個實作 Switchable_state 介面的類別來實現 Session 版本的切換帳號功能，即可無縫接軌地讓系統多出 Session 切換帳號功能。
系統可以同時保有 Cookie 與 Session 版本的切換帳號功能

Pipeline 流水線模式

系統有個每日信件功能，該功能會在每日凌晨啟動排程寄送當日的系統信件給使用者。
最初的需求為：
1. 寄送每日系統通知
沒多久後，每日信件又有新的需求，要寄送新的信件種類：
1. 寄送每日「系統通知」
2. 寄送每日「站內訊息」
沒意外！每日信件馬上又出現第三個需求：
1. 寄送每日「系統通知」
2. 寄送每日「站內訊息」
3. 寄送「明日上課資訊」給教師
每日信件功能原本的設計是，將所有建立信件內容的邏輯寫在同一個 Controller 上。但是隨著需求不斷增加，Controller 變得又龐大又複雜。
考量到將來可能會需要寄送多種資訊給使用者，故重構程式結構，讓未來擴充每日信件功能比較方便：
  1. 引入 Pipeline，把取得各種系統資訊的邏輯注入進 Pipeline。
  2. 透過 Pipeline 取得每日通知信件內容，並建立信件 HTML。
  3. 把建立「系統通知」信件邏輯搬移至 System_notify_handler.php
  4. 把建立「站內訊息」信件邏輯搬移至 Message_handler.php
  5. 把建立「開課資訊」信件邏輯搬移至 Course_start_handler.php
重構後的結構
每日信件功能只需透過新增 Pipeline 的任務，即可新增信件種類
　　

導入 Event Sourcing 概念紀錄系統日誌

其他經驗

高雄科技大學講授 PHP 程式設計課程

技術顧問對 1 月份提出的 系統重構流程 相當有興趣，故將重構計畫整合至校外課堂中，帶領一批學生一起參與重構計畫，希望透過讓學生閱讀企業級的程式碼，栽培學生寫出「成熟」的程式。在這個計畫中，公司由經理和我每個禮拜中抽出兩天的時間到高雄科技大學替學生上課，上課的主題是網站系統開發，包含：
  • Gitlab 基本操作
    • Commit
    • Commit Message 規範
    • Push
    • Pull
    • Merge Request 概念與用意
  • HTML5
  • CSS
  • JavaScript
  • PHP
  • CodeIgniter 3
  • 如何閱讀程式碼
另外也可以看當時設計給學生的 訓練菜單，我認為這份也很適合給較沒開發經驗的新進人員當做教材學習。

翻轉教室

每週兩天的上課時間，對網站開發沒概念的學生來說實在是太少了，因此必須設計一套適合的課程來解決時間太少的問題。最後遵循一套名為「翻轉教室」的教學方式，設計出讓學生在非上課時間也能夠自主學習的課程。
安排目標與練習，讓學生主動找時間學習
翻轉教育的課程必須事先幫學生定製一系列的主題與範圍（詳情可見：訓練菜單)，再給予每個主題的學習資源，讓學生以概括的方式快速了解主題。最後每個主搭配一些題目或情境，讓學生以解決問題導向的方式進行學習。另外，為了因應學生素質不一致的問題，教學資源和題目包含淺至深的議題，讓進度較快的學生不必等其他同學的進度，就能持續往下練習。
開始上課前幾週，只需要幫學生起個頭，簡介一下主題的內容與主題之間的關聯，並且指派每週作業。下課後學生就會自行找出實踐作業的相關知識，從中學習知識並且得到解決問題的成就感。
當學生熟悉翻轉教室的形式後，每次到學校上課都是與學生探討在作業中遇到常見錯誤、困難，並且提出良好的解決方案或學習方向。

Gitlab 當作回饋機制

翻轉教室主要是讓學生透過自主學習的方式進行學習，因此必須有個回饋機制讓學生知道自己學得正不正確。原本翻轉教室是利用每次上課時間，讓學生分享作業；以及講師帶領學生探討寫作業過程中遇到的問題來當作回饋。
我和經理選擇導入更適合開發人員的 Gitlab 來實踐回饋機制：
  • 利用 Milestone 要求學生將作業繳交至 Gitlab。
  • issue 功能則像 StackOverflow，讓學生可以公開討論自己的問題，個性羞怯的學生也能在 Gitlab 與講師或同學進行交流。
  • Merge Request 機制用來審視學生的作業，將學生做得不好的地方與建議即時回饋給學生。

利用 Merge Request 導入良好的開發觀念

Merge Request 讓我變成學生的個人教練，學生上傳程式碼後會立刻得到錯誤報告與改善建議。發現常見問題時，也可以 tag 所有學生一起討論並學習解決方案。
我和經理在 Merge Request 階段進行嚴謹的 Code Review，審查內容包含:
  • Commit Message 規範
  • Coding Style
  • 重構
  • Clean Code 觀念 …等
只要不合格就退回並給予改善建議，詳細內容可以看 PHP 作業常見問題與建議。前幾個作業中，學生都被多次退回才通過 Code Review。
對學生進行 Code Review 並給予建議
不到一個月，學生的程式碼變得相當成熟，不再有意義不明的變數名稱，也不會寫出巢狀 if，並且有能力釐清程式碼的職責。甚至能力較好的學生還會回頭重構前幾次的作業呢！
Code Review 除了訓練學生效果很好以外，我認為一個 IT 公司也應該好好利用 Code Review 持續培養開發人員良好的開發習慣與思維！
​

留言

張貼留言

這個網誌中的熱門文章

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
閱讀完整內容

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） 上述流程如下圖： ​
閱讀完整內容

PHP OO 物件導向基礎教學

PHP OO 基礎教學 此篇教學只是物件導向的基礎與實作，內容只包含類別與物件的操作，讓不熟悉類別的人可以初識物件導向的好處，並且了解物件與類別的特性與關係。 更多物件導向的理論的學習內容會整理到 PHP OO 的進階教學: 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則，Why SOLID? PHP OO 物件導向原則:單一職責原則SRP PHP OO 物件導向原則:開放封閉原則OCP PHP OO 物件導向原則:里氏替換原則LSP PHP OO 物件導向原則:介面隔離原則ISP PHP OO 物件導向原則:依賴反轉原則DIP 進階觀念：再談物件導向設計原則: 單一職責原則，定義、解析與實踐 認識物件導向 Object Oriented： 物件導向是一種寫程式的方式，它傾向讓開發者把類似或有關聯的工作或屬性，組織到類別(classes)裡面。這可以讓程式保持遵守  不重複原則** “don’t repeat yourself” (DRY) **，且更容易維護。 “Object-oriented programming is a style of coding that allows developers to group similar tasks into classes.” 不重複的程式(DRY)是物件導向最主要的優點之一，物件導向嚇跑了很多的開發者，因為它帶引入了一些新的語法，並且一看就知道比直譯程式(procedural)還複雜。但是，其實仔細了解一下，OO 實際上是一種非常直觀且是簡化程式最好的方法。 一、認識物件與類別 Understanding Objects and Classes 在開始更深入了解 OOP 之前，一定要先了解  物件(object) 與 類別(class)  的差異。本章節會介紹 類別(class) 的構造，還有其功能與用途。 類別(class)，可以比喻為一間房子的藍圖，類別只是清楚得定義房子的結構與形狀。 物件(object)，可以比喻為一棟真的房子， 物件是類別的實例化 。 資料(data)就像是鋼筋、電線、混泥土等蓋房子的材料。如果沒有按照 藍圖 (類別 class)  來組裝，這些
閱讀完整內容