通常你在 composer.json 裡很少會用到 replace 這個 schema 屬性 ，不過在以下情境它就很有用了。

例如你正在開發一個專案 (也就是在 composer.json 中的 type 為 project ) ，它相依 original/library 這個套件以及 other/package 這個套件。很巧的是， other/package 這個套件也相依了 original/library 這個套件。

假設現在你覺得 orginal/library 這個可能已經太老舊，但維護者又不想讓你更動它，所以你決定把它 fork 出來改成一個相容但是功能更強大的 better/library ，並且把它標上新版號釋出。

現在回到你的專案，將原來的 original/library 改成 better/library ，並希望一切正常；只是 other/package 還相依在 original/library ，使得它跟你的 better/library 有衝突。那麼該怎麼讓 other/package 也改用 better/library 呢？我們可不打算再 fork 一份 other/package ！

這時候就是 replace 出場的時機了。

看完前一篇的介紹，我想你應該已經想好面對 legacy code 時，應該要重構還是重寫了。如果你打算對正在線上的程式碼進行重構，那就像在幫飛行中的飛機換引擎一樣；如果是重寫，那就是造一架新飛機讓它升空，然後在空中把舊飛機裡的乘客接過來一樣。

那麼要怎麼在空中幫飛機換引擎或接送乘客呢？應該有些具體的方案吧？其實有幾件事是兩個方法都必須先做的，以下就整理了幾個重構或重寫前重要的步驟。

在程式已經上線很久很久的情況下，公司也找了不少人來維護這些程式碼；而因為開發者來來去去，加上每個人對程式開發的觀念不同，他們也許都有過這樣的感受：

• 因為缺少規格文件，這團程式碼到底有哪些是該拔還是不該拔，很抖；算了，放著不管吧。
• 因為迫於時間壓力，被只求解決眼前問題所帶來的不穩定性困擾著；算了，有 bug 再修。
• 因為沒有寫過測試，修正程式時常常擔心改東壞西的不安全感；算了，有人叫再說。
• 因為團隊已有慣例，想要動手調整架構，卻怕同事不支持；算了，給下個人弄吧。
• 因為依賴語言特性，有些好的作法引入之後反而造成問題；算了，反正會動就好。

結果專案中的技術債越欠越多，而這些程式碼也變成了所謂的 legacy code 。

很多人在寫測試時，常會陷入該去測試結果還是測試細節的困擾裡。雖然我的測試寫得不算太多，但我還是提供一些看法與實務上的經驗供大家參考。

前兩天 Laravel 老爸 Taylor 分享了他對幾個知名的 framework 所做的程式碼品質分析，引起了社群很大的討論。

這是在網路上流傳很久的 Spotify 公司工程文化的介紹，雖然是兩年前的影片，但看完後覺得跟我們公司有很多相似的地方，而且也有值得學習的部份。因此特別把其重點整理並紀錄下來，以供往後組織參考與討論。

Part 1

資深工程師的潛標準如果是有沒有雞雞跟表定從業年資，不是好好檢視過往提出的軟體設計建議、code review 內容，甚至是 coding performance 跟工作倫理表現的話，那無法服人應該不令人意外吧。

— Ravi Wu (@ravilwwu) 2016年12月21日

看到這篇推，心中還滿有感觸的。本來就不是資歷混夠久、程式寫得好就能算得上資深工程師；資深工程師該怎麼定義其實很難拿個準，我的主管也曾問過我這個問題，我一時之間也很難完整回答。不過在面試時常常看到很多面試者都是應徵資深工程師，但實際問他們一些問題之後，卻發現他們卻缺乏了一些東西。

所以藉這個機會，我想從幾個面向來聊聊我心目中的工程師應該具備哪些特質與能力，而這些特質與能力，我都是從身邊厲害的同事們與社群的朋友們身上觀察到的，他們都是我所敬重的資深工程師 (當然職稱不一定是) ；同時我也會提供一些過去遇到的反指標，避免大家誤會資深工程師是否都是這樣的人。

不知道你有沒有在開發 PHP 程式的過程中，測試過需要使用 anonymous function 或 closure 的函式或類別方法？我在開發自己的函式庫時，就遇到了需要測試 closure 是否被正確調用的問題。

在解決幾個問題後，我發現其實做法並不難，所以接下來我就來介紹幾個測試 closure 的方式。

如果你面對的是以前舊有的 PHP 程式，是時候負起一些責任了。

我知道它改起來很痛苦，一堆不良的 PHP 程式習慣都阻礙你的修正；使得每次調整功能時，到底改得對不對，得要等到上線才知道。想要重寫一個新版本，但太多的實作細節你不清楚；也沒有最新的規格文件，讓你無法為新版本做出功能無誤的保證。

現在你唯一擁有的，就是已經在線上運作的程式邏輯；雖然它可能還有 bug ，但至少大多數的功能是通過使用者驗證的。那麼先為它買個保險吧！確保之後的修改不會影響到其他功能的正常運作；而最直接的方式，就是把目前程式邏輯所呈現的結果或是使用者的操作，寫成自動化 Web 測試。

建立 Web 測試的方法有很多，這裡我將介紹我在實務上使用 PHPUnit 加上 Mink 搭配 PhantomJS 的方法。

來上 TDD 課的學員問到一個 Laravel 程式碼重構的問題，這裡簡單地做分享。未來如果有好的實戰範例，這系列就會延續下去。