WadeHuang的學習迷航記

在 Mac 上切換 PHP 版本 如果你是使用 Liip PHP 替你的 Mac 安裝 PHP 的話，那麼恭喜你，切換 PHP 版本會變得非常簡單。 安裝任何 Liip PHP 之前，做好備份！ 雖然切換版本很簡單，但也有應注意事項！！！ 安裝 Liip PHP 後，會覆蓋原本在 /ect/apache2 目錄底下的設定檔案 ，所以在安裝任何 Liip PHP 之前， 記得先做好備份 ，以便將設定復原。 更好的做法是，把自己客製化的設定，額外拉出一個設定檔案。等安裝完成後再 Include 即可。 一但做好備份後，就可以開始進行安裝囉！ 如何切換 PHP 版本 當您同時安裝多個版本的 Liip PHP 時，可以在 /usr/local 目錄下看見所有版本的 PHP : 根據 Liip PHP 的設定，不論您安裝任何版本， Liip PHP 一律會從 /usr/local/php5 這個路徑執行 PHP 。 然而 /usr/local/php5 只是一個捷徑，並且指向這個目錄下其中一個版本的 PHP： 由此可知，如果 想要切換 PHP 版本，只需要替換 php5 這個捷徑即可 。 切換捷徑即可替換 PHP 版本 cd /usr/local rm php5 ln -s php5-7.3.0alpha3-20180705-141106 php5 快速切換 PHP 版本： 如果每次切換版本都要手動砍捷徑太麻煩了，也可以寫一個 Base Shell 指令稿來替你切換版本。 首先新增一個 switch_php.sh 檔案： #!/bin/bash # 使用方法: # ./switch_php.sh <version> # ./switch_php.sh php5 # ./switch_php.sh php7 # activate php56 if [ "$1" == "php5" ]; then sudo rm /usr/local/php5 sudo ln -s /usr/local/php5-5.6.14-20151002-085853 /usr/local/php5 echo "activated p

自動校正中文文案排版（For 檔案） 資料來源： WadeHuang1993/github 此工具針對「檔案」校正中文文案的排版，統一中文文案與排版格式皆參考 中文文案排版指北 。 此工具是基於 NauxLiu/auto-correct 做出來的「自動中文排版工具」。 此工具只在 Command-Line 模式中運行 安裝要求： PHP 5.6+ 安裝： 將 AutoCorrectChineseTypesetting Clone 下來即可。 使用說明： AutoCorrectChineseTypesetting 必須在 PHP-CLI 模式下進行： 將要進行排版的檔案放到 AutoCorrectChineseTypesetting 目錄下。 使用 PHP-CLI 執行 AutoCorrect.php 校正中文文案排版。 AutoCorrect.php 會自動將校正完成的檔案輸出至 Outputs 目錄內。 步驟： 在 Command-Line 模式中： cd path/to/AutoCorrectChineseTypesetting php AutoCorrect.php -i InputFile -o OutputFile 若 OutputFile 沒定義的話，預設輸出的檔案名稱會與輸入檔案名稱相同。 可用參數： -i 要做排版的檔案名稱。 -o 輸出的檔案名稱（可選）。 -a 新增校正辭彙庫（可選，可多次新增）。 -h 查看使用說明。 新增辭彙庫 -a 參數提供了新增辭彙庫的功能： 將您要新增的辭彙庫（xxx.php）放置於 dictionary 目錄下。 執行 AutoCorrect.php 並使用 -a 參數加載辭彙庫。 可多次使用 -a 參數，加載多個辭彙庫。 辭彙庫必須為 *.php 檔案，其內容為： <?php return [ # '校正前的字詞' => '校正後的字詞', /** * ...將您的新詞彙加入於此。 */ 'docker' => 'Docker' , '

用 KanbanFlow 做時間管理 不論上班或私事，我都喜歡使用 kanbanflow.com 這套工具來管理自己的時間與進度。 Kanbanflow 是一個專案管理工具，可以用來協同開發。使用 Kanbanflow 能快速列出清晰易的讀待辦事項（To-Do List），並將待辦事項分成 To-Do 、 Do Today 、 In Progress 、 Done 四種狀態。 你可以把工作與生活瑣事，全部整理成有「 明確行動 」的待辦清單，讓你能夠一眼清楚所有事務的內容與進度。 Tips：除了以上四種狀態以外，當然也可以自己新增/刪除新的 狀態。 待辦清單不能只是備忘錄，還要清楚列出「下一步行動」 明確化你的下一步行動 使用 KanbanFlow 的時候，強烈建議實施 微亮計畫 去管理自己的計劃，讓待辦清單督促自己做事，提升自己做事情的效率效率。 以下摘錄自 微亮計畫 ： 被事情淹沒的時候，先確保有達到基本款，在追求進階版。 基本款：達到基本要求所需要的時間 進階版：達到心滿意足的程度需要的時間 微亮計畫重點: 盡量一次只做一件事，最多三件事，否則會降低工作效率。 把一週內想做的事情全部寫上去。 標出 24 和 48 小時內真的要完成的事情。 預估個別需要的時間（分「基本款」、「進階版」兩種時間)。 兩天過後再循環一次 推薦閱讀： 經理人 - TO DO LIST 這樣用才對！ 微亮計畫 ​

3.1.2. 高階與低階（Hight-level and low-level） 高階與低階一詞在程式的世界中很常見，越高階的程式碼越抽象，越低階的程式碼越多實作。 第一次看到這句話的人可能已經開始神遊，不過現在讓哥帶你釐清如何辨別高階與低階。 註： 「高階」也常以 「Client」 一詞做取代 。 低階程式 首先來看低階程式碼，越低階的程式碼越接近底層。一般來說我們都懂， 越底層的程式碼越複雜 ，這是因為物件導向開發傾 封裝複雜的過程 ，以便重複利用。 這個概念其實在開發過程中也常碰到，以 jQuery 的 ajax （非同步連線）作舉例，你知道 jQuery 在封裝 ajax 之前有多複雜嗎？？ 在 ajax 沒有被封裝之前，程式碼長這樣 ： // If url is an object, simulate pre-1.5 signature if ( typeof url === "object" ) { options = url; url = undefined ; } // Force options to be an object options = options || {}; var // Create the final options object s = jQuery.ajaxSetup({}, options), // Callbacks context callbackContext = s.context || s, var // Create the final options object s = jQuery.ajaxSetup({}, options), // Callbacks context callbackContext = s.context || s, // Context for global events // It's the callbackContext if one was provided in the options // and if it's a DOM node or a jQuery collection globalEventContext = callbackContext

測試的術語 3.1.1 測試覆蓋率 Coverage 測試覆蓋率以百分比表示，用來測量有多少行程式碼已經被 測試程式 執行過。 如果你的程式碼有 4 行，但只有其中 3 行被測試程式執行過，那麼測試覆蓋率就會是 75%。剩下的 25% 可能是應該要廢棄的程式碼，或者是不屬於這個類別的工作責任，應該被移動至屬於他的地方。 以下列出多種測試覆蓋率的用途： 中文名稱 英文名稱 用途 函式覆蓋率 Function Coverage 確保每一個方法至少執行一次，且沒有發生錯誤。 行數覆蓋率 Line Coverage 確保程式每一行至少執行一次，且沒有發生錯誤。 決策覆蓋率 Decision Coverage 確保每個以真偽 (true/false) 控制程式走向的分支，至少被執行一次且沒有發生錯誤。 條件覆蓋率 Condition Coverage 確保每個分支是至少執行一次，並且沒有發生錯誤。 注意：為了滿足決策覆蓋率與條件覆蓋率有多個分支，必須針對每個分支的情境撰寫一個測試案例。 對測試覆蓋率的觀點： 覆蓋率數據只能代表你測試過哪些代碼，不能代表你是否測試好這些代碼。 不要過於相信覆蓋率數據。 測試人員不能盲目追求測試覆蓋率，而應該想辦法設計更多更好的案例，哪怕多設計出來的案例，對覆蓋率一點影響也沒有。 結論： 測試人員不應該為了滿足測試覆蓋率而撰寫測試案例，應該要以「使用情境」撰寫測試案例。 ​

什麼是重構？ 重構是一系列的等量變換 系統重構，就是在的 不改變軟體外部行為基礎上，改變軟體內部的結構 ，使其更易於閱讀、易於維護、易於擴充與易於變更。 持續不斷地對系統的內部品質進行改善與改進，就是重構的價值。 1.1 如何確保行為不被改變？ Ans: 單元測試、版本控制 單元測試 進行重構之前，務必先替程式碼撰寫單元測試。確保每個方法的「 輸出結果符合預期結果 」之後，才可進行重構。 接下來 每重構一小步，就立刻執行一次單元測試 ，確認被重構的方法「行為沒有因為重構而被改變」。 只有測試通過了，這次重構才算成功！ 版本控制 一般會採用 小步快跑 的方式進行重構，一次只重構一小部分，重構完馬上執行測試，測試通過後立刻上傳至 版本控制 （Git 或 SVN）。 這麼做的原因是，一但某個修改測試不通過，則還原回來。小步快跑可以讓重構的過程中，以最快速度發現修改的問題，將因重構錯誤帶來的損失減到最小！ 畢竟人不可能避免犯錯:-P 1.2 為什麼我們不在意實作細節？ Ans： 重構時只在乎受測程式的「輸出結果」與「預期結果」是否保持一致 。 因此，對一個物件進行測試時，只需要測試其公開方法（Public Methods），並不需要測試受保護方法（Protected Methods）與私有方法（Private Methods）。正確的設計下，測試完所有公開方法後，所有的受保護方法與私有方法都會被執行完畢。若出現沒有被執行的方法，表示該方法該被遺棄，或移動至屬於這個方法的類別。 1.3 為什麼不在意不明確且未測試的行為？ Ans： 還沒確定一段程式碼的行為是否符合預期之前，不可以對其進行重構！ 遇到一段行為不明確的程式碼，可以對其撰寫單元測試，利用輸入的資料與輸出結果，來理解這段程式碼的用意與行為。 當這段程式碼有單元測試保護的情況下，才可對其進行重構。 1.4 為什麼不關注效能？ Ans：一般來說， 不會在剛開始重構的階段就去在意效能，只在意程式碼是否有保持正確的輸出 。 但是如果一個實作在太慢，我們就有必要先修改實作了！ 如何對效能進行測試？透過 Benchmarking 套件，可以將執行函式的時間點當作「輸入」，並將運作完成的時間當作「輸出」。取時時間差回

單元測試法則 What should we test? Incoming & Outgoing Messages 上圖表示一個物件是如何被測試的。 測試物件的時候，你可以發現受測物件會 接收 與 發送 訊息： Incoming Messages 表示呼叫受測物件的訊息 Outgoing Messages  表示受測物件 傳遞 給其依賴物件的訊息 訊息可以被傳進物件，也會被物件傳遞出去（如上圖你可以看見有訊息進入物件，也有訊息從物件出去）。 進行測試時，你只能對物件傳遞訊息，沒有辦法看見物件的內部。這就是為什麼要 測試介面，不要測試實作。 （testing the interface, and NOT the implementation.） 測試介面讓我們可以隨意切換實作類別，並且不破壞測試程式。 Query & Command Messages 除了 Incoming & Outgoing Messages 以外，訊息還分為 Query 與 Command 兩種： Query Message： messages return data without changing anything. 只返回 Data，不做修改任何物件屬性的訊息 不會替應用程式帶來副作用。 Command Message： messages modify data without returning any data. 只修改物件屬性，但不返回任何 Data 訊息 一定會有副作用。 合併的 Command 與 Query 訊息： 這種訊息除了修改資料與回傳資料外，還可能有隱藏的副作用。 （如新增一筆 user 資料並返回新的 user ID，但是 DB 內的 ID 自動 +1） 在商業邏輯一定要使用合併訊息時，一定要確保這些訊息不能含有意料外的副作用。 Test Double 為什麼要 Test Double？ 1. 隔離依賴： 單元測試目的是要測試受測物件的行為是否符合預期，如果連受測物件的依賴物件也一起進行測試，那就叫做 整合測試 了。 因此單元測試需要隔離依賴。 2. 要求快速： 單元測試的時間應該