在 Laravel 專案中整合 Vue CLI

自從 Vue CLI 3 發佈以來,如何將它整合在 Laravel 裡是不少開發者的疑問;因此 Vue 的老爸尤雨溪便針對這個問題寫了一個教學範例 ,本文即是參考該範例所寫,不過有根據 Laravel 的新特性做一些調整。

閱讀全文

我如何從需求出發到完成一個專案

身為一個 Web 開發者,有時候我還是會問自己:「如果今天讓你一個人從頭開發出一個網站,你要怎麼開始呢?」這倒不是說我不知道怎麼做,而是要讓我自己徹底地去理解需求所面對的問題,然後明白自己可以用什麼工具去解決它。

剛好前陣子遇到一個公司內部的需求,讓我有機會重新省視一下自己目前的技能是否足以完成這個需求。

閱讀全文

Laravel 執行測試時出現 Function name must be a string

在 Laravel 撰寫單元測試有用到 @dataProvider ,執行測試時卻出現 Function name must be a string 的錯誤。

這是因為所有的 Data Provider 會比 setUp 更早被執行,所以不能在 Data Provider 裡用任何在 setUp 後才會有的東西,例如 $this->app 或 helper function ,因為這時候它們還沒有被初始化或被 autoload 載入。

閱讀全文

身為前端工程師,對你來說,你認為最重要的是什麼?

好友 Kuro 公開問了這個問題,嘗試挑戰一下。不過主要也只是整理了一下我從身邊的前端同事及社群朋友們上看到的一些特質,畢竟比起我來,他們在前端領域打滾得更久。當然這些特質應該是適用大部份工程師 (不論哪一端) ,但我還是認為前端工程師平時要更著重這些特質。

註:其他領域或許也有「前端」這個術語,但一般人認知的「前端」是泛指「 Web 前端」。

這些特質包含:

  • 厚實的基礎能力
  • 擅長找出問題點
  • 擁有靈活的思維
  • 時常保持好奇心

閱讀全文

我的 2018 年

又過了一年了, 2018 年只在這個部落格零零落落地加了幾篇文章,感覺自己似乎沒什麼長進。最近寫作的機會大多是在專案的文件上,對於技術知識的研究與自己內心的探討變得越來越少,所以應該是來寫篇心得感想的時候了。

老實說原本打算寫篇年底回顧,不過整理了一下手邊的隨手筆記和平常記在 Facebook 上的資訊後,發現想講的東西太多了,就隨性想到什麼寫什麼吧。

閱讀全文

在 Laravel 中使用 Behat 來加強測試的可讀性 - 進階篇

上一篇文章中,我介紹了如何把 Behat 整合到 Laravel 裡;不過後來我發現在專案規格越來越複雜時,把所有 step definitions 都寫在 FeatureContext 類別中變得非常不易閱讀。另一個問題就是我不想要用 putenv 函式來定義環境變數,而是希望能有 Behat-Laravel-Extension 把環境變數放在 .env.behat 裡的用法。

閱讀全文

在 Laravel 中使用 Behat 來加強測試的可讀性 - 基礎篇

Laravel 的測試框架是基於 PHPUnit 上所建立出來的,而在 Laravel 5.5 之後,測試框架的功能也大幅地加強了。只不過在越來越複雜的專案規格下,我個人覺得 PHPUnit 在情境案例的描述能力上還是不太夠,最好可以用人們看得懂的語言;而目前能夠用自然語言來描述規格情境的,當然就是 CucumberGherkin 語法了。

閱讀全文

理解 composer.json 的 replace

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

例如你正在開發一個專案 (也就是在 composer.json 中的 typeproject ) ,它相依 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 的幾個階段

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

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

閱讀全文

面對 Legacy Code ,該重構還是重寫?

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

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

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

閱讀全文