五倍券 Banner - 首頁 - desktop

五倍券 Banner - 首頁 - mobile

五倍的五倍券優惠活動

Blogs - Sidebar


## 所謂「半路出家」的工程師
也許以下的故事對你／妳而言似曾相識：
> 之前沒有程式或相關背景的你／妳，透過自學或參加線上／實體課程，找到了第一份工程師的工作。
> 
> 到了就職報到的第一天才發現，主管跟同事所說的話怎麼都聽不懂；好像當初所學的，其實對於工作情境而言根本就不夠用。過了幾天，把主管交代的任務完成、開始在專案發 PR 。這些 PR 中，有許多部分都被主管評為需要修改。更不幸的是，好像怎麼修改都無法達到標準。每次都得硬著頭皮、一條一條地向主管或同事請教。下班後足不出戶全心全力的付出，為的就是要把不會的東西趕快補齊，才有辦法給公司和自己一個交代。
> 
> ⋯⋯時間快轉到三個月半年後，這樣子的循環在現在雖已有好轉，但心中的挫敗感不減反增。對於工作，還是覺得自己似乎什麼都不懂；「當初公司一定是有誰搞錯了，才會錄取根本不適合這份工作的自己」，你／妳這樣想著。與一些許久不見的朋友碰面、提到了換了工作成為了工程師時，總是覺得有些心虛。「我，真的已經是工程師了嗎？」，你／妳，在心中反問著自己。

今天想要與各位分享的是在面對工作時，心中所產生的「我好像還不夠格」、「我不屬於這邊」、⋯⋯等想法，有時並非自己努力不夠，而是冒名頂替者症候群在作祟。

## 什麼是冒名頂替者症候群（ Imposter Syndrome ）
冒名頂替者症候群，以工作情境論，是指當面對所交辦的任務時，當事人所感到的焦慮感、自我懷疑以及擔心，造成了其對任務過度準備或故意拖延任務（或兩者皆具）。

當任務順利地完成，當事人也會將其成功歸因於自己有下了許多努力（透過對任務的過度準備）或單純地運氣好（因拖延任務、自覺自己沒有下功夫在做）；因完成任務而收到上司或同事的正面回饋，當事人也通常會將這些讚美給「打折扣」，覺得自己並沒有真的這麼好。⋯⋯久而久之，上述狀況演變成覺得自己只是個「還沒有被人發現的騙子」、自我懷疑、憂鬱和焦慮。簡言之，冒名頂替者症候群讓實際上已經成功的當事人，仍覺得自己似乎不應該是團體中的一份子、是位「冒名頂替上來的騙子」。

## 冒名頂替者症候群如何影響你我
![post-總覺得自己在工作上不夠稱職？論冒名頂替者症候群所帶來的影響](//images.ctfassets.net/8er52l3j5u76/3hDXQG7iVxufu6fEBrsQ2y/986d385ad5530496d022cd00b76da6dd/fig-imposter-cycle.jpg)
([Clance’s (1985) model of the Imposter Cycle, as depicted in Sakulku & Alexander (2011)](https://www.apa.org/science/about/psa/2018/09/imposter-syndrome))

可能受到冒名頂替者症候群影響的人有以下[特質](https://mari.umich.edu/news/impostor-syndrome)：

1. 自認不夠努力而總是過度工作
2. 為了避免失誤而拒絕接受工作上新的挑戰
3. 因害怕做出來的成品／成果不夠好而拖延交辦事項
4. 過度加班而疏於照顧自己，甚至犧牲了工作與生活之間的平衡
5. 在工作上遇到狀況時，為了不要讓他人發現其實自己（覺得自己）不夠格而刻意避免向他人請教或求助
6. 總是以犯過的錯，而非成就，來定位自己

若以在工作上表現良好而得到讚美及鼓勵舉例：

- 自覺是因為有準備

	能夠順利完成交辦事項，是自己花了大量時間與心力後的結果。下次要花的努力只能多不能少，才能夠維持著這樣子的表現而不會被識破。

- 自覺毫無準備

	覺得會有如此表現一切都是因為運氣好；自己多學會的技能剛好是工作所需要的、自己才派得上用場。仍然覺得自己德不配位，是個假冒的騙子。

## 在工作上可以如何克服、或至少與冒名頂替者症候群共存
- 用不同的角度看待事物

	工程師經常得面對未知的挑戰，而且結果有時候也往往不盡人意。如果對於要完成的任務感到焦慮，將其當作是個學習的機會；絕大多數情況下，它不會是造成你／妳職涯去留的轉淚點。

- 知道不是只有你會這樣想 

	如果感覺到自己對交辦事務感到手足無措、甚至是在逃避面對時，可以試著找也正經歷類似狀況的夥伴聊聊。當發現不是只有自己覺得事務困難時，可以幫助你對現在的處境做更正確的[歸因](https://en.wikipedia.org/wiki/Attribution_(psychology))。

	假使身邊真的沒有人可以討論，也可以試著讀讀[其他人的故事](https://medium.com/landingfestival/58-of-tech-employees-experience-imposter-syndrome-heres-how-to-overcome-it-78172d8a2258)。

- 允許自己邀功

	當完成了一件困難的任務時，允許自己將功勞歸在自己的身上。若不相信自己也有功勞，可以把為完成任務所做的努力，列成一張表來證明。對於收到他人的讚美不必推託、一句「謝謝」即可。別人不是為了讓你自我感覺良好而才給予讚美的；他們是真心這麼想的。

- 教學相長

	透過指導他人，除了能夠給予需要幫忙的人協助以外，也是對自己工作能力最直接的[賦能（ Empowerment ）](https://zh.wikipedia.org/wiki/%E8%B3%A6%E6%AC%8A)、覺察到自己已有能力可以助人。

## 我如何與冒名頂替者症候群相處（心得分享）
- 理性認知自己現在的狀態，不需要有過大壓力

	拿普遍會被當作比較標的、所謂的「本科系畢業」的工程師來說，即使大學／研究所時並非專精該領域，也在電腦科學的領域耳濡目染了數年。若在學習新技術或概念上，自己比起本科系畢業的朋友「開竅」較慢，需要認知到其僅是因為欠缺此領域所用到的知識與認知架構而已。比起為此而懊惱焦慮，將注意力轉到規劃及調整學習的方式上會來得較實際些。

- 參加聚會

	在聚會中遇到的人，每個人都有值得借鏡，或讓自己「自我感覺更加良好」地方。程式圈和其他領域相比友善許多，大部分的前輩都非常樂意分享所見所得；面對涉世未深、還在理解這個領域是怎麼運作的新朋友，也能透過心得分享與技術交流，體會到自己其實已經有能力理解、甚至是解決別人的問題。以上的聚會互動，除了是人脈積累的一種方式外，也可以是個獲得[社會支持](https://en.wikipedia.org/wiki/Social_support#Links_to_mental_and_physical_health)的地方。

- 休息，是為了走更長遠的路

	如果低落、挫敗的感覺過於強烈，而手邊的事務並沒有急到得要必須得加班完成，允許自己休息一晚。也許是約上好友碰面聊聊近況；也許是找間從未吃過的餐館用餐，重新在戶外體驗許久未仔細端詳的公園巷口；或者是關在房間裡，讓電影與宵夜做今晚的朋友；⋯⋯。不論如何，請把手上的接力棒先傳給明天的自己，並溫柔地告訴自己：今晚的休息，是為了能夠更有精神地面對明天的挑戰。

## 「路，不是比誰走得快，而是比誰走得遠」
這是當還在別的領域時，被一陣陣襲來的挫敗感而無所適從的我，有幸聽到前輩所分享的一句話。希望這篇文章能夠鼓勵到也許還在螢幕前苦惱自己是不是真的適合程式工作的你／妳。

業貴持之以恆。重點不應該放在計較起步的快慢，而是在求進步的同時也照顧好自己身心的需求，才能夠走得更遠、更長。

### 參考資料 
- [Feel like a fraud?](https://www.apa.org/gradpsych/2013/11/fraud) by Kirsten Weir on Amarican Psychology Association

- [Are you suffering from imposter syndrome?](https://www.apa.org/science/about/psa/2018/09/imposter-syndrome) by Lydia Craig on Amarican Psychology Association

### 延伸閱讀
- [Yes, Impostor Syndrome Is Real. Here's How to Deal With It](https://time.com/5312483/how-to-deal-with-impostor-syndrome/) by Abigail Abrams on TIME

- [58% of tech employees experience imposter syndrome. Here’s how to overcome it.](https://medium.com/landingfestival/58-of-tech-employees-experience-imposter-syndrome-heres-how-to-overcome-it-78172d8a2258) by CareerFoundry

- [你有 Impostor syndrome (冒名頂替症候群) 嗎？](https://brianhsublog.blogspot.com/2018/10/impostor-syndrome.html) by Brian Hsu

- [為什麼我無法坦率地擁抱成功？ — 冒牌者症候群](https://medium.com/as-a-product-designer/%E7%82%BA%E4%BB%80%E9%BA%BC%E6%88%91%E7%84%A1%E6%B3%95%E5%9D%A6%E7%8E%87%E5%9C%B0%E6%93%81%E6%8A%B1%E6%88%90%E5%8A%9F-%E5%86%92%E7%89%8C%E8%80%85%E7%97%87%E5%80%99%E7%BE%A4-2c8520a2c710) by Jasmine Lin


post-總覺得自己在工作上不夠稱職？論冒名頂替者症候群所帶來的影響

總覺得自己在工作上不夠稱職？論冒名頂替者症候群所帶來的影響

post-CI/CD 從零開始 - 使用 CircleCI 部署 Node.JS App 到 GCP App Engine

CI/CD 從零開始 - 使用 CircleCI 部署 Node.JS App 到 GCP App Engine

## 前言

「工欲善其事，必先利其器」，通常看到這個開頭，就知道今天要來介紹工具。在寫程式時，大家通常習慣的 Editor 是哪些呢? Vim、Emacs、Atom、Sublime、VSCode、<del>記事本</del>。而上述的 Editor 中，最廣為人知的就是被譽為「編輯器之神」的 Vim 和被譽為「神之編輯器」的 Emacs。由於這兩款 Editor 不同的特色與本質，形成了各自的派系並且相互歧視，因此還引發了 Editor 界的一場聖戰「[Editor War](https://en.wikipedia.org/wiki/Editor_war)」。

回到正題，這次主題的 VSCode 相較與前面兩款成神的 Editor 來講只能算是新生兒而已。但對筆者來說，選擇使用起來順手、舒服的 Editor 較為重要，接下來讓筆者稍微介紹一下這次的主角 VSCode：

- 基於 Electron 開發 <sub><small>註1</small></sub>
- 原始碼在 GitHub 上開源，並採用 MIT 授權條款
- Windows、Linux 和 macOS 等作業系統皆有支援

<small>註1：[Electron](https://electronjs.org/) 是 GitHub 開發的一個開源框架。開頭提到的 Atom 也是基於這個框架開發的。</small>

## 安裝

這邊可以直接到 VSCode 的官方網站來直接[下載](https://code.visualstudio.com/#alt-downloads)，或是透過以下方式安裝：

### MacOS
```shell
$ brew cask install visual-studio-code
```

### Linux
#### Ubuntu / Debian
1. 先到 [VSCode](https://code.visualstudio.com/#alt-downloads) 的網站
2. 下載 `.deb`，並透過 apt 安裝

```shell
$ sudo apt install ./<file>.deb
```

#### RHEL / Fedora / CentOS
- dnf

```shell
$ sudo dnf check-update
$ sudo dnf install code
```
- yum

```shell
$ yum check-update
$ sudo yum install code
```

若使用的工具不在上述或是安裝遇到問題，可以參考官方這份[文件](https://code.visualstudio.com/docs/setup/linux)

## 執行
安裝後，可以直接使用 Command Line 開啟：

```shell
$ code <path>
```

像筆者使用 MacOS，直接官網下載的檔案安裝後，在 Terminal 發現 `code` 不存在的話，請跟著以下步驟：

1. 按下 F1 或是 `cmd + shift + P`
2. 輸入 `Shell Command: Install 'code' command in PATH` 並按下 Enter

完成以上兩個步驟後，重開 Terminal 就可以使用 `code` 來開啟資料夾或檔案了

接著開啟 VSCode 後應該就會看到下面這個畫面：
![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/2AilxHBQcBuem5XGosq5PY/18f22e87da45e0bab501d86b713518e2/eBvhJSk.png)

接著就來看看 VSCode 一些功能：

### 內建 Terminal

- 快捷鍵： `cmd + ｀`

按下快捷鍵後，下方就可以看到 Terminal 的畫面，如下圖所示：

![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/3sqqye24IjeXST1YFpqGTU/419b113bfb5572170eceba630a30195e/gz8sUhu.png)

而 VSCode 預設的 Terminal 字型跟 `Editor: Font Family` 一樣，也就是 `Menlo, Monaco, 'Courier New', monospace`。如果想要更換字體，可以在設定中加入 `"terminal.integrated.fontFamily": "<字型>"`

### 設定

- 快捷鍵： `cmd + ,`

![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/4E9YubFVR6FIIaElLisFpH/8968ee696aa7eea8e64a1e1989916628/wFr1MOM.png)

按下快捷鍵後，就會看到像上方圖片一樣的設定檔畫面，而更改設定的方式有兩種

1. 如上圖，可以直接點選更改設定值
2. 點選圖片中，紅色框框的按鈕，會開啟一個 `settings.json` 的檔案，在上方的 `內建 Terminal` 部分所提到的 `"terminal.integrated.fontFamily": "<字型>"` ，也是直接加到這檔案內即可生效

而眼尖的讀者應該也發現在設定的畫面中，有區分使用者與工作區兩種，接下來就談談這兩種的區別吧！

#### 使用者
這邊的使用者，是指當前登入該台電腦的使用者，所以只要是同一個使用者，無論開啟任何資料夾或檔案，都可以使用到一樣的設定，而各個作業系統的 `settings.json` 檔案路徑如下：

- Windows： `%APPDATA%\Code\User\settings.json`
- MacOS： `$HOME/Library/Application Support/Code/User/settings.json`
- Linux： `$HOME/.config/Code/User/settings.json`

#### 工作區
而這邊的工作區，是指當前開啟的資料夾，更改這邊的設定後會在資料夾的目錄下產生一個 `.vscode` 的資料夾，裡面存著 `settings.json` 的檔案。如果是專案上想要要有些共通的設定的話，就可以更改這邊的設定達到一致性

在這邊要注意的是，工作區的設定優於使用者設定，所以當使用 VSCode 的時候，發現跟原本設定怎麼有些出入時，就先檢查一下工作區的設定吧。

### 快捷鍵
介紹工具怎麼不介紹快捷鍵呢，好好使用快捷鍵可以達到事半功倍呢，接下來讓筆者一一介紹一些筆者常用的快捷鍵：

#### 開啟快捷鍵設定的畫面
- 快捷鍵： `cmd + K` + `cmd + S`
- 更改快捷鍵的方式：
  1. 點選要更改快捷鍵的項目
  2. 點選項目前方的筆，或是按下快捷鍵 `cmd + K` + `cmd + K`
- 設定檔路徑：
  - Windows： `%APPDATA%\Code\User\keybindings.json`
  - MacOS： `$HOME/Library/Application Support/Code/User/keybindings.json`
  - Linux： `$HOME/.config/Code/User/keybindings.json`

#### 將整行向上(下)複製
- 快捷鍵：
  - 向上複製： `alt(option) + shift + up`
  - 向下複製： `alt(option) + shift + down`

有時候遇到一樣的東西要寫很多行，還在使用 複製 + Enter + 貼上嗎？不如來試試看這個快捷鍵，這邊筆者有更改過快捷鍵，只要按下 `cmd + up` 或是 `cmd + down` 就可以快速地向上或向下複製一樣的東西了，如果要複製多行的話，把要複製的那幾行選取起來，再按下快捷鍵即可

#### 更改當前檔案的 language mode
- 快捷鍵： `cmd + K` + `M`

#### 開啟 Markdown 的預覽畫面
- 快捷鍵： `cmd + K` + `V`

#### 快速選取「下一個」與選取項目相同的項目
- 快速鍵： `cmd + D`
- 使用方式： 選取文字後按下快捷鍵
- 示意圖：
  - 點選前： 

![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/5nH9tmBoRPWXzSwyREj2sn/fd59b7197e2fe4fcefe99313f33f7d80/yMXtpc0.png) 

  - 點選後：

![post-VSCode 的奇幻旅程](//images.ctfassets.net/8er52l3j5u76/1NYaEKcLVCFR0Pl84Cn55E/30ca82d6a8dd78e5b0c6c5e11fa1f7bd/0KiFHRS.png)

#### 快速選取「所有」與選取項目相同的項目
- 快速鍵： `cmd + L`
- 使用方式： 選取文字後按下快捷鍵

#### 快速開啟目標檔案
- 快速鍵： `cmd + P`
- 使用方式： 按下快捷鍵後，輸入要開啟的 `檔案名稱` 或是 `路經 + 檔案名稱` 後，按下 Enter 即可開啟

#### 到達指定行數
- 快速鍵： `control + G`
- 使用方式： 按下快捷鍵後，輸入要到達的行數並按下 Enter，即可到達該行數

#### 註解
- 快速鍵： `cmd + /`

以上就是筆者日常常用的快捷鍵，如果有其他需求，不如先找找快捷鍵的設定裡面，有沒有各位需要的快捷鍵功能喔

### 套件 Extension
在 VSCode 裡面按下 `cmd + shift + Ｘ` 或是前往 [VSCode Marketplace](https://marketplace.visualstudio.com/vscode) 都可以來尋找並安裝所需要的套件。如果是初次使用 VSCode 或是不知道該裝什麼套件的話，可以在 Extension 搜尋的地方輸入 [Show Recommended Extension](https://code.visualstudio.com/docs/editor/extension-gallery#_workspace-recommended-extensions)，就會列出 VSCode 建議安裝的套件，不過這邊還是要依照每個人使用需求去安裝。

如果是其他 Editor 使用習慣的使用者， VSCode 也有對應的快捷鍵可以安裝，只要按下 `cmd + K` + `cmd + M` ，就會列出其他 Editor 快捷鍵的套件以供安裝，以下推薦幾個筆者使用的套件：

- [Ruby](https://marketplace.visualstudio.com/items?itemName=rebornix.Ruby)
- [Live Server](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer)
- [Live Sass Compiler](https://marketplace.visualstudio.com/items?itemName=ritwickdey.live-sass)
- [Material Icon Theme](https://marketplace.visualstudio.com/items?itemName=PKief.material-icon-theme)

## 結語
我們 VSCode 的啟航就到這了，大家或多或少對 VSCode 有進一步的認識 <del>吧（？</del>

透過這次的介紹，希望可以讓各位將 VSCode 打造成更順手的 Editor，而下一次將帶領大家探索 Extension 新大陸，並試著寫出屬於自己的套件。(ง๑ •̀_•́)ง


post-VSCode 的奇幻旅程

VSCode 的奇幻旅程


## 前言

大家自助旅行時喜歡搭車還是自駕呢？有經驗的旅人會說「看情況」。熱門景點大多交通便利，雖然行程多少會受到路線和班次限制，但整體來說一般還是會因為各種方便，選擇搭乘大眾交通工具吧。那如果是要去比較特別的景點的話呢？或者是雖然是要去四通八達的地方，但帶了一家老小呢？ **你確定你真的要帶著父母（或小孩）和大包小包的行李，在沒有電梯的月台狂奔去趕兩小時才一班的車嗎？** 這種情況下，正常人都會勸你們跟團或自駕的。

專案開發其實也是類似的狀況。敝公司的讀者想必對 Ruby on Rails 都很熟悉；Rails 自 2005 年發展至今，除了框架自身已相當成熟之外，周邊更有完整的生態系和社群支撐。也因為如此，即便 [Ruby 每年都被宣告死亡](https://isrubydead.com/)，在競爭激烈、兵貴神速的市場上，Rails 仍然是業界「快速開發」的首選。

> 「速度是非常強力的武器，充滿魅力又帥氣，但即便如此也不是無敵」排球少年第 290 話

然而，就是這個然而，Rails 雖然「各種方便」但絕非萬能。Rails 的哲學是以遵循慣例來換取開發速度，更重要的是市面上大部分的業務需求也確實都能在這個框架下得到很好的成效。但換個角度來說，當你的業務需求就是和所謂的 The Rails Way 無法順利配合，或者你真的就是不喜歡 Rails 包山包海的設計思維的話，Ruby 工程師有其他的選項嗎？

答案是有的！Ruby 社群其實一直都有類似的討論和專案，像是今年 Rubyconf Taiwan 就有勇者挑戰了筆者個人也滿喜歡的 Trailblazer（[開拓者們建立鐵道的辛酸血淚史 by WenchuanLin](https://www.youtube.com/watch?v=fyuSUKfwwVM)），我們最近也有在客戶的 Rails 專案中引進 operators 的概念來整理商業邏輯。不過，今天要介紹的不是 [Trailblazer](http://trailblazer.to/)，而是常和它一起被提到的輕量 MVC 框架，[Hanami](http://hanamirb.org/)。

> Hanami 原本的專案名稱是 Lotus，但後來為了避免和 IBM 的 Lotus 商標混淆就改名了<del>有用過 Lotus Notes 的老人請舉個手</del>。Hanami 就是日文的「賞花」，除了和原本的蓮花相關，也帶了向源自日本的 Ruby 致敬的意義。

世界上沒有完美的技術解決方案，大多數時間我們都是在不同的問題中做取捨（trade-off）。就像自駕雖然給了旅人自由的移動手段，但取而代之的是你必須自己看地圖找路、注意行車安全，還需要掌握加油站、休息站、停車場資訊等，絕對不會比較輕鬆。

如果說 Rails 的特色是鋪好了一套包山包海的軌道，只要照著 The Rails Way 往前進就能到達目的地，那麼 Hanami 的賣點則正好相反：「The web, with simplicity. 」千萬別誤會，這裡說的 simplicity 指的是回歸「單純」，不是說開發上比較簡單（笑）大略整理一下 Hanami 的特色：

- 背後哲學是 Domain-Driven Design
- 尊崇 PORO（plain old ruby object），不對 Ruby core class/stdlib 做 monkey patch <del>AcitveSupport 表示</del>
- 主張顯式優於隱含（explicit over implicit）
- 遵循單一功能原則（single responsibility principle）
- 不做 DB 層的 callback

雖然好像一直在重覆這點，不過 Hanami 和 Rails 真的是完全不同的哲學（笑）Hanami 重視的是專案長期的維護性，這一派的開發者大多認為長期來看黑魔法反而有害（例如框架在背後偷偷做了太多東西，最後卡來卡去互相傷害，像是最近這則 [Rails issue#36844](https://github.com/rails/rails/issues/36844)），因此在設計上採用了完全不同的作法。當然，也因為這樣，相較大家習慣的 Rails，Hanami 自然也是少了很多「開發上的便利性」，更無法否認的是它周圍的生態圈也並不完整<del>不過這邊的心態大多是「這不需要用 gem 啊為什麼不自己刻就好」XD</del>。

由於本文撰寫時 Hanami 的穩定版本為 1.3.3，但「據說」近期會釋出[變動頗大的 2.0](https://github.com/hanami/hanami/pull/975)，為了避免短時間內就被改版的杯具，下面只會以官網提供的範例大致介紹一下現況。如果讀者有興趣的話，建議可以自己走一次[官方教學文件](https://guides.hanamirb.org/introduction/getting-started/)體驗看看。雖然大家回到工作上應該還是繼續以寫 Rails 為主，但如果 Hanami 的思維能為各位帶來一些不同的刺激，那筆者寫這篇文章也算是有點意義了。

## 建立專案

```text
$ gem install hanami
$ hanami new bookshelf
$ bundle install
$ hanami server
```

咦？怎麼好像有點眼熟？不過來看看 Hanami 幫我們建了哪些東西：

```text
$ cd bookshelf
$ tree -L 1
.
├── Gemfile
├── README.md
├── Rakefile
├── apps
├── config
├── config.ru
├── db
├── lib
├── public
└── spec
```

乍看之下依然是 87 分相似，但其實已經出現重大分岐了。Hanami 的架構是將產品的核心（application core）和其對外介面（delivery mechanism）徹底分開；前者安排在 `lib` 目錄下：

```text
$ tree lib
lib
├── bookshelf
│   ├── entities
│   ├── mailers
│   │   └── templates
│   └── repositories
└── bookshelf.rb
```

後者則以應用程式為單位，各自座落在 `apps` 目錄內，每個應用程式另有各自的 controller、view 等。預設的應用程式目錄為 web。

```text
$ tree apps/web
apps/web
├── application.rb
├── assets
│   ├── favicon.ico
│   ├── images
│   ├── javascripts
│   └── stylesheets
├── config
│   └── routes.rb
├── controllers
├── templates
│   └── application.html.erb
└── views
    └── application_layout.rb
```

## Application Core
對照 Rails 就是 MVC 的 model 部分，自動產生的指令也非常眼熟：

```text
$ hanami generate model book
      create  lib/bookshelf/entities/book.rb
      create  lib/bookshelf/repositories/book_repository.rb
      create  db/migrations/20170406230335_create_books.rb
      create  spec/bookshelf/entities/book_spec.rb
      create  spec/bookshelf/repositories/book_repository_spec.rb
```

### Model => Entity & Repository

不過在 Hanami 裡並沒有 `model` 這個目錄，而是依 DDD 的概念，分成 `entity` 和 `repository` 兩部分。簡單來說，`entity` 是商業邏輯的核心，是用來表現持久層（persistance layer）資料的 immutable 物件。實際上和持久層互動的則是 `repository`（和 git 那個無關）。假設我們已經建好 migration，實際操作起來大概是這種感覺：

```text
$ hanami console
irb> repository = BookRepository.new
irb> book = repository.create(title: 'Hanami')
irb> book.title # => 'Hanami' 
```

`Hanami::Repository` 提供了 `create`, `update`, `delete`, `all`, `find`, `first`, `last`, `clear` 的介面。要注意的是，這些全都是 private 方法！這是因為在 Hanami 的思維裡，開發者不應該直接把整串的 query 曝露在外面，像是：

```ruby
BookRepository.new.where(author_id: 23).order(:published_at).limit(8)
```

而是應該要寫出意圖明確的 API：

```ruby
# lib/bookshelf/repositories/book_repository.rb
class BookRepository < Hanami::Repository
  def most_recent_by_author(author, limit: 8)
    books
      .where(author_id: author.id)
      .order(:published_at)
      .limit(limit)
  end
end
```

除了程式意圖明確之外，這樣做的好處還有方便做孤立測試，也可以避免程式和底層資料庫的耦合。這部分的實做是以 [ROM](https://rom-rb.org/) 和 [Sequel](https://github.com/jeremyevans/sequel) 為基礎，有興趣的話可以再自行研究。

另外比較特別的是，由於 Hanami 的 validation 和 Rails 的作法有根本上的不同，`entity` 層是完全不處理 validation 的（後述）。

## Delivery Mechanism

在 Hanami 的架構中，業務邏輯是共用的（集中在上述的 `lib` 裡），但業務邏輯的應用可以有很多種，例如網站（`apps/web`）、管理介面（`apps/admin`）、對外 API（`apps/api`）等。每個對外介面有自己的目錄，裡面有各自的 controller 和 view 等內容。如果用 Rails 的說法，等於是從設計上就鼓勵你把東西拆成 engine 來做。

### Controller => Action

指令開始和 Rails 不太一樣了！由於同一個專案內可以有多個應用程式，因此需要在 generator 中指定。另外要注意的是，參數是 `action` 不是 `controller`（但檔案是建在 `controllers` 目錄裡）：

```text
$ hanami generate action web dashboard#index
      create  apps/web/controllers/dashboard/index.rb
      create  apps/web/views/dashboard/index.rb
      create  apps/web/templates/dashboard/index.html.erb
      create  spec/web/controllers/dashboard/index_spec.rb
      create  spec/web/views/dashboard/index_spec.rb
      insert  apps/web/config/routes.rb
```

相對於 Rails 是習慣把 RESTful 的七大神器都寫在同一個 controller 上，Hanami 的作法是把每個動作（`action`）拆成單獨的檔案，大概是長這樣：

```ruby
# apps/web/controllers/dashboard/index.rb
module Web
  module Controllers
    module Dashboard
      class Index
        include Web::Action
        expose :greeting

        def call(params)
          @greeting = "Hello"
        end
      end
    end
  end
end
```

這裡的 convention 是每個 action 都要實做 `call(params)` 的方法，再用 `expose` 將值開放給 view/template 使用。而 Hanami 將每個 action 拆開來，最大的好處就是方便測試，像是可以輕鬆模擬 request 的 header 和 params：

```ruby
# spec/web/controllers/users/show_spec.rb
require_relative '../../../../apps/web/controllers/users/show'

RSpec.describe Web::Controllers::Users::Show do
  let(:action)  { Web::Controllers::Users::Show.new }
  let(:format)  { 'application/json' }
  let(:user_id) { '23' }

  it "is successful" do
    response = action.call(id: user_id, 'HTTP_ACCEPT' => format)

    expect(response[0]).to eq(200)
    expect(response[1]['Content-Type']).to eq("#{ format }; charset=utf-8")
    expect(response[2]).to eq(["ID: #{ user_id }"])
  end
end
```

### View => View & Template

相形下之 view 還滿單純的；有仔細看 generator 的產出的話，會發現 Hanami 也同時幫我們產生好了 `views` 和 `templates` 的檔案。其中 `view` 是負責把 `template` render 出來的物件，前者大致可以用 decorator 來想像，後者就是等同 Rails 的 view（Hanami 支援包括 erb、slim、haml 在內的各種常見 template engine）。請注意範例中使用了在 controller 中被 `expose` 開放的值：

```ruby
# apps/web/views/dashboard/index.rb
module Web
  module View
    module Dashboard
      class Index
        include Web::View

        def welcome_message
          greeting + " and welcome"
        end
      end
    end
  end
end

# app/web/templates/dashboard/index.html.haml
%h1 Dashboard
%p= welcome_message
```

### 表單

Hanami 本身提供了內建的 form builder，支援所有 HTML5 的表單元件。其最大特色在於「form builder 語法不因 template engine 不同而改變」：

```ruby
# erb
<%=
  form_for :book, routes.books_path do
    div do
      label 'Title'
      text_field :title
    end

    submit 'Create'
  end
%>
```

```html
# 產出以下 html
<form action="/books" id="book-form" method="POST">
  <div>
    <label>Title</label>
    <input type="text" name="book[title]" id="book-id" value="">
  </div>
  <button type="submit">Create</button>
</form>
```

理想上是要能做到像 erb 那樣，一整段可以直接覆製貼上的 block，不過目前 [haml/slim 的支援](https://github.com/hanami/view/issues/122)還有點美中不足，需要自己補上前綴記號：

```ruby
# haml/slim
= form_for: book, routes.books_path do
  - div do
    - label 'Title'
    - text_field :title

  - submit 'Create'
```

雖然也是可以在 haml/slim 裡寫 inline ruby 再去輸出，不過那樣的話還不如直接寫在`view` 裡算了：

```ruby
# apps/web/views/books/new.rb
module Web
  module Views
    module Books
      class New
        include Web::View

        def form
          form_for :book, routes.books_path do
            text_field :title

            submit 'Create'
          end
        end
      end
    end
  end
end

# app/web/templates/books/new.html.haml
= form
```

不過筆者個人的哲學是 `view` 不該處理 HTML（反之，`template` 不該處理邏輯），不管上面哪種寫法心裡都有點抗拒，所以還是希望這點在 Hanami 2.0 裡能有所改善。

### 資料驗證

前面提到 Hanami 和 Rails 在資料驗證上有根本的不同。請回想一下：Rails 的作法是先把物件生出來，再對物件去做驗證。這固然有它方便的地方，但隱藏的風險是我們會產生出很多「[有問題的物件](https://solnic.codes/2015/12/28/invalid-object-is-an-anti-pattern/)」。Hanami 的作法則是先針對 params 做驗證，驗證成功才會產生物件，等於是從源頭迴避掉上述的問題。

除此之外更不一樣的是，在 Hanami 的思維中，「對 params 的驗證」和「寫入持久層時的驗證」這兩件事也是分開的！這也是為什麼 `entity` 本身不會去做資料驗證（因為先驗證成功了才會有 `entity`），`Hanami::Validations` 也[故意沒有提供常見的 uniqueness 驗證](https://github.com/hanami/validations#uniqueness-validation)，而是鼓勵開發者自己去處理 database constraint error。

> 話是這麼說，但具體該怎麼實做[似乎還沒有結論](https://discourse.hanamirb.org/t/what-is-a-proper-way-to-handle-a-uniqueness-constraint/351/4)，然後  Hanami 作者本人是[建議寫在 interactor 上](https://gitter.im/hanami/chat/archives/2017/03/14)。Interator 的實做請參考[官方文件](https://guides.hanamirb.org/architecture/interactors/)。

那麼簡單看一下驗證的範例：

```ruby
# apps/web/controllers/signup/create.rb
module Web
  module Controllers
    module Signup
      class Create
        include Web::Action

        params do
          required(:name).filled(:str?)
          required(:email).filled(:str?, format?: /@/).confirmation
          required(:password).filled(:str?).confirmation
        end

        def call(params)
          if params.valid?
            # ...
          else
            # ...
          end
        end
      end
    end
  end
end
```

不過要講 Hanami 的 validation，就必須來看它底層的 [dry-validation](https://dry-rb.org/gems/dry-validation/1.0/)。dry-rb 也是筆者一直在關心的專案，其中最喜歡的正好就是 dry-validation 所以剛好順便推坑！dry-rb 的 gem 都可以單獨運作，手上如果有 Rails 的 side project 的話可以拿去玩看看，相信會<del>再也不想碰 ActiveRecord validation</del> 感到身心舒暢，大致看幾個範例就好：

```ruby
＃ params 一定要有 :name，需要有值，值需為字串，且長度在 3~10 之間
required(:name).filled(:str?, :size?(3..10))

# 也可以寫成 block
required(:name) { filled? & str? & size?(3..10) }

# params 不一定要包括 :name，如果有送的話也不一定要有值，但若有值的話，需要是字串
optional(:name).maybe(:str?)

# params 一定要有 :age，需要有值，值需為整數，且需要大於 18
required(:age).filled(:int?, :gt?(18))
```

當然也可以自建規則（predicates）：

```ruby
require 'hanami/validations'

class Signup
  include Hanami::Validations

  predicate :url?, message: 'must be an URL' do |current|
    # ...
  end

  validations do
    required(:website) { url? }
  end
end
```

總之是個寫起來很開心的工具，介面很乾淨，誠心推薦大家試用 XD

## 周邊生態系

這塊是 Rails 的無敵強項，天下武功唯快不破，而 Rails 的神速正是建立在這個豐厚的生態系之上。年輕的 Hanami 顯然還在努力中，有興趣的讀者可以自行參考[官方團隊推薦的套件](http://awesome-hanami.org/)，基本的東西像是前端套件、資料分頁、檔案上傳、身份驗證等也都是有的。當然如果你有心投入開源技術開發的話，這裡還是一片藍海等你來貢獻唷～

## 小結

如果你只是在寫單純的 CRUD 網站的話，Hanami 不一定會是最適合的工具。但請想像一下：今天有個功能，資料流有至少三個入口，需要一次處理超過四層以上的巢狀資料，隨便就會影響到五、六張資料表，有錯綜複雜的資料驗證規則和<del>上線前才知道的</del>各種特例，最後還要視情境同步到不同資料表或打外部 API 並持續追蹤狀態…不要說不可能，以上是血淚實例（顯示為對著 ActiveRecord 痛哭）

商業需求總是瞬息萬變，認真的專案做到最後一定會超出一般的 CRUD 的範籌。這種時候，從設計上就鼓勵甚至是強迫開發者要「把東西拆小，使之不互相影響，方便測試和串連」的 Hanami 架構，對「專案的長期可維護性」是很有價值的。

最後也誠心推薦大家可以看一下 [Hanami 作者 @jodosha 今年的演講](https://vimeo.com/339279205)，裡面提到的 FP/OOP callable object 概念非常值得深思，也是貫穿 Hanami 運作方式的核心。基於這個想法而串連在一起的 Hanami、ROM、dry-rb 等專案今後會對 Ruby 帶來哪些改變，也非常令人期待！

### 參考資料
- [Hanami Guides](https://guides.hanamirb.org/)：官方教學文件
- [Awesome Hanami](http://awesome-hanami.org/)：周邊生態系
- [Hanami Cookbook](https://hanami-cookbook.stdout.in/pages/getting-started.html)
- [Rubyist Magazine: HanamiはRubyの救世主(メシア)となるか、愚かな星と散るのか](https://magazine.rubyist.net/articles/0056/0056-hanami.html)
- [What I learned building an app in Hanami](https://rossta.net/blog/what-i-learned-about-hanami.html)
- [Rails vs Hanami](http://teotti.com/rails-vs-hanami/)
- [Controllers: the Rails way vs the Hanami way](https://sipsandbits.com/2018/05/23/rails-controllers-vs-hanami-controllers/)
- [RottonSoftware: Validating records in Hanami](http://www.rottensoftware.com/validation_in_hanami/)
- [RottonSoftware: Hanami - Entities and Repositories](http://www.rottensoftware.com/hanami-entities-and-repositories/)
- [Invalid Object Is An Anti-Pattern](https://solnic.codes/2015/12/28/invalid-object-is-an-anti-pattern/)
- [Luca Guidi - Hanami 2.0 - rubyday 2019](https://vimeo.com/339279205)
- [Hanami 2.0 demo app](https://github.com/jodosha/soundeck)

### 推薦書單

- [Domain-Driven Design](https://www.tenlong.com.tw/products/9780321125217)
- [Clean Architecture](https://www.tenlong.com.tw/products/9780134494166)
- [Practical Object-Oriented Design in Ruby](https://www.tenlong.com.tw/products/9780134456478)

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>


post-Hanami - 軌道外的風景

Hanami - 軌道外的風景


時間永遠是固定的24小時這麼多，如何掌握在有限的時間內取捨事情的優先順序？

PM 手中可能會有多個專案在進行，最有可能遇到的狀況，例如：

你一早進到公司，正打開電腦要回 A 專案客戶的訊息，結果不到兩秒鐘， B 客戶問你能不能開個簡短的視訊會議討論他剛剛新開的 issue，接著 C 客戶突然又在群組上問你昨天會議的事情，然後同事走過來問你午餐要吃什麼(咦)。

是的，彷彿受到詛咒一般，點開什麼東西，事情就會一卡車的跟著飛來XD

>做事之前，先排列好優先順序，勇者打怪也是要照步驟來的。

## 優先順序
### 以有限的時間為前提，做出取捨

手中有太多事時，如同前面所提到，在有限的時間內優先處理重要且緊急的事情，可以從下面的象限圖，將你手中的事情先大致分為四塊：

(請看我<del>簡單明瞭的</del>象限圖表)

- 緊急且重要的事情
- 緊急但不重要的事情
- 不緊急但重要的事情
- 不緊急也不重要的事情

用上述的四象限去安排優先順序，比起遇到什麼事就先解決什麼事，倒不如從優先緊急的事情下手，對於自己的時間安排會更好掌握。

以專案管理上會遇到的狀況來說，若時程緊縮無法調整的時候，也可以依照此象限表去跟客戶協商哪些功能或是畫面是最緊急重要的，進而做出取捨。

但我有看過另一種說法，通常我們做不重要又不緊急的事情<del>總是最愉快的，有時候甚至最快完成，例如：追劇打遊戲。</del>

## 排程

>我為什麼需要為自己的時間排程？
>—— 排程表可以一眼看出整個時間的分配計劃

確定好需要安排的事項後，將它們記在任何你擅長使用的排程工具上，遇到計畫調整時，可以較為輕鬆直覺地去安排。

排程這個動作也可以運用在專案管理上，你可以使用排程表去和專案成員 or 客戶討論議題，最起碼你手上有個可以直接調整的時程表，方便雙方討論，減少溝通成本。

排時程表除了『提醒自己有這些待辦事情』外，也有『應對突發狀況而需要調整』時，可以一眼看出整個計畫的走向，從而去迅速的協調安排的功能。

>有時候會有這種疑問：專案就算排程了，也只是預估的時間，跟實際上所花費的時間還是會有所差距，那為什麼要排程?

就像出去旅行，也會大致安排幾個今天要吃的食物 / 要去的景點，比起毫無排程，有安排過後的行程可以掌握到大概有哪些事情需要去完成，調好整體專案的速度與步驟，隨時可以應付變動，搭配最前面提到的象限表，做出取捨或是應對方法。

## 適度留白

>那些平時被你疏忽的小事，也會佔據你的時間。

不是當下緊急的事情，常常容易被忽略去估算花費的時間，覺得總會有時間去完成。舉例來說：每天大概會花費30~60分鐘整理各專案的進度，又會花 15-30 分鐘去準備隔日會議的內容。

又例如，預估時程時，開發前的評估+研究，跟開發完成後的測試時間，看起來只是普通的兩件事，但其實這後面有許多隱藏成本，例如評估研究時，跟客戶雙向溝通的時間成本、還有測試時出現 bug 時，解決也需要時間，小事疊加起來，耗掉的時間也是非常可觀的。

所以在行程前後通常會再抓一些餘裕，是用來應對有意料外的狀況發生時，還有緩衝的時間可以消耗。

## 搭配專注的爆發力，不可小覷

在每件執行的事情上，最好將一切外在的干擾排除，保持一定的高專注力，全數貫注於手頭的事情上，將進度衝刺到最大值。

公司工程師們曾經跟我討論過一個話題，打 code 有時候打到一定的程度時需要高度專注與心力投入，被打擾的話，要再度切回原本的思緒與高專注力是有困難的，就像你算數學算到一半，有人叫你寫作文，寫完再繼續切回去算數學一樣，心情很難恢復啊——！

## 結語

上述所提的幾個小主題，可以幫助你在時間上作出較合理的時程安排，避免讓自己陷入什麼事都想做，卻什麼事都沒做完的狀況。

延伸到專案上的話，除了排優先度的先後順序外，難免會有功能必須做出取捨，如同前面提到，可以幫你節省大量的溝通與時間成本，希望對於有興趣研究時間管理與時程安排的你，可以增添一些幫助 :)

post-勇者，成為時間的支配者吧！

勇者，成為時間的支配者吧！


PM 除了常被討論到的溝通、專案管理技能，在團隊中是否具備補位能力，也是能否讓團隊成員妥善發揮的重要指標，尤其在小團隊協作中，善於補位的 PM 能給的 buff 效果也會更為顯著。

那什麼是補位？補位又該做什麼呢？

簡單來說，在專案過程中能讓開發流暢進行，但沒有專人負責、沒被注意到、可能讓夥伴被打斷的事項，或是需要反覆確認的細節等，都會需要有人能適時補上空缺。當然，這也不僅是 PM 的責任，就像出團打副本，如果每個人都能靈活支援彼此，應該都能滿載而歸才對 XD

而在小團隊中， PM 最常見的補位就是 QA。

團隊協作中難免會出現溝通過但認知不同的狀況，或是開發中沒有注意到的盲點，若能在 QA 這道防線中被察覺，就可以在功能上線或交付前找到問題，早發現早治療。

接著，就來說說 QA 必學的 Git 指令吧！

## 複製專案到本機

QA 時常需要在本機端進行測試，這時我們會利用 `git clone` 這個指令取回線上的 Repository，在[這篇文章](https://gitbook.tw/chapters/github/clone-repository.html)裡有包含圖形介面及指令的解說，在此就不多贅述，接下來的介紹也將以終端機上的操作指令為主。

（專案複製到本機端後，記得詳讀當中的 README 文件把專案環境先架設起來喔！）

## 切換分支

多人協作的專案常會採用多分支進行開發，主要是為了不影響已上線的功能，也避免大家在開發過程中你等我、我等你這樣浪費時間，說好先各自平行發展，等確認沒問題後再一一合併回來。

使用慣例上，一個分支通常代表就一個功能或一個 Bug 的修正，在測試時就針對每個分支處理的內容驗證，可以限縮問題的範圍，減少多個功能混合開發導致問題很難追溯的情況。

換句話說，你今天預計測哪個功能，就切到那個功能的分支去測試。

    $ git checkout feature_1
    Switched to branch 'feature_1'

使用 `git checkout` 會將遠端的分支建立一份在本機端，也可以用來在本機端切換分支，同時還是檔案救星！如果使用 Git 的過程中發現做錯事了，莫急莫慌，這指令可以用來[拯救被誤刪的檔案或目錄](https://gitbook.tw/chapters/using-git/recover-deleted-files.html)。

## 更新分支內容

如果一個分支在測試的同時也還在進行開發，那麼能隨時拉到開發人員最新推出的分支內容就很重要了，要嚴防自己的分支內容跟不上時代啊！XD

    ＄ git pull

這主要在處理當遠方的分支內容更新時，要讓本機能同步成最新的狀態，這樣就能確保自己不會測到過時的內容，也避免開發人員已經修正過的問題沒有被注意到而造成誤解。

雖然看似單純，但 **git pull** [背後的故事](https://gitbook.tw/chapters/github/pull-from-github.html)可不只這樣而已！搭配不同參數還有不同奧妙，就留給有心人自己挖掘了。（笑）

## 新增/查看目前分支

有時候，一些簡單的設定檔修改，也是 PM 可以協助的範圍，這時可能就需要加入新的分支，用來測試加入或更新的設定檔是否正確。例如：我們試著新增一個叫作 feature_2 的分支。

    $ git branch feature_2

發現好像什麼事都沒有發生 o_oa
那要怎麼確認這個分支到底有沒有被加出來呢？
其實上述指令去掉後面的 branch name，就可以用來查看分支列表。

    $ git branch
      feature_2
    * feature_1
      master

看起來這個分支有被加出來了，但怎麼確認我目前在哪個分支上呢？
上面的例子裡，分支名稱前的星號稱為 **Head** ，標示的就是目前所在的分支，要在新分支上調整設定檔的話，記得先利用上面説的 `git checkout` 指令切換過去唷！

    $ git checkout feature_2
    Switched to branch 'feature_2'

## 將檔案交給 Git 做版本控制

PM 除了在協助 QA 時會頻繁地切換分支外，偶爾也會協助更新設定檔這些簡易的修改，如果說前面的指令主要在切換版本，這裡要提的就是將協助修改或新增的檔案上傳到 Git 加入控管所需的相關指令。

當我們在目錄裡新增了一個 Git 之前完全不認識的檔案 `hello.html` 後，可以利用 `git status` 這個指令來查看目錄當前的版控狀態。

    $ git status
    On branch master

    Initial commit

    Untracked files:
      (use "git add <file>..." to include in what will be committed)

	          hello.html

此時 Git 表示：這誰啊？我不認識。雖然發現了這傢伙的存在，但因為沒聽說過這位想幹嘛，所以`hello.html` 就先列為 untracted file 囉。

但 `hello.html` 也是後續需要被納入版本控制的檔案，當務之急還是趕快透過 `git add` 讓 Git 知道這位之後也是快樂夥伴吧。

    $ git add hello.html

此時，終端機畫面看起來平靜無波、不起漣漪，但我們可以利用 `git status` 確認一下。

    $ git status
    On branch master

    Initial commit

    Changes to be committed:
      (use "git rm --cached <file>..." to unstage)

	          new file:   hello.html

看起來 `hello.html` 這個檔案有被順利認識並註記為新朋友了，但這其實還不算是真的加入為版控成員。`git add` 這個指令就像跟 Git 說：這位先登記錄取，之後再跟其它人一起報到的意思差不多。

等到其它需要新增、修改的檔案也透過 `git add` 登記好了之後，再利用 `git commit` 一起正式報到給 Git 儲存控管。

    ＄ git commit -m "Add some files for ..."

在 `git commit` 後加上參數 `-m` 可以直接輸入本次修改處理了什麼事情，讓其他協作者或將來的自己可以快速看懂這次的修改發生了什麼事。

完成 `git commit` 之後，總算是將這次的修改正式交給 Git 控管了！

如果想研究如何搭配圖像介面使用，或是想進一步了解更多細節，建議可以服用[這篇](https://gitbook.tw/chapters/using-git/add-to-git.html)，個人覺得對了解這些指令有奇效 XD

## 總結

這篇稍微介紹了 PM 平常會用到的一些 Git 入門指令，熟悉這些指令後就可以在不同分支中跳來跳去，一下我進來了，一下我又出去了，耶！

這些指令用起來都不難，也沒什麼毀天滅地的破壞性，建議同是 PM 的你可以試著以此為起點接觸 Git，發現它的妙用後就能做更多的應用。Git 絕對是 PM 值得一點的技能樹！

如果有興趣進一步認識 Git 的話，就走這道[任意門](https://gitbook.tw/)前往探索吧！門的彼端有詳盡、有趣、又容易理解的介紹喔！

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Git 觀念和原理嗎？
>
> 我們有開設 🔮 [坐上 Git 時光機 - 版本控制](https://5xruby.tw/courses/git) 課程唷 ❤️️
>


post-PM 也能乘著 Git 時空旅行

PM 也能乘著 Git 時空旅行


「咦？為什麼系統的訂單金額一直都是顯示成 0 元？」「從什麼時候開始有這問題的？」

主管看到訂單系統的顯示結果不正常，想問到底是怎麼一回事。但這個專案的開發團隊有二十多人，大家每天都有許多的 Commit，也許某位同事無意間改了計算稅務的功能，結果不小心跟著改到訂單顯示金額了。

如果很明確的知道問題是出在哪一個檔案的話，我在「[為你自己學 Git](https://gitbook.tw)」一書的「[【狀況題】等等，這行程式誰寫的？](https://gitbook.tw/chapters/using-git/git-blame.html)」章節曾經介紹過 `git blame` 指令可以找出指定檔案的第幾行是誰在什麼時候寫的，一下子就可以把犯人抓出來。

但是，有時候一個問題的造成，背後可能是多個程式執行之後的結果，或像是開發 iOS App 需要進行編譯才能看到顯示結果為什麼不正確，所以可能不是單純光用 `git blame` 就能輕鬆找出問題來。更何況，這個問題可能早在幾週前就發生了，只是當時沒人發現，直到現在才曝光。在這麼多的 Commit 裡，要怎麼知道從哪個 Commit 開始是有這個問題的？特別是如果大家在 Commit 訊息都沒有特別註明自己改了什麼內容的話，面對這幾百甚至是幾千個 Commit，難道只能 Checkout 到每一個 Commit，然後檢查訂單的顯示結果是不是正確嗎？

## 使用「二分法」

不知道大家有沒有玩過「猜數字」遊戲：

「請你從 1 到 100 之間猜一個數字，如果沒猜中，我會跟你說你猜的數字比答案大還是比答案小，然後繼續猜，直到猜到為止」

「50！」

「比 50 大」

「75！」

「比 75 小」

「65！」

「恭喜你，答對了」

通常一開始我們會使用「二分法」從中間的 50 開始猜，為什麼？因為這樣一次就能刪掉一半的數字，沒猜中的話，就再對剩下的另一半再切一半繼續猜，這樣應該沒幾次就能猜到答案了。

在 Git 裡有個叫做 `bisect` 的指令，也是用類似的「猜數字」的方式，可以很快把有問題的點找出來。

<i class="icon-download" aria-hidden="true"></i>檔案下載：<https://ubin.io/git-bisect>

在這個範例裡，目前總共有 23 次 Commit：

    $ git log --oneline
    6e593bc (HEAD -> master) update CSS
    e67e3cf add footer
    da11948 update CSS
    84ee212 add links
    8b59e89 add Tiger page
    711bc24 update title of Fish page
    1ee10be update page
    6a8fb89 update title
    6e3fab8 update title
    b031a2c update page
    73860fa update page
    f53c5ea add Fish page
    afa4537 add cover image
    2d15868 remove js code
    8f744f8 add Dog page
    b51f5e8 add Cat page
    da3d4b9 update CSS
    7a51f8e add Sign in form
    7e64d30 update script
    1086842 link style and script file in index
    f6b72af add stylesheet and script file
    3de629a add HTML content
    f9f14ff init commit

不知道什麼時候開始，在 `index.html` 頁面上的 Sign In 按鈕沒辦法按了（被 disabled 了）。看看上面這些 Commit 訊息，寫得實在很糟糕...根本看不出來 update 了什麼內容。

所以，除了一個一個去看到底每個 Commit 改了什麼之外，我們可以試著使用 Git 裡的 `bisect` 指令來抓問題：

    $ git bisect start 起始點 結束點

因為我確定在 `f6b72af` 的時候功能還是正常的，所以可以這樣做：

    $ git bisect start HEAD f6b72af

意思是針對目前的所在地（也就是 `HEAD`）到 `f6b72af` 這段範圍開始來做二分法。按下 Enter 鍵執行之後：

    $ git bisect start HEAD f6b72af
    Bisecting: 9 revisions left to test after this (roughly 3 steps)
    [73860fa1ba395a7db7dd34c966644f667b0b87e3] update page

這時 Git 會直接跳到差不多一半的地方，也就是 `73860fa` 這個 Commit。這時候發現功能還是正常的，Sign In 按鈕是可以按的，所以就可以跟 Git 說目前的結果是好的：

    $ git bisect good
    Bisecting: 4 revisions left to test after this (roughly 2 steps)
    [711bc2458ac4c9c87b41110a4f23224ff1536a13] update title of Fish page

這時 Git 會自動跳到差不多中間的位置，也就是 `711bc24` 這個 Commit。重新整理頁面，發現這時候功能是壞掉的...所以繼續跟 Git 說現在是壞掉的：

    $ git bisect bad
    Bisecting: 2 revisions left to test after this (roughly 1 step)
    [6e3fab83aeb14d9640337357027c167194f0c628] update title

現在看起來是正常的，所以：

    $ git bisect good
    Bisecting: 0 revisions left to test after this (roughly 1 step)
    [1ee10be0c8b8565a8d2e66e1707d90c3ef3fa07a] update page

如果結果是正常的，就是 `git bisect good`，如果結果是不正確的，就是 `git bisect bad`，在不斷的 good 跟 bad 的交錯幾次之後，最後找到答案了：

    $ git bisect bad
    6a8fb890400553b95e27996ec948fefb836cb2d6 is the first bad commit
    commit 6a8fb890400553b95e27996ec948fefb836cb2d6
    Author: Eddie Kao <eddie@digik.com.tw>
    Date:   Wed Aug 7 16:18:23 2019 +0800

        update title

    :100644 100644 bd266562ec6d1ec64e5c29f32c7190582db95958 39f7c9edc892bd2b2e916e233ad1bc3989f7a3d4 M	index.html

抓到了！看看在第一行出現的訊息，Git 告訴你「6a8fb89...cb2d6 is the first bad commit」，就是從這個地方開始壞掉的，原來是某位同事在修改頁面的時候暫時把那個按鈕關掉，結果忘記改回來...

如果 `bisect` 做一半不想做了，或是做完了，可以使用 `reset` 參數：

    $ git bisect reset
    Previous HEAD position was 6a8fb89 update title
    Switched to branch 'master'

然後就回到原本的 `master` 分支了。

雖然在這個範例只有少少 23 個 Commit，可能感受不出來效果，感覺自己一個一個 Commit 查也是可以查得到，但如果是 230 個或是 2,300 個就不一樣了。生命應該浪費在寶貴的事物上，而不是浪費在這種地方呀 :)

> 本文轉載自「為你自己學 Git」電子書之追加章節

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Git 觀念和原理嗎？
>
> 我們有開設 🔮 [坐上 Git 時光機 - 版本控制](https://5xruby.tw/courses/git) 課程唷 ❤️️
>


post-咦？這個問題是從什麼時候就有的？

咦？這個問題是從什麼時候就有的？

大家好，今天要來跟大家說一個如果是非本科系的工程師不確定上課有沒有學過，如果是本科系的應該是上課有學過，菜鳥工程師可能會不小心踩到的坑，在開始說明之前先給大家看一段程式碼。

這是一段很簡單的 Ruby 程式碼，表示調整廣播電台頻道的類別，支援預設電台的功能，也就是說使用者在按下某個按鈕，就可以跳到喜歡的頻道(話說現在年輕人還知道電台嗎？＠＠)。

```ruby
class Tuner
  def initialize(presets)
    @presets = presets

    clean
  end

  private

  def clean
    @presets.delete_if { |preset| preset[-1].to_i.even? }
  end
end

p presets = %w(90.1 106.2 88.5) # -> ["90.1", "106.2", "88.5"]
p turner = Tuner.new(presets) # -> <Tuner:0x00007fe7b08ff170 @presets=["90.1", "88.5"]>
p presets # -> ["90.1", "88.5"]
```

大家發現了嗎？ presets 已經被我們改變了，在討論為什麼之前我們先來看看有什麼方式可以傳遞引數！

## 傳遞引數的方式

1. Pass-by-reference：丟到方法裡的引數實際上只是變數的參考(reference)，修改引數就會修改到原始的變數。

2. Pass-by-value：丟到方法裡的引數是變數的值(value)，修改引數不會修改到原始的變數。

## Ruby 的引數是如何傳遞？

參考[官網的FAQ](https://www.ruby-lang.org/en/documentation/faq/4/)：

在 Ruby 中所有的變數和常數都會指向一個參考物件，除了直接使用會噴 NameError 例外錯誤的未初始化區域變數(沒有參考)，當我們指派一個變數或初始化一個常數，表示我們設定了變數或常數指向的參考物件。

意思是指派這件事情，實際上並不會產生一個複製的新物件，例如前面範例程式碼中 `presets = %w(90.1 106.2 88.5)` 表示說 `presets` 是會指向 `%w(90.1 106.2 88.5)` 參考物件的變數。

但 `Fixnum`, `true`, `nil`, 和 `false` 是例外，他們是 `immediate values`，變數會保持本身的物件而不是另外指向一個參考物件，這些例外被指派的引數會產生這個類型的複製物件。

當方法被調用時，引數被指派為參數：

```ruby
def addOne(n)
  n += 1
end

  a = 1
p addOne(a) # -> 2
p a         # -> 1
```

當傳遞的是物件的參考時，一個方法是有可能改變傳進來的可變物件(mutable object)：

```ruby
def downer(string)
  string.downcase!
end

p a = "HELLO" # -> "HELLO"
p downer(a)   # -> "hello"
p a           # -> "hello"
```

### 小結：
- Ruby 傳遞引數的方法並沒有相當於其他語言的 pass-by-reference。
- Ruby 是 pass-by-value，但是 values 是 references，Pass by reference value 可能是相對準確的說法。

---

回頭看看上面的 code，把 `object_id` 印出來觀察，presets 改變的原因是因為傳進方法的是可變物件的參考(相同 `object_id`)，當我們直接改變物件就直接改到了原來的物件。

```ruby
class Tuner
  def initialize(presets)
    @presets = presets

    clean
  end

  private

  def clean
    @presets.delete_if { |preset| preset[-1].to_i.even? }
    p @presets.object_id # -> 70140344834080
  end
end

p presets = %w(90.1 106.2 88.5) # -> ["90.1", "106.2", "88.5"]
p presets.object_id # -> 70140344834080
p turner = Tuner.new(presets) # -> <Tuner:0x00007fe7b08ff170 @presets=["90.1", "88.5"]>
p presets # -> ["90.1", "88.5"]
```

## 解決方法

上面的範例，看起來可以改成這樣：

```ruby
class Tuner
  def initialize(presets)
    @presets = clean(presets)
  end

  private

  def clean(presets)
    presets.reject { |preset| preset[-1].to_i.even? }
  end
end

p presets = %w(90.1 106.2 88.5) # -> ["90.1", "106.2", "88.5"]
p turner = Tuner.new(presets) # -> <Tuner:0x00007f9adfaa2b80 @presets=["90.1", "88.5"]>
p presets # -> ["90.1", "106.2", "88.5"]
```

因為 reject 會以傳回一個新的陣列代替更改接收端(presets)，故原本的物件並不會被我們修改到，但這並不一定是個好方法，如果我們不需要在初始化的階段就更改 presets，或是其他實體的方法才需要更改 presets，還是有可能會遇到麻煩。

**所以其實我們真正想要的是，可以用複製物件來代替指向原本物件的參考。**

## Ruby 複製物件的方法

Ruby 有兩種複製物件的方法：`dup` 和 `clone`，雖然兩者都會根據接收端建立新物件，但 `clone` 會保存原始物件的 2 項額外功能，`dup` 則不會。

### `clone` 不同於 `dup` 的 2 項額外功能：

1.`clone` 會顧及接收端的凍結狀態(frozen status)，如果原始物件已經凍結，那副本也會是凍結的。

```ruby
    object = Object.new
    object.freeze
    p object.frozen? # -> true
    dup_object = object.dup
    p dup_object.frozen? # -> false
    clone_object = object.clone
    p clone_object.frozen? # -> true
```

2.如果接收端有單例方法，`clone` 會複製單例類別(singleton class)。

```ruby
    object = Object.new
    def object.wow; :wow end
    p object.singleton_methods # -> [:wow]
    p object.wow # -> :wow
    clone_object = object.clone
    dup_object = object.dup
    p clone_object.wow # -> :wow
    p dup_object.wow # -> undefined method `wow' for #<Object:0x00007f7effa8af40> (NoMethodError)
```

所以當我們想修改物件的時候，大部分會選則用 `dup` 而不是 `clone`，因為凍結的物件無法修改或解凍，所以 `clone` 可能會回傳無法修改的物件。

## 修改程式碼

所以我們現在將程式碼改成這樣：

```ruby
class Tuner
  def initialize(presets)
    @presets = presets.dup

    clean
  end

  private

  def clean
    @presets.delete_if { |preset| preset[-1].to_i.even? }
  end
end

p presets = %w(90.1 106.2 88.5) # -> ["90.1", "106.2", "88.5"]
p turner = Tuner.new(presets) # -> <Tuner:0x00007fe7b08ff170 @presets=["90.1", "88.5"]>
p presets # -> ["90.1", "106.2", "88.5"]
```

恭喜！這樣就解決了我們一開始更改到原始物件的問題了！

## 注意

雖然我們已經解決問題了，但要留意 `dup` 和 `clone` 只會產生淺層複製(shallow copy)的物件，意思是對於 `Array` 這類的集合物件，雖然複製了容器，但並未複製容器內的元素，我們可以在不影響原始物件的情況下加入或移除元素，但是如果我們試圖要修改 `Array` 裡的元素，就會修改到原始元素，例如：

```ruby
array = ["Polar"]
p dup_array = array.dup << "Bear" # -> ["Polar","Bear"]
p dup_array.each { |element| element.sub!("lar", "oh") } # -> ["Pooh", "Bear"]
p array # -> ["Pooh"]
```

可以看到我們還是修改到原始物件的元素了，編寫自己的類別的時候我們可以複寫 `initialize_copy` 這個方法來控制複製過逞的深度，如果需要使用既有類別深層副本的物件，就必須自行處理。

另外有一個方法是可以使用 [Marshal](https://ruby-doc.org/docs/ruby-doc-bundle/ProgrammingRuby/book/ref_m_marshal.html) 類別來序列化，然後再對集合及其元素進行序列化還原：

```ruby
array = ["Polar"]
p dup_array = Marshal.load(Marshal.dump(array)) << "Bear" # -> ["Polar","Bear"]
p dup_array.each { |element| element.sub!("lar", "oh") } # -> ["Pooh", "Bear"]
p array # -> ["Polar"]
```

使用 `Marshal` 會有相當的限制，除了時間，他要對物件序列化並還原序列化，還必須考慮記憶體的需求數量。複製的物件將會佔用它自己的記憶體空間，如此一來使得 `Marshal::dump` 建立序列化位元組資料流，因此假如載入大型物件會使得程式大幅增加記憶體需求。

另一個問題是 `Marshal` 並非可以對所有的物件作序列化，例如 IO 類別的實體、單例物件(singleton objects)等，會引發 TypeError 的例外。

## 總結

- 大部分的情況我們使用 `dup` 就可以解決想要複製物件的問題了，但如果我們可以了解這些限制能讓我們將來在需要做深層副本的時候遠離麻煩。
- Ruby 表現得像為不可變物件傳遞值(pass-by-value)，為可變物件傳遞參考(pass-by-reference)。
- `dup` 和 `clone` 只會建立淺層副本。
- 大多數物件來說，`Marshal` 能在需要時用來建立深層副本。

### 參考： 
[Effective Ruby](https://www.effectiveruby.com)

---

>  👩‍🏫  __課務小幫手：__
>  
> ✨ 想掌握 Ruby on Rails 觀念和原理嗎？
>
> 我們有開設 🏓 [Ruby on Rails 實戰課程](https://5xruby.tw/courses/ruby-on-rails) 課程唷 ❤️️
>

五倍紅寶石・專業程式教育機構

ASTRO Camp

線上課程

短期課程

技術文章

五倍消息

技術文章

總覺得自己在工作上不夠稱職？論冒名頂替者症候群所帶來的影響

CI/CD 從零開始 - 使用 CircleCI 部署 Node.JS App 到 GCP App Engine

VSCode 的奇幻旅程

Hanami - 軌道外的風景

勇者，成為時間的支配者吧！

PM 也能乘著 Git 時空旅行

咦？這個問題是從什麼時候就有的？

新手不小心會踩到的坑：我真的複製出物件了嗎？

訂閱文章

電話 | (02) 2331-5247

信箱 | [email protected]

地址 | 10046 台北市中正區衡陽路 7 號 5 樓

專業課程

ASTRO Camp

線上課程

短期課程

關於我們

關於五倍紅寶石

聯絡我們

媒體報導

加入我們

部落格

技術文章

五倍消息

幫助與政策

常見問題

隱私權政策

服務條款