《星箭廣播》112 集——軟體工程師團隊怎麼工作?Pair Programming 實戰經驗談(ft. 資深工程師小朱)|節目逐字稿

| |

本文為《星箭廣播》112 集——軟體工程師團隊怎麼工作?Pair Programming 結對開發實戰經驗談(ft. 資深工程師小朱)訪談逐字稿,為了方便閱讀,內容經過編修。本集節目介紹與相關連結請到此頁面閱讀。

本集使用說明&來賓介紹


Titan: Hi ,大家好,歡迎收聽星箭廣播第112集,我是主持人 Titan。

今天呢,我們邀請到一位特別來賓,他是 Perpetual Protocol 的資深工程師朱昱任,我們等一下在節目裡面會叫他小朱。 Perpetual Protocol 這家公司呢,它是一個去中心化的永續合約交易所,跟區塊鏈有關,等一下我會請他來跟大家介紹一下他們公司在做什麼。

今天這個主題呢,邀請到小朱來上節目,主要目的是想要請他來跟大家聊聊工程師的團隊是怎麼工作的,那我們現在先請他來跟聽眾打招呼,順便請他來自我介紹一下,他之前參與過蠻多開源專案,我覺得我們的聽眾有很多可能有聽說過。

小朱Hi ,大家好,我是朱昱任,那大部分的人,大家都叫我小朱。那我自己本身主要是網站前端的開發,那其實我自己很喜歡開發一些小工具,像我最近就在做一些自動化記帳的軟體等等,就是這類型的小工具做的滿多的。

我自己也蠻喜歡參加開放原始碼的開發專案。之前有參加過 Mozilla 的 Firefox OS 的開發,它是一個手機的 OS 。那除了這個以外呢,我也參加過蠻多 g0v 相關的開發,大部分主要在做一些災害物資的相關的管理,有做一些議員跟立委投票相關的資料,後來也花了蠻多時間在做跟勞基法相關的一些開放源碼的資料的整理,等等的這些東西。

那因為我一直都蠻喜歡做開放原始碼的專案,所以做這些事情其實讓我覺得蠻有趣的。而且其實我們現在的公司, Perpetual Protocol 其實也有很多都是開放原始碼的專案,讓我在工作上其實還蠻開心的。

啊,其實我也蠻喜歡寫作的,我不是專家啦,但是我還蠻喜歡寫一些東西的,像是軟體開發啊或是旅遊等等的,都會有寫這方面的東西。

Titan對小朱參與過的開源專案有興趣的聽眾,可以去我們的 Show Notes 找相關的連結來參考,或者是如果你對他寫旅遊啊,還有咖啡,或者是他好像還有寫過 MIDI 的程式,就是用手機上面,用那個叫做 Web MIDI 吧,我記得。他在 Medium 上面有寫一篇文章,就是開發這個東西可以讓你用手機直接產生一個像鋼琴鍵鍵盤的東西做音樂,有興趣的聽眾可以去看我們的 Show Notes 。

前面有說我們今天請小朱來,是要跟大家談工程師是怎麼工作的,那我先交代一下事情的脈絡喔。

首先呢, Perpetual Protocol 的共同創辦人之一,小朱的老闆 Tempo 馮彥文,其實就是我們節目的常客,跟我一起主持過很多集的 Cjin 程希瑾的先生。以前我們有訪問過 Tempo ,當時他跟他的 partner – 李紹剛 Wraecca ,也是現在 Perpetual Protocol 的共同創辦人,他們當時還在探索可能接下來的創業題目。那一次的採訪裡面,我有請他談比較多關於創業的一些想法,有興趣的聽眾,也可以去我們 Show Notes 的連結讀一下那一次的採訪。

之所以會有這一集啊,主要是因為 Cjin 看到我們節目《星箭廣播》常常在談各種生產力工具,還有一些工程師怎麼工作的方法,甚至我們有聊過一些跟 SARS 相關的議題。所以她就想說可以介紹小朱跟我認識一下所以就有今天這一集。

等一下我會先請小朱簡介一下他們公司, Perpetual Protocol 這家公司是在做什麼的,他們的團隊組成是怎麼樣的。先給大家有一點概念,這樣子之後他在講他們團隊怎麼工作的時候,我覺得會比較有助於理解。

接著我們就會進入正題喔,《工程師怎麼工作》,這個議題其實範圍是可以很廣的,所以我們想說要聚焦在幾個地方,今天的節目可以分成大概三個部分。

一開始我會請小朱說明像他們這樣的純軟體公司的工程師團隊是怎麼運作的。比如說怎麼開會,團隊合作,過程中會使用到哪些工具,第二個部分的會進一步的去談到他們的工作模式裡面很特別的一個部分, Pair Programming 中文叫做結對開發,或者有人可能讀中國的文章講結對編程。

那沒聽過的聽眾朋友完全不用擔心,包含如果你對區塊鏈不是很了解或者是 Perpetual Protocol 這家公司在做什麼,不知道的話那也沒關係,因為等一下小朱會用一些舉例的方式協助大家了解。

這一集我們不會談到什麼特別的技術問題,沒有工程師背景的聽眾也不用太緊張。我自己是認為 Pair Programming 是個蠻有趣的東西,可以跟大家分享我以前在網上讀到一些有趣的故事。

我自己好像是在大概七、八年前, 2012、13 年剛入行的時候有聽過工程師講 Pair Programming ,但是就也只有僅止於聽過而已,並沒有真的看過說他們是怎麼操作。那後來到了上一次 Tempo 採訪的時候,他有跟我講,他覺得這個才是正確的開發方式。我是有點驚訝啦,但剛好這一次他們的公司就是在用這種方式在工作,所以等一下大家可以聽一下小朱分享他們的工作方式。那最後呢,我會請小朱跟大家分享一下他個人的工作方法還有一些使用到的工具。

所以今天節目大概就是這三個部分,這集一樣是遠距錄音,我跟小朱一樣是用 Zencastr ,那有一個特別地方跟大家提一下,小朱他的電腦是跟我一樣都是 M1 的 Mac 。那今天他用的是 M1 Mac 內建的麥克風,所以我想聽眾朋友如果對 M1 的麥克風特別好奇的話,也可以觀察一下我們這一次錄音的品質。

因為之前的兩位來賓 Alan 跟 Richart 他們都有各自用麥克風,就像我一樣就是專門用一個麥克風來錄音,那小朱他這次是用直接用 Mac ,我在過程當中聽我是覺得還好啦,有些人可能也在觀察說如果直接用它的麥克風來做視訊會議或者是錄 Podcast 會有什麼效果,大家可以參考一下。那另外一點就是我們今天的節目,因為顧及大家理解,所以有一部講比較多,就是在  Perpetual Protocol 關於他們公司的性質跟他們的產品還有去中心化跟區塊鏈的議題有稍微講比較多,所以請大家善用我們節目的章節功能。

如果你真的只想要聽 Pair Programming ,那你可以直接去找到那個章節,直接點進去開始聽,跟大家說明一下。

Perpetual Protocol 這家公司在做什麼?


Titan:我先請他來跟大家簡介一下他們的公司 Perpetual Protocol 。

小朱: Perpetual Protocol 是我們公司的公司名字跟產品名字都是用這個字,那我們公司主要在做的產品其實是一個去中心化的永續合約交易所。英文就是 decentralized perpetual contract exchange ,那其實這幾個字大家都看過就是去中心化跟永續合約交易所。但是你說把它全部都組在一起之後,它其實就不是那麼好懂了,所以我會把它分成幾個部分來簡介一下。

那首先要簡介的是去中心化這個東西,那我們在講去中心化以前,我想要先講一下最原始的時候人跟人之間是怎麼交易的。

那基本上在剛開始的時候啊,一般假如說我們有一個東西想要給另外一個人,拿來交換另外一個東西的時候。比如說我有魚,然後你有蔬菜,然後想要互相交換的時候,通常都是用以物易物的方法來做。

它其實是一個最基本的交流,那這樣的交流它有一個很棒的地方就是說這個互動不需要經過其他人同意,你只要進行交易的這兩個人都同意這樣的做法,那它就可以做了。那這跟去中心化其實就已經非常類似,因為它其實是中間沒有其他的中間人,只要這兩個人同意,那這樣的交易就可以進行。

那我們再想想看喔,以前這樣的交易行為,假如說到現代的時候大概會怎樣進行。大家最常進行的可能就是說 OK,那假如說我跟小明之間,我需要轉帳一千塊給他的話,通常我們就會用手機的網路銀行的 APP 去完成。那比如說就是輸入小明他的銀行是哪一間,然後還有銀行帳號是什麼,然後就可以完成了。大家使用這個東西的時候應該會覺得非常的方便喔,它可能在五秒或是十秒之內就可以做完這件事情。

但是呢,其實非常方便的一個網路銀行的 App 的使用,其實是一個冰山一角,那它就是這個露出來的一點點的冰山,這底下需要有非常巨大的基礎建設,才可以完成你現在看到的這麼簡單的一件事情。那其中就牽涉到一層層的中介人,或者說我們可以說是中介機構是要雙方都可以信任的,這樣的交易體系才可以完成。

大家可以先想一下就是說,假如說我跟小明,我們兩個是使用兩個不一樣的銀行,那這兩個銀行之間在互轉這個金額的時候,其實他們是一個有一個利益衝突的。因為假如說你從 A 銀行轉到 B 銀行的時候就代表 A 銀行這邊的錢會變少,B 銀行那邊的錢會變多。那這樣的話,雙方都需要很確定這樣的交易可以正確地進行,那不然的話其中有一個人就會損失,那另外一個人就會得利。

這兩個銀行他們要怎麼去確保對方不會欺騙我這個銀行,然後多拿一點錢或少拿一點錢呢?在台灣的解決方法是這樣的,銀行界他們有合資成立了一個機構,叫財經公司。那這個財經公司呢,會負責國內所有銀行的清算。因為大家都有投資這間公司,所以他可以說是作為銀行跟銀行之間的一個比較中立,或是比較受信任的中介機構。那有了這個機構之後呢,兩個銀行之間才可以透過這一間公司,或是這個機構來負責清算。

大家可以想一想喔,假如說我們今天沒有財經公司這樣一個機構,或這樣一個公司的話,他們之間要去怎麼去做轉帳,事實上是很困難的喔。因為假如說伺服器放我這邊的話你就會懷疑我。放你那邊的話我就會懷疑你,所以我們一定是需要有這樣中間人。

Titan大家可能會覺得財經公司沒聽過,或者是我生活上好像沒有真的跟他們打過交道,過去一年大家如果有在用衛福部的買口罩的系統,你是用信用卡結帳的,那你可能會在你的信用卡帳單看到財經公司跟你收一筆錢,我想這應該是他跟大家近期比較有直接接觸到的經驗吧。

小朱:包括財經公司啊,其實他們都是一層一層的中介機構,你在這些金融體系體底下幾乎所有事情都要透過這樣來做。比如說你開銀行,人民要怎麼相信你不會去偷他的錢呢?那其實是有政府的監管,那背後可能還有其他的金融的保險機制。

那假如你有使用過跨國匯款的話,那其實就是有一個叫 SWIFT 的組織在做跨國的清算的工作。所以說假如說你把一個一個金融服務攤開來看,它都是由環環相扣的信任體系跟中間人,就是我們所說的中介組織支撐起來的。

那我們再回想喔,我們剛剛做的那一個動作,就是我用網路銀行的 App 去轉帳,可以這麼便利的狀況下,那其實後面是有一個很巨大的金融體系跟很巨大的信任機制,跟中介機構才有辦法完成。可以就說是中心化的技術,只是大家不會特別強調,因為從以前到現在我們都是用這種方法在運作的嘛,所以它不會特別說是一個中心化的技術。

Titan剛剛小朱有提到一個信任這個詞喔,因為我們現在一般的生活在使用台灣的銀行體系,或者是金融體系的交易工具啊,或者是這種服務,已經蠻習慣了,大家對這整個活動喔,從頭到尾的信任度也很夠。可是我覺得大家可以想像一下,為什麼小朱剛剛有提到說這些中間人還有他會講一些,好像我們很懷疑銀行會不會偷我們錢,或者是兩邊的交易。比如說我匯款給小朱,中間會出什麼差錯。為什麼會懷疑?那可能大家會覺得跟自己的經驗是有點相反的嘛。因為我們都不太會懷疑這件事情。

大家可以想像在二十年前、三十年前,剛開始有網路的時候,為什麼 eBay 這家公司要在網上做拍賣,然後有 PayPal 這樣的公司出現。就是因為大家不太信任在網路上買賣,因為大家會覺得說,啊,我都看不見,我甚至不知道賣家是誰,不敢跟他買東西,我也不覺得我先付錢後他就會把貨出給我。

所以會有 PayPal 這樣子我們說第三方支付這樣的角色,他必須在中間,就是我們跟賣家的中間,那我付錢給賣家的過程其實是先把錢給 PayPal , PayPal 幫我把錢保管好,等到賣家真的有把貨物寄給我,我有收到之後,我就跟 PayPal 講說,啊 PayPal 你可以幫我把錢給賣家了,大概是這樣子的概念。

所以這個信任的建立,其實並沒有大家想像這麼理所當然。那何況是我們剛剛講的金融的交易,它其實是花我們非常多時間,才把這個體系建立起來的,比網路的時間當然還要更久。

小朱那大家其實可以想像喔,我們剛開始在網路購物 PChome 的時候,我相信大家都會覺得,啊我是不是不要用信用卡來交易,那甚至說我不要用 ATM 的轉帳來交易。那我們可能會選擇用貨到付款,那這樣其實就是跟信任有關,因為你不知道你錢給他之後,他會不會給你。貨到付款它是相對起來好像一個比較容易的方法,因為你拿到貨物的時候你交了錢,但是這個時候大家要想像,其實那個貨運也是行政體系的一環。假如說他在中間把你這個錢拿走一些,那你要怎麼去面對的問題,但是當然到現在大家都已經非常習慣用這樣的服務。也就是這樣的中介機構已經取得大家的信任,所以這樣可以比較放心的用這種方式來做交易。

Titan欸,其實小朱你剛剛講到貨到付款,我們也不知道貨運公司會把我們的錢拿去做什麼,其實我真的沒想過。

小朱對,沒有錯。因為這個其實就是因為已經太頻繁發生在我們生活中,我們就比較不會想到說,「喔,這件事情它到底會做什麼。」就是跟大家或許印像中可能會覺得銀行都會把我的錢存在戶頭裡不會去動用,但其實你仔細,假如說你去看一些資料,其實不是這樣的,他會把你的錢拿去投資或是做一些應用,那當然都是在監管範圍底下發生的。

Titan:接下來就請小朱講一下什麼是去中心化的機制。

什麼是「去中心化」?


小朱:那我們剛剛有提到就是說,有中介組織這種我們可以把它叫做中心化技術,當然以前不會有這麼講,那直到去中心化的機制產生。

去中心化的機制到底是什麼呢?

你要達成去中心化有很多種方法,那比如說我剛剛講的以物易物,基本上也是去中心化的一種,但這個時候我們想要講一下區塊鏈,這個近十年來比較新奇的一個技術。那你在區塊鏈裡面基本上有兩種角色,第一個是使用者,就是你是使用區塊鏈,那第二種叫做節點,那這個節點比較像是提供服務的角色。

那這個節點呢是任何人都可以當一個節點,你需要當一個節點的話你只要到網路上去下載一個軟體之後運行,這樣就可以了。那加入之後你不需要許可,也不需要註冊,就可以加入當成一個節點,節點主要要做什麼事情呢?

假如說有一個人,他把一段程式邏輯放到區塊鏈上之後,當這個使用者他要求要執行這段程式的時候,你需要幫他運行這段程式,所以這個就是節點要完成的事情,那作為你幫他運行這段程式呢,你在跑完這一段程式或是說這段邏輯的時候他會給你獎勵。

這邊有另外一個機制就是說,假如你不照著這個跑的時候呢,其他的節點就會來糾正你說,喔這樣結果是錯誤的。那這些節點他會再去跑一個正確的結果,那這樣就可以達成說我們是一個不特定的人來幫你執行這樣一個程式的一個網絡機制。

剛剛有提到說,假如說我們要轉錢給小明的話,可能是要跟他買一個東西嘛,這個時候其中我們就可以利用區塊鏈的方式來完成這件事情。我們可以發佈一段程式邏輯到區塊鏈上,那同時我也給小明看,這份程式邏輯是在這個地方,它的邏輯大概是長怎樣,那雙方都可以閱讀。

你可以想像,它有點像合約喔,就是我先給你一個合約然後兩邊的人都可以閱讀,確認這個合約的內容,只是這個合約它基本上就是一段邏輯,就是說我做什麼事之後,你要做什麼事情。當雙方都確認這段邏輯,或是這段合約沒有錯的時候,就可以執行這一個邏輯,或是執行這個合約來進行利益交換。

假如說我想要用1000美金來換成比如說一個比特幣,當然現在不是這個價格。那我說要執行這個事情的時候呢,其實我是會要求節點來執行這段程式的。那區塊鏈網路上的節點收到這個需求之後呢,就會開始執行,那執行完他就會收到一筆獎勵。

剛剛有提到說假如有節點他想要做惡,想要從中間得到利益,他可能會不照著程式邏輯,或是不照著合約執行,這個時候其他網路上的節點就會糾正他。而且不照邏輯執行的這個人,他就不會拿到獎勵,就可以用這個獎勵機制然後來確保所有的節點都會用同樣的邏輯來執行程式。

我們就可以說這段邏輯它一定會照著我們之前設想的方式來執行這段程式,也就是說,我付1000塊出去我一定可以拿到一個比特幣。

那我們用一個簡單的概念來比喻它其實就跟數學一樣喔,有一個網路上了的迷因它是這樣的,就是說「人生會背叛你,但是數學不會,因為數學不會就是不會。」那這個其實就跟區塊鏈一樣,這個程式當你已經發出需求的時候,它就一定會照這個邏輯執行,那它不會因為有什麼原因然後就導致不照這個程式邏輯執行。當然我這是講一個很簡易的狀況,那實際上執行的時候有很多事情需要去考慮。

Titan這樣是不是暗示說其實區塊鏈的運作是要有夠多的節點一起參與,它才可以運作的比較好,可以這樣說嗎?

小朱對。

Titan所以聽眾可以把區塊鏈這個東西想像成跟我們現在在上網,他們用的所謂通訊協定,其實是有一點類似的。

像我們講 TCP/IP 這樣的東西,其實就很像,或者是大家上網的時候看到前面那幾個 https 這個東西,就是我們講的網際網路它的協議,網際網路它的設計,既然叫網路就是有很多個點連起來。所以如果其中一兩個出什麼狀況的時候,其實不會影響到這個網路的正常運作,大家也可以把區塊鏈就想像成是像這樣網際網路這樣子的一個通訊協定,或是說它的設計的目的主要不是為了通訊,你可以講就像網際網路一樣的協定,用這樣方式去理解。小朱想要跟大家講就是中心化跟去中心化,它其實是一個光譜,有完全的中心化的專案跟完全去中心化的專案,中間有很多不一樣程度的去中心化的專案在裡面,可能不是100%,但是就是會有某種程度去中心化。

那我們剛剛解釋的就是我們在做的東西就是「去中心化的永續合約交易所」的前四個字,「去中心化。」

期貨與永續合約


小朱:接下來要講永續合約是什麼,但是我們在講永續合約之前,我們要講一下期貨。因為永續合約是一種特殊的期貨,那期貨它其實就是說我們用一個約定的價格購買一段時間之後的某一個商品的合約。

那比如說今年是2021年嘛,星巴克他想要確認明年產地的咖啡量充足,而且又希望價格可以預測,因為咖啡豆這種東西是有一個波動的價格的。那他希望在今年的時候就確定明年他想要拿到多少咖啡豆的話,這時候他可能就會跟產地的農民簽訂一個2021年的期貨契約。那比如說現在價格是多少,我們就先用這個價格來購買你未來的的價格的咖啡豆數量。

對星巴克來講他有一個好處就是,因為咖啡豆的價格是波動的,那他又希望可以拿到足夠的咖啡豆的話,這個時候他就可以確認,就是他的成本跟他到時候都會有供貨,來降低風險。

那對農民來講,有好處就是說他在今年的時候就可以確保明年的時候,他的咖啡豆一定有人買,所以那他就可以對這個東西比較放心一點,那這個東西其實就是期貨,對雙方來講雖然說它有一定的好處,那當然也伴隨著一定的風險。

比如說呢,價格是波動的,咖啡豆的價格可能高可能低,所以到時候呢它的價格可能會跟現在不一樣。那比如說價格如果變貴了,但是農民已經跟星巴克有一個契約,就要用某一種價格來收購,那如果價格比較低的時候呢,星巴克還是一樣要用一樣的錢來收購這個咖啡豆,那可能就會對星巴克造成損傷。

但是其實基本上都還是有好處的,因為他可以現在就去消除未來的某一個風險。順帶一提,我們剛剛有提到,假如說你是把你的錢給他,然後他給貨物的話,這個在期貨裡面我們就叫做現貨交割。

那所以說到現貨交割,那其實就是有另外一種形式就是現金交割。比如說星巴克欠了一個期貨契約是用20萬買了一噸的咖啡豆的合約,到期日到的時候原本咖啡農要給星巴克1噸的咖啡嘛,但是假如說是現金交割的意思,就是說這個時候雙方就會看目前的價格,來決定要給他多少金額,而不是給他咖啡豆。

剛剛說星巴克原本是20萬要給這個交易對手,然後這個交易對手要給他一噸的咖啡,如果是現金交割的意思呢,就是說我們現在先看市場的價格是多少,那假如說現在市場的價格是30萬的話,原本是星巴克的20萬給出去然後拿到1噸的咖啡豆,這個時候就會變成交易對手直接10萬塊給星巴克。星巴克這個時候手上就有30萬了嘛,那他就可以自行到市場上去買一噸的咖啡豆,所以大致上是這樣的運作方式,我們就是叫做現金交割。

這個時候我們就可以來講永續合約了,剛剛有提到永續合約它是一種特殊型態的期貨。咖啡豆例子都有講到一個交易的期限嘛,就是到某個時候就一定要交易,永續合約意思就說它是一個沒有期限的期貨。但是你反過來說你可以說它是每1個小時就到期一次的期貨,或是每一天就到期一次的期貨。

因為它每一天,或是每一個小時,一個固定時間內,一個相對短的時間內,它就會結算一次期貨。結算完之後呢,你原本的契約還是會存在,它用這種方法來達成一個看起來像是永遠都不會到期的效果。那其實你也可以說,你是每個小時會到期,或是每一天會到期一次。

Titan所以你們做的這個期貨的交易所,它們的運作方式其實跟我們所理解的期貨交易是很像的,只是底層的技術不同,可以這樣理解嗎?

小朱可以,那還有一個特殊的它是永續合約,那一般的假如說我們的咖啡市場啊,或是其他的期貨交易市場,目前還沒有像永續合約這種的交易形式。永續合約它是一個,目前在加密貨幣裡面比較常被使用到的一個新型態的期貨,但是在一般傳統市場還比較沒有這種類型的商品出現。

Titan那小朱我想請問一下你們現在在 Perpetual Protocol 上面有哪些期貨是正在透過你們的交易所來交易。

小朱現在主要都還是一些加密貨幣,比如說大家比較知道的比特幣啊,或是乙太幣等等。但是就我們的系統設計的機制它是可以擴充到一些更多或是更常見的期貨,比如說石油啊,原油啊,這些東西他其實都是可以。那當然我們在做這些事情的時候都有一個規劃,看我們到底要怎麼去做到這件事情,那這是一個比較長遠規劃,我們是確保我們可以支援這種形式,只是目前還沒有實現而已。

Titan這就好像前一段時間上市的 Coinbase 吧,他們好像說他們的目標,他們的 mission 喔,是要為這個世界創造一個開放的金融系統,那只是說他們的起步點可能就是從加密貨幣的線上錢包以及貨幣的交易所開始。根據他們的共創辦人 Brian Armstrong ,他有講過,他希望到時候錢這個東西在全世界流動的時候可以不需要那麼麻煩,有這種中間人在那邊。

假如我在台灣,然後小朱在日本好了,我要把錢匯給小朱,那我就可以透過加密貨幣跟區塊鏈的機制直接把錢給他,那中間不須要經過任何第三方所謂的中間人,比如說銀行來完成這件事情。

小朱說到這個例子的話,其實假如說我們需要在跨國之間匯款,通常都會用會 SWIFT ,雖然也是透過銀行,但其實是透過 SWIFT 這樣子的機制。

我不知道大家有沒有使用過喔,但是像我自己使用的經歷的話,你每次做一個交易大概是三天到一個禮拜,甚至兩個禮拜才能完成交易,而且你每次交易的時候要付的手續費也不見得一樣。這牽涉到他們中間可能有一個機制,然後來決定你要是怎麼去交付,那中間可能有更多的中間人,可能會有一個銀行或是兩個銀行等等的。

因為我們自己在台灣,在銀行的轉帳完全可能不會意識到這件事情有多麻煩,但是當你跨國的時候他要面臨很多法規問題的時候,就會發現這件事情當有中間人參與,又是一個特別複雜的狀況的話,就會拖得很長,而且價格上也不見得那麼透明。

團隊組成、分工、小朱除了寫程式還要做什麼?


Titan:小朱算大概有跟大家介紹了 Perpetual Protocol 他們的公司是在做什麼的,然後所謂的去中心化的永續合約交易所怎麼運作的,接下來就請他跟大家簡單講一下他們的團隊的組成,以及他們工作內容到底是什麼。這樣才有助於我們等一下要繼續往下講他們工作的方法,還有 Pair programming 結對開發。

小朱:那我們現在公司主要是有18個人,分隔幾個比較功能取向的一些團隊,第一個就是有  business develop ,商業開發這樣的團隊,主要是跟潛在的夥伴去敲定一些合作關係。那我們有 marketing ,市場行銷的團隊,那主要是推廣公司的產品,那我們有社群溝通的團隊,主要是跟社群溝通,然後讓他們知道的最新發展,跟我們最近的改變,還有他們有問題的話可以去詢問。

接下來就是我比較專注的部分,就是在工程團隊,就是再做軟體開發的,那我們在工程開發裡面又主要細分成3個模組。

第一個叫它合約團隊,其實這個合約不是紙本的合約,而是運作在區塊鏈上的合約,你可以想樣成它就是一段程式邏輯,只是它是寫在區塊鏈上,跟其他程式有一點點不一樣。然後第二個是後端團隊也就是在伺服器的部分,其實這個區塊鏈啊,核心邏輯呢它是有一個限制就是說,某一些邏輯只能在區塊鏈上做,但是某些邏輯不行,所以說有些我們沒辦法在區塊鏈上執行的邏輯,我們就會交由我們後端團隊來執行。

比如說我們要針對一些資料去做所以索引啊,或是我們有一些基礎建設,比如說我們剛剛有提到就是節點嘛,我們需要自己也成為節點的話,那我們需要由我們的後端團隊去設置自己的東西或是說其實我們跟其他的交易所之間我們自己本身會有一個套利的模組,那這個模組它同常是要拿來增加交流動性,或者是它通常需要讓兩邊市場的價格比較接近的這些東西。這些事情在合約的限制下比較不容易做到,我們就由後端團隊來做,還有很多其他的模組。

第三個模組的話其實就是前端的模組,意思就是說跟使用者互動的地方,它提供一個互動介面讓使用者用的話,我們就是在這個前端模組來做,那主要就是說我們一般使用者使用到的網站就是會由前端的團隊做的。因為我們是去中心化的公司,所以其實很多時候我們都會希望我們的東西是盡量地是開放源碼的。

有些東西如果現在不是開放源碼的話,我們的長期規劃都是希望所有東西到後面都是可以開放源碼,讓所有人都可以檢視我們的各個模組之間是怎麼樣運作的,那這樣的話使用者也可以比較信任我們的運作。

我們在這個工程團隊裡面,工作其實不會一直執著一個模組的事情,那我們會在三個模組之間轉移工作。比如說你可能,你現在是做前端,那可能過一段時間之後你就會去做後端,或者是會去做合約等等的。那在後端呢或是其他模組的成員,他們有可能就是過一段時間之後就會做其他的一些工作。

Titan你剛剛講你們公司有三個模組嘛, contract ,前端跟後端,一般在理解網路的產品的開發,大概都會很粗略地說,啊你是做前端的,你是做後端的。那對你們公司來說,合約的這個部分,它也可以把它分到前端或後端嗎?那再來是比如說前端工程師他也可以跑去做後端的東西嗎?這樣實務上會不會有一些困難,還是說在你們公司還好。

小朱第一個問題是喔, contract 它到底是算前端還是後端,它是比較接近後端的,因為它基本上也是公司的核心邏輯運作的地方。那假如說以一個一般的網站而言,它也是有分前端跟後端,前端主要要處理的問題就是使用者要如何去使用我們的東西。後端要處理的模組就是說,使用者使用我們的東西之後,它裡面實際上運作的邏輯是怎樣。

那如果說以這樣的方法來講的話我們可以說 contract 它是比較偏後端的,但是比較不一樣的地方是,在區塊鏈上執行的這個程式啊,因為它是一個去中心化的技術。所以說它在技術層面有很多跟原本的後端比較不一樣的地方,如果我們粗略的分的話其實它是可以分在後端,只是你需要一些額外的知識才有辦法掌握這樣的工作。

那第二個問題呢,我們剛剛有提到,就是說我們團隊之間會互相轉移工作,大家都可以想像,假如說今天你只做前端,你想要去做後端的話,那大概會有一個鴻溝需要跨越嘛。因為跟你原本實做的事情不一樣,因為前端主要是在聚焦在怎麼跟使用者互動,怎麼跟後端互動,或是說在 contract 的話,它就有點不太一樣。

我覺得我們公司這個問題會比其他的團隊要少一點,主要原因也就是我們今天想要提到的 Pair programming 。因為我們透過 Pair programming 的方法,其實可以讓我們在轉移我們的工作內容的時候可以更容易的上手。然後我覺得我們等一下在後面的時候可以談一下 Pair programming 怎麼樣來協助我們做這件事情可以比較平順的上手。

Titan剛剛我們在介紹小朱的時候,有跟大家說他是資深工程師嘛,但就我的了解啊,小朱你在團隊扮演的角色好像不能只是說是寫程式的工程師而已,你好像還有做很多別的事情。

小朱對啊,因為我是這個團隊剛成立的時候就加入了,那我是以資深工程師的這個角色來加入的。但是其實因為我已經在這個公司工作很久了,那當你在做越久的時候就會覺得公司有很多地方是需要其他人幫忙的,所以說當然就是角色上也做一些轉換,只是我職稱還是掛資深工程師就是了。

比如說我在外部活動的時候,有時候會掛 engineer head ,比較可以讓外面的人理解就是我的工作的角色大概是什麼。當然我做的事也不是這樣而已,平常會幫忙做一些工程上的資源的調配,比如說誰要做什麼事情啊,或者是哪個團隊需要支援,我會負責去做協調。那我也會協助安排專案的進行,跟 founder 之間來討論我們的大的目標是什麼,那這個大的目標底下,我們要怎麼把它拆成一些比較可以執行的步驟。那我也幫忙做 hiring ,就是招募,那我也會看一下公司文化大概要怎樣怎樣。

所以這樣融合下來,也可以說我做的事情大概就是雜事,但是也就是說其實因為我工作在這個公司裡面是比較久的,所以自然就會開始認為公司有哪些地方需要幫忙,或許我就是可以在開發上做得少一點。那其他時間再多安排一點時間,讓公司在運行上可以更加的順利一些。

Titan當初 Cjin 就是這樣跟我介紹的,說 Perpetual Protocol 這家公司裡面工作要怎麼運作,用什麼工具,用什麼方式工作,蠻多都是她協助安排的。剛剛在聽小朱講說他的身份,還有他去外面有參加活動的時候會掛 engineering head ,如果大家有聽我們之前有一集我們邀請到前 Twitter 工程師,現在在 Robinhood 工作的 Zero Cho,那一集在講他的職稱的時候他也說自己覺得自己的職稱雖然叫 engineering manager ,直接翻譯就叫工程經理,那只是說他覺得翻譯成中文工程經理很怪。

所以這邊大家有一個概念就是可能工程師即便是在台灣,他們在談自己的工作的時候,其實他們的文化上面很少會硬把所有的工作都翻譯成中文。像假如我們今天在銀行工作,那我們就會知道,襄理、協理是什麼角色,是做什麼的,但是如果在工程師的團隊文化裡面你可能就會聽到比較多直接講英文的,他們大概也不見得會花心思把這些英文全部都把它翻譯成中文。

Daily standup meeting


Titan:接下來就請小朱來先跟大家講一下他們工程團隊內部是這麼溝通然後這麼運作的。

小朱其實在我們工程內部呢,我們其實是有參考一個叫做 Scrum 的一個做法, Scrum 是一個在軟體開發上有很多公司會採用的一個方法。我們其實不是完全是跑 Scrum ,只是因為我們覺得這個 Scrum 裡面有很多東西值得參考所以我們會拿出來用,但是我們其實跟跑 Scrum  基本還是不太一樣。那大家如果是軟體開發的人員的話,你可能會覺得就是有點熟悉,但是又有點不太一樣的地方。

我們基本上會以兩週做一個單位,來規劃這兩週我們要排哪一些工作,那這兩週的期間我們就把它稱為一個 Sprint ,會讓團隊的成員去估計每一個工作它的大小,它的困難度,它要花多少時間,然後來決定就是我們這個 Sprint 到底要放多少工作進來。那當我們都已經規劃好這個  Sprint 它裡面的工作大概是有多少之後呢,就會開始這個 Sprint ,然後大家就會照著,有個兩週的計劃,然後來開始進行這個工作。

但是其實如果大家在開發的時候都會知道,這個 Sprint 的中間喔,很多時候都會有一些臨時的工作需要排進來。那這個時候呢,通常都會我來做這些事情,就是說想要在中間進來這個 Sprint 的工作,我們會給他做一個檢傷分類,叫 triage ,那這其實是一個急診室用的東西,就是會先把這個病人依照他的受傷的狀況然後來把他分級。

那我們對於一個新的工作進來也是一樣,假如說這個新的工作真的很急的話,我們就會請同仁一樣要去評估它的大小,然後把這個工作給排進去,那這個排進去的同時呢,我們就會再看我們這個 Sprint 裡面有沒有優先度比這個還要再低一些的,那我們會把它移出,就可以達成比較高優先程度的工作可以進來。

假如說它優先程度跟我們現在執行的工作比,它是比較沒那麼優先的,我們就會說 OK,那我們可以放在下一個 Sprint 做。那用這種方法來控制說,我們一個 Sprint 的工作量大概都是類似的,而且如果一次一個比較高優先程度而且比較緊急的事情喔,它也是可以在中間比較有彈性的把它插入到這個 Sprint 。這個基本上就是我們工程內部,以一個 Sprint 為單位來做一個會議喔。

Titan:那你們每一次的 Sprint 都可以準時的完成嗎?我們講這個衝刺都可以衝到終點嗎?那如果遇到 delay 的話要怎麼辦?是要排到下一次 Sprint 嗎?還是說這個任務就先不要做。

小朱:我得很誠實的講,通常是比較不會,那我們通常自己在完成的時候,大概可以完成70%或是80%的工作。

我覺得這邊可以順便講一下,就是我們跟 Scrum 比較不一樣的地方就是, Scrum 他們好像可能會有一個固定的範圍,他們就一定會達成。那對我們來講的話,其實我們兩週的長度,這個  Sprint 是用來估計我們這個工作到底要放多少東西進來的。所以我們比較不會說一定會抓一個期限說,喔,我們要使命必達,一定要完成,因為在區塊鏈程式的開發,在安全上其實是有它必要的考量。

當然就是優先程度或是時限當然還是很重要,但是我們不會抓一個非常死的期限,就是說我們兩周之內一定要完成一個東西。那這樣的話可能就會比較沒有彈性,或是你可能就會因為這個期限的關係,我們就這樣一個品質讓比較不好,或是它還沒有完備的東西出去,所以跟一般的  Scrum 就會有點不太一樣。

那在全公司方面呢,我們會有一個 stand-up meeting ,也就是說我們在每天早上的時候會有一個會議,那這個早上10點的時候所有公司的人都會參加,那這個會議主要的目的呢就是來更新一下狀況,還有在這個時候尋求各位的幫忙。

通常大家會花一到兩分鐘講一下以下這些事情,第一個會是,我有什麼需要幫忙的,第二個是我昨天做了什麼,第三個是我今天預計要做什麼。那這些事情它其實是一個很短的更新,主要是要讓大家知道我們到底有什麼事情是需要幫忙的。

Titan我在看大家講在講 stand-up meeting 的時候,通常那個議程的順序都是每個人先講一下昨天做了什麼事,今天預計要做什麼,然後今天要做的事情有哪些地方是需要其他人幫忙的。為什麼你們的順序好像不太一樣?是把哪邊需要幫忙放在第一個,有什麼特別的原因嗎?

小朱那這個其實是我們就是實務上做的調整。因為我們後來發現,其實我們要做這三件事情嘛,有些人他需要什麼幫忙事情會忘掉或是他不需要幫忙他就不講或者是他根本忘了這件事情了。所以我們就會把件事情排到第一個,那這個就是希望以這個為重點,我們整個 stand-up meeting 最重要的就是你到底有什麼需要幫忙的。有什麼東西卡住了我的進度,我也需要其他人協助才能做到,所以我們就把它調到第一個,那這也是跟其他的 Scrum 有一點點不太一樣的地方。

因為每個人花1到2分鐘,所以總體的長度大概是15分鐘到20分鐘。那我們不會嚴格的控制時間,但是會鼓勵大家快一點。因為大家都知道,其實這種開會有時候越長的那效果又不見那麼好,主要就是讓大家知道你需要什麼東西幫忙,這樣就可以了。那最近人真的太多喔,後來我們就分成兩批來做這個事情,分成工程團隊跟非工程團隊。

Titan這是在說你們公司擴張的很快嗎?(笑)

小朱對,我覺得我們公司確實是擴張的也滿快的,那事實上是大家都會互相參與啦。就是比如說兩位 co-founder 他們兩邊的會議都會參加,那像有些 marketing 的成員他們也會參加工程會議,只是他們在工程會議上不會講話,那主要是想要了解一下目前工程的進度大概是怎樣。

因為大家現在都已經是遠端工作了吧,我們在每天早上10點的時候會使用一套軟體叫 Tandem  開會,大家會加入某一個 meeting room 之後,然後就開始開會,來做這個 daily stand-up meeting。

完全遠距工作之前呢,其實我們公司是一個部分遠距的公司,以前是每週一的時候需要進辦公室,其他時間大家在家裡工作,或是你要來辦公室也可以。以前在辦公室的時候呢,我們會有一個大的電視,在上面會直接開 Tandem ,然後讓其他人加入他。

假如說是遠距工作的人,他還是可以遠距離連進來,那假如說是有到辦公室的人,那就會在辦公室開。那主要是因為我們的員工其實不是只有在台灣而已,所以我們就用這樣的形式,那當然在台灣的話就會盡量希望大家可以進辦公室。那但是考慮到大家都住不同地方喔,那也不是強迫,就是希望大家可以這麼做。

Titan:剛剛小朱有講到 Tandem ,這個軟體,其實我們 Star Rocket 部落格之前有介紹過這個產品,它的設計有一個地方很特別就是大家都安裝 Tandem 之後,團隊成員是可以看的到彼此現在正在使用哪些程式。

這個設計有一個好處就是,當你發現工程師他正在用 IDE 開發軟體的時候,那你就會知道說最好不要去打擾這個工程師,你可能就需要用這種非同步的溝通方式,可能去 Slack 留言,你也要預期說他不會馬上給你回應,這個東西算是我覺得 Tandem 設計上面比較特別的地方。那當然啦,我想也不是每個人都喜歡被人家知道現在自己正在使用哪個 App ,電腦上正在做什麼,所以這個可能就比較見仁見智,但我想還是可以說它是一個比較創新的設計,大家可以去我們的 Show Notes 看相關的連結。

Pair programming也是會議的一種?


Titan:剛剛有講到開會啊,小朱你們公司有分幾種會議嘛,剛剛有聽到 daily stand-up meeting ,就是每天要開的這種例行的會議,那還有哪些會議?

因為我想會議這件事情喔,在公司的運作上面滿重要的,可是身為員工可能不是那麼喜歡開各式各樣的會議,有時候會覺得它有一點佔用大家太多的時間。所以我覺得去了解一個團隊對於會議的態度或者是說決定要開哪些會議,什麼樣的狀況下要開會,是蠻值得大家去了解的。

小朱:在我們公司就主要剛剛已經有提到的兩個會議喔,第一個就是 Sprint kickoff 會議,通常是每隔週的週一,那這個這個會議主要是決定接下來兩周要做什麼,還有趁這個時間來回顧一下,我們上一個 Sprint 的開發上有沒有遇到什麼問題,或是我們的開發進度大概是怎樣。

那第二個是,剛剛講到 daily stand-up meeting ,是每天早上都會開的。還有一個我會把它歸類為會議,就是 Pair programming ,那 Pair programming 是我們是以預設的這種形式來進行開發工作的,所以一般來講 Pair programming 通常都是每天都會發生的會議,只是它持續的時間可能比較長一點。

Titan我有點意外 Pair programming 對你來說算是一個會議,就是每天都會發生的會議。因為我之前在讀資料的時候,比較不會把它跟會議聯想在一起,但其實照你這樣講,好像它也可以當成一個每天都在持續的會議。

小朱對啊。

Titan因為的確就是兩個人要一直講話溝通嘛。

小朱對,其實就跟我們現在做 Podcast 一樣喔,就是算我們正在進行的一個工作事項,那但是其實這個工作事項裡面會包含大量的溝通。所以在這樣的形式內,其實對我來講它也是一種會議,那只是它是以開發為目的的會議,然後在這個會議裡面不僅只有討論而已,它同時也在產出,所以雖然說有一點點不太一樣,但是我也會把它歸類為是會議的一種。

除了剛提到這三個以外呢,事實上也還有其他的會議。我們會議到底什麼時候安排呢?通常都是在 daily stand-up 結束之後,大家都還在線上嘛,就會說,喔我需要找誰啊,我哪些東西需要協助,需要誰幫忙。所以這個就是一個好的時間點,來跟大家約我接下來的這一天可能會跟誰,想要一起開會或是一起討論一些什麼東西。

另外一個會議呢, brown bag 中午大家可能會聚在一起,然後大家拎著各自的麥當勞的包包,它是一個褐色的袋子的一個會議喔。我們原本的時候是每週一會進一次辦公室嘛,通常我們都會叫 Uber Eats ,然後就會有人來分享各式各樣的主題。

那這種各式各樣的主題呢它不見得是開發相關的,那因為我們是做一個金融產品嘛,所以有時候是金融知識的分享,那有時候會去參考別的專案的發展過程會講一下,就是這個專案大概在做什麼的,那他們的做法上有什麼特別有趣的地方等等。

那通常這個會議呢,我們的設想是比較輕鬆的會議,它可以一邊吃飯的時候一邊講,那我們也希望就是準備的時候不需要花太多時間,應該是一個輕鬆的分享喔。但其實工程師或是我們的團隊成員有時候都很認真喔,有時候會準備一些蠻厲害的內容。大概就是我們平常會遇到的會議,就是這些,當然不包含外部會議啦,就蠻多是可能要跟投資者開會啊,或是跟其他合作夥伴開會,我就不在這邊講了。通常我們要怎麼決定要不要開會呢?當然就是我們需要協助的時候我們就會找人開會。那像我們在做這種金融產品,其實很多時候都是一個研究的成份很高的一個工作,像我們團隊成員有時候會他們今天研究了一下,找出一些方法要來實作某些東西的時候,但是我們在實作前會想要再詳細討論一下說,喔,這個實作方法,它的缺點是什麼,優點是什麼,那你跟第二個人講的時候,它會不會找出一些問題來等等的。

還沒有涉及開發層面的時候,我們通常會花很多時間在討論這件事。我可以說這樣的討論在我們公司是蠻常發生的,不過主要就是在 daily stand-up 之後呢,大家通常會在 Tandem 裡面就是會很多交互的約,之後我要約誰,我要約誰,在這邊決定之後,接下來就開會。所以我們決定開會,通常都是讓團隊成員自己決定。

Pair Programming 結對開發


Titan:好,那講完開會的部分,接下來來講今天的重點喔, Pair Programming 結對開發。那現在大家對於 Perpetual Protocol 這家公司工作的內容啊,還有團隊的組成,跟他們開會日常的運作方式都有一些概念了。

剛剛小朱有說 Pair Programming 對他們來說也算是一種會議,在這個部分呢,我會請小朱分兩個部分來談結對開發這件事情,第一個就是 Pair Programming 它的理論,它怎麼做的,它的規矩是怎麼樣,它們的設計是怎麼樣的。

第二個就是 Perpetual Protocol 這家公司,在他們實際上在執行結對開發的時候,實務上的做法。我想這個部分就跟小朱在跟大家講說他們公司是操作相類似 Scrum 喔,但其實不完全一樣的這個部分是很像的,是有他的原因在背後。

首先我想先問小朱說你們這樣子做 Pair Programming 大概多久了,這是不是你第一次實際參與 Pair Programming 的?

小朱我大概工作10年或是10多年,那這是我第一個公司用 Pair Programming ,所以對我來講其實也是蠻陌生的。我們公司原本的團隊在很小的時候是沒有採用 Pair Programming 的,但是等我們成長到期時還是很小,就是4個人5個人的時候就開始用 Pair Programming 的方法來做所有的事情,那它也作為我們預設開發的工作方法。

先跟大家稍微解釋一下 Pair Programming 大概是怎樣的一種工作型態喔, Pair Programming  意思就是說我們兩個人一起開發,所以是兩個人一組的結對開發的模式喔。裡面主要有兩個角色,第一個是 navigator 就是導航者,那這個人他通常是比較擔任導引的一個工作,那其實就像是我們開車的時候,坐在副駕駛座的人通常都會講一下接下來可能會怎麼開。

當然這個時候現在可能都被 Google 或是導航軟體所取代了,但是基本上它是一個負責講解或是來導引討論的一個角色。那另外一個就跟開車一樣他是一個 driver ,也就是一個司機的角色,那他是實際擔任撰寫程式的。Navigator 跟 driver 之間呢,跟開車有一個不一樣喔,就是這個角色是會互換的。就是我們不是說一定都一直在開車,或是我們一定都當 navigator 。基本上呢,原則就是會由一個人來寫程式,然後一個人負責引導討論這樣。

Titan雖然說剛剛小朱用開車來比喻喔,就是副駕駛跟駕駛喔,不太會常常換來換去,但是在做 Pair Programming 的時候兩個人的角色會互換,但其實不變的就是方向盤還是只有一個,他們兩個人其實是共用一部電腦,甚至共用一個鍵盤。那當然透過一些技術,你可以不用用同一個鍵盤,但是基本上請大家想像,兩個人共同操作一台電腦。

小朱:欸,對。

Pair Programming的優點


小朱:這樣的開發上當有它的優點跟缺點,對我們團隊來講,第一個優點就是說它這個知識是可以更快速的散播的。

你想想看,通常你在兩個人一起開發的時候,基本上都會有一個人對這個程式或是對整個架構是比較熟悉的,那另外一個人可能是相對起來比較不熟悉的,那當然有可能兩個人都很資深。

那當我們是兩個人就是知識的量比較不平均的時候呢,在這個過程裡面通常會有一個人在講解,那假如說他知道另外一個人可能對這一部分比較不熟悉,他就會多花點時間講解,這個地方大概是怎樣,它運作原理是什麼,或是它當初為什麼要這麼設計等等,所以我覺得第一個好處是比較容易讓這兩個人的知識量比較快的達到相對平衡的狀態。

這跟第二也有關係,在這個狀況下新加入的成員他是比較容易進入狀況的。比如說你剛加入我們公司,那說實在,我們公司的產品確實是一個滿複雜的產品喔。區塊鏈本身就是日新月異,很多時候今天的東西明天就不見得是這樣了,所以新加入的成員一般來講都要花比較多的時間上手。但是在結對開發的狀況下,因為是兩個人一起開發,所以通常我們針對新進的成員的時候,就會花較多時間跟他做 Pair Programming ,就跟剛剛一樣,你知識可以很快的去散佈給另外一個人。

那我覺得另外一個也蠻有用的事情就是,一般來講我們在寫程式的時候呢,通常都是一個人寫,然後你寫完之後真的要上線或是真的要把這個功能完成的時候,會由另外一個人來做代碼審查,也就是 code review 。一般來講這個 code review 通常是會看這個程式的邏輯,除了是不是正確的以外,也會看一下說這個東西是不是符合我們的寫作慣例,那有時候甚至會覺得說這東西其實跟我想像的不一樣,它應該有一個更好的做法等等。那這個時候就會透過 code review 的方法來確保這個程式有第二個人看過,而且有經過討論這些內容是這兩個都可以接受的。

那 Pair Programming 上我們基本上會比較少做 code review ,除了必要以外。當然有時候真的很謹慎的時候我們還是會做。那為什麼不需要做呢?你可以想像喔,在這個結對編程的時候,或者是結對開發的時候,通常是一個人在寫程式的時候另外一個人在導引問題。當他發現這個程式有問題的時候,他在第一時間內就會問他說「欸,這邊你為什麼想要這麼寫?」然後寫的人可能就會開始講說,因為為什麼我要這麼寫,在寫每一步的時候都會在這個寫作的過程裡面一一的被討論。這個 Pair Programming review 的程度呢,就是在你剛開始寫,到你最後面的時候都有人已經完整的討論過這個程式了。

所以它跟 code review 更好的地方就是說他如果覺得這個 code 有些地方討論或是方向不對的時候,他可以在很早的時間內就可以開始進行討論,那甚至可以在進行修改後取得共識,所以比 code review 的話它的效果要更好。那我們在這個狀況下通常也比較不做 code review ,因為它是更深入的去 review 這個 code 。

另外一個好處呢,就是其實 code review 也可以達成這個效果,就是一段程式通常會有兩個人以上比較熟悉,但是 code review 你畢竟是看的人,你沒有參與他這個寫作的過程,你只是看到他的成果而已。那在 Pair Programming 上,第二個人他是從頭到尾都參與他,所以可以說一段程式裡面通常這兩個人都是會比較熟悉,甚至比 code review 的第二個人還要更熟悉一點。

這個其實又跟下一個有關,那實際上我覺得它都是環環相扣的,我們可以說人力瓶頸可以得到一個舒緩,因為這個程式不是只有一個人比較熟悉嘛。我覺得大家可以想要在我們一般工程師的開發環境裡面,通常都有一個特別強的,那這個特別強的他會 tag 非常多的工作,到最後面他幾乎會整個系統的很大一部分都是他做,那當他請假或是當他離職的時候呢,有時候對公司會造成一個致命性的打擊喔。

Titan我以為你要說很大的衝擊,怎麼會變成,致命性的打擊,對。

小朱那這個狀況一直都會發生,因為能力越大責任就越大嘛。一般來講我們會透過請他去  review source code 然後讓他的能力可以比較 skilling ,他的產出可以透過 review 的方法來讓更多人看到。

假如說公司沒有這麼規劃,或是沒有這麼做的時候,這個人他就會變得很忙很忙,那你可以想的到,不管什麼部分都是需要他參與的話,那整個來講它就會變成一個瓶頸。雖然說他是公司最強的人,其實這樣的狀況也很不好,就是不論是對他的壓力來講也不好,那對公司其實也不好。

在結對開發的狀況下,這個東西就可以舒緩一些喔,因為這段程式一定都有兩個人閱讀過。就算這個人他這個時候沒有空的話,另外一個人因為他是在參與初期就跟他參與這件事情,所以他也有一定的熟悉程度可以來改這段東西。

那最後一點的好處呢,就要回到我們剛剛前面有講的,我們在三個模組的 front-end contract 跟  back-end 之間我們的工作角色是會互相的轉移的喔。 Pair Programming 讓這件事情會更簡單一些,可以想像假如我是一個前端工程師,我現在要去開發後端工程師的東西,他其實會有一個距離需要補上。但是假如說你在 Pair Programming 的時候,基本上會有一個 navigator 跟一個  driver ,所以你的 navigator 在這個時候就可以當作一個導引的角色,他可以跟他說這邊結構是怎樣啊,你該怎麼加入等等的。所以這樣就會讓我們在工作上的轉移會比較容易一點,那大家都可以去做一些他覺得這部份有意思那就可以往這個地方發展,就是這對我們來講是一個很棒的優點。

Titan:我覺得其中一個蠻有趣的就是可以讓同一個工作有不只一個人,基本上就是兩個人以上都熟悉這個工作。

那我想已經工作過一段時間的人,你可能會有這個經驗就是公司有一些同事他離職,這個空窗期或者是工作交接的時候會遇到很多狀況。因為好像有些工作只有一個人知道,實際上是怎麼進行,那當他離職或是請假的時候就會對你們團隊的運作造成一些困擾。那如果 Pair Programming 它的設計的話,好處就是一份工作大概它都會有兩個人參與過,造成的影響可能不會那麼大。然後再來就是剛剛小朱有講到人力的瓶頸,高手什麼事都要做,變成什麼事都卡在高手那邊,那這件事情可以因此得到一些舒緩。

Pair Programming的缺點


小朱:好,那說到缺點部分其實有一些喔。我們開始 Pair Programming 之後,第一個會遇到就是我們發現開發的速度變比較慢。

大家可以想像,就是你們兩個人寫一個程式,你剛要寫第一行 code 的時候,他就會跟你說,欸你這個地方可能要怎麼寫,那時候你們就會開始進行討論。那所以說,這樣的過程當然在開發上會比較慢,但是你反過來想,就是它其實更早的時候就取得共識,而且大家已經經過討論了。但是這個缺點絕對是你剛開始做的時候你馬上就會發現的,但是你說拉長時間來看,它不見得是一件壞事。

第二個是我自己也是剛開始做之後馬上感覺到的喔,在兩個人一起開發的時候你會比較累,一般在開發的時候你可會回去倒個水啊,想一下啊,上網找一些資料或是什麼之類的,那你有自己的開發步調。那在兩個人開發的時候, navigator 要負責導引討論,那另外一個人要負責寫的時候,通常也會加入討論。

所以一般來講在這個時間我通常會覺得還蠻累的,它會比一個人開發要再累很多。你可以想像你在專心的時候某件事情,然後專心的做25分鐘,而且這之間除了你,不只有在產出以外,你還有在討論,那這樣其實是一個強度滿高的工作喔。

其實我配合3個小時之後就覺得非常的累喔,那通常我跟團隊之間我會盡量配合不要超過3個小時。可能3個小時結束之後,我們就會去各自做一些事情,像我自己會做一些管理的工作啊,或者是我會去更新一些文件。這可能沒有那麼適合 Pair Programming 或是根本就不適合的事情,我們就之後再去做,但是會盡量的把時間就是控制在一個不要太久。

Titan欸,那我們錄Podcast算是強度很強工作齁,因為要連續兩個小時。

小朱沒有錯喔,確實是這樣。其實跟 Pair Programming 有異曲同工之妙。

Titan之前我們可能在別的節目有提到過喔,一般工程師他們可能大家會想像說啊我們每天工作就8小時。但是對工程師來說其實不太可能是1天8小時都在寫程式的喔,通常可能工程師覺得說我一天上班時間,裡面有4個小時我在寫程式就已經算是很猛了。因為其實是比四個小時更短的,所以剛剛小朱講的 Pair Programming 三個小時就很累,我覺得這應該是蠻合理的。

大家可以用開車的比喻來想想看,剛剛小朱有說嘛,你在寫第一行的時候 navigator 就會有話想要跟你討論,那通常開車的人都蠻討厭副駕駛座的人在那邊指手畫腳的,所以如果用這個概念來理解 Pair Programming 它會遇到的問題,應該比較容易想像。

那再來就是如果你要密集的交流溝通的時候,對工程師來說也是一種負擔算比較大吧,因為其實對一般人來說說在工作上如果要持續的跟另外一個人一起搭配,然後要配合彼此的步調,所以這個應該是比較辛苦。

小朱對啊,確實是這樣。因為通常不能那麼長時間的工作嘛,所以我會搭配一些方法,然後來做一個短暫的休息之後,然後再開始工作等等。我們晚點可以再討論這個事情。

Titan進入實務上的討論之前,我想再問小朱一個問題,就是 Pair Programming 是  perpetual protocol 既定的工作方式嘛,而且你剛剛有說你們公司現在在擴張嘛,你們在 hire  在僱用新的工程師的面試過程當中會針對 Pair Programming 做特別的設計嗎?怎麼知道說他適不適合 Pair Programming ?

小朱對,其實這個是我們考量的重點,因為我覺得對我們的這個團隊的溝通上的文化來講,其實我們會需要就是工程師是比較需要溝通的。那所以說在我們 hiring 上面的設計也是這個樣子,我們在 hiring 的過程其實是有一關會需要做一個 Pair Programming ,會讓來面試的人會有他一份比較熟悉的程式,然後這個時候我們比如說會有一個題目衍生它的一個功能,面試的人跟被面試的人會一起做一個短時間的 Pair Programming 。

目的不是要讓提到這個需求被完成,或是我們要新增一個功能被完成,而是在這個短時間內來看一下你要怎麼在這樣的環境裡面跟其他人去討論事情,或是你要怎麼引領這個開發的過程等等。那對我們來說,當然觀察這個人技術好或不好,那是一個重點,可是更重要的是在工作的當下會怎麼跟我們討論。因為 Pair Programming 對我們來說很重要,所以我們在 hiring 的時候就會做這樣的事情,了解這個想要加入的成員是不是適合我們的這種工作環境。


Pair Programming實務 : 善用番茄鐘


Titan:好,那接下來我們請小朱來跟大家解釋一下他們實務上是什麼操作 Pair Programming  結對開發的,那我想大家可以理解喔,事實上大部分的工作方法在理論跟實務上都會有一些差別。

小朱:恩,沒有錯,那我們剛剛講到是說我們每兩周會有一個 Sprint 嘛,所以我們在 Sprint 的開頭時候通常都會先大致上討論一下就是說,喔我接下來可能會跟誰Pair 。有時候你工作是奇數的人嘛,那有時候就會有一個人他可能不是 Pair ,那這個時候我們就會變成原本的方法就是,他寫完之後然後發一個 code review 的要求,然後請另外一個人 review 。

每天 daily standup meeting 的時候,有時候我們有一個工作是還沒有排定誰要做的時候通常也會大家問一下,就是說我們接下來要做這個工作,那有沒有誰有興趣的,之前沒有做過這個領域想要一起來做的。

Titan我想請問一下喔,長期下來會不會有一種狀況就是有的工程師比較喜歡跟特定的工程師一起配對,就變得比較沒有那麼喜歡用任務導向來分配這個工作,會有這個問題嗎?

小朱其實這個問題是算是蠻自然就會發生的,那我也不太確定它到底是不是一個問題喔。但是我們其實也會做一個平衡就是像我們有些工作是希望大家都有做過,那通常就是會有一個主要執行的,就是他幾乎每次都是大概執行這個工作,但他每次都會找不同的人來配合,就是他希望這這工作大家都要會,那接下來呢,其他的他們就可以在兩兩進行配合等等的。

所以說這兩件事情都是會發生的,那我們通常是不會特意的去要求大家 rotate,看這個工作性質是怎樣的,然後再來決定。可是我們在安排有時候通常會比較希望是比較熟悉的人搭配一個相對不熟悉的人這樣來做,但是這些也都是一個大致上的準則,但是我們通常不會太干涉要怎麼做。

Titan我想應該可以理解啦,應該不會想要讓兩個都很菜,或是兩個對這東西都不熟的人讓他們一起搭配對不對?如果可以的話。

小朱對,通常不會。因為接下來要工作的模組比較不熟悉的話,對於他原本一些既定的規則沒有瞭解的時候寫下去可能就會有一些不符合需求的產出,或是不是預期內的產出,那之後可能就要花更多時間來修補這些東西喔。所以一般來講當然都是希望在Pair 的時候至少有一個人是比較熟悉的,那當然這個東西在對一個全新的工作就不是這樣了,通常就是還是會兩個不熟悉的配合。

但是這邊我也想要分享一下我自己的做法,因為 Pair Programming 是一個很高強度的一個工作方法。那我自己會搭配一些做法,然後讓這個事情是比較好的去執行,我自己會用一個叫番茄鐘的方法,跟 Pair Programming 是沒有關係的,你一個人也可以做。那通常會把時間切成一個等比例的長度,比如說25分鐘,番茄鐘其實很簡單就是你專心做25分鐘的工作之後,然後休息5分鐘,然後這樣連續的一直做下去。過程是希望你專注,就是你25分鐘內都不要做其他事情,只專注在你正要做的事情,然後接下來再五分鐘休息。

對我來講番茄鐘的好處是讓我自己可以提醒自己要休息的時間,因為我在使用番茄鐘之前,我有時候可能會一次工作兩個小時,三個小時。工作到後來,你可能花很多時間,但是你接下來可能會有種身心俱疲的感覺,那另外一個效果就是其實你中間也不會完全在工作,你可能會去上上網什麼的,那工作時間長了之後,你就會慢慢的集中力就會比較分散。

那事實上人呢,他要保持高度的專心其實是滿困難的一件事情。番茄鐘它其實是一個方法就是讓你可以保持專心,但是不要太久時間的時間,然後休息一下讓你可以回復你可以專心工作,然後接下來在開始工作這樣。通常我會把它用在 Pair Programming ,這是是我自己啦,那當然每個人的工作方法都不一樣。

通常我會跟另外一個人講說OK,我們來Pair 25分鐘,然後休息5分鐘,連續做幾次這樣。通常我的目標會設定在我們一天就只做6個,因為6個其實就是3個小時嘛,其實3個小時的 Pair Programming 就是非常非常累的,結束之後呢,我們可能就會各自去做些其他的事情。

也不是說所有事情都適合 Pair Programming ,假如說你要做一個研究項目,你要做一個  research ,你需要看很多書什麼的,你兩個人一起看這個書,幫助可能沒有很大,但是你們兩個討論的幫助會比較大。所以在這種 research 的工作,我們通常就不會用 Pair Programming 的方法,就會就是兩個人分開看,過一段時間之後再回來再一起討論一下,就我們各自看了什麼,那這種方式比較有效率。另外一個例子是有時候好有時候壞就是當你 bug 找不出來是什麼原因的時候,通常也會雙方去分開去看一下資料,看有沒有可能是怎樣的問題。那這個通常也是有可能會兩個人一起做啦,像是我昨天剛好遇到一個例子,就是我們要設定一個東西看起來很簡單的,但是一直都無法設定好,然後我們就兩個人一起做,最終還是沒有找出原因來。但是這個過程就是你是怎麼思考的這件事情,當然有時候也是值得分享就是可能會考慮當下的情況倒底是怎樣。所以說 Pair Programming 雖然說是我們預設的方法,但是我們也不會所有的事情都使用。

遠距工作怎麼 Pair Programming?


Titan:那現在你們團隊都是遠距了嘛,因為在家工作的關係,但遠距的 Pair Programming 要怎麼做,你們會用哪些工具來輔助啊?

小朱:因為其實我們原本也只有一週進一次辦公室嘛,所以我們原本就是用遠距的方法,除了周一以外。

主要有兩個工具喔,第一個就是我們剛剛已經提到,就是 Tandem , Tandem 它雖然說是一個開會的工具,但它其實有一個很方便的功能,當你在分享螢幕的時候,就是看螢幕的人都可以看到每個人的遊標在哪裡,所以說你可以順著他的視線去看他現在正在看什麼,或是跟他溝通東西。在沒有一些其他工作的狀況下,我們就會用 Tandem 來做,那當然它不是專門的 Pair Programming 的工具,但是也還算是適合我們,也經常會這樣做。

第二個工具呢,那就是 Visual Studio Code 它的一個延伸套件,叫做 Live Share 是一個專門在 Pair Programming 用的時機。

那我先跟大家講解一下我們一般開發的時候我們會用到哪一些工具,第一個就是文字編輯器。在寫程式的時候你會需要用到這個編輯器,它會把語法顯示不一樣的顏色,讓我們比較好知道我們正在開發什麼東西,會比較清楚的看到哪些東西是怎麼樣運作的。

那第二個就是除錯,它可以讓程式運行的時候一行一行的執行,或者是你執行到某一行的時候它可以停下來。假如說我們在開發一個東西的時候,出了問題的時候呢,我就會希望它停留在某一個時間點之後,我們來看這個 context 底下的所有資訊,來找出潛在的問題到底在哪裡。

比如說在這個工廠的流水線,你可能會製造三明治啊,或是製造罐頭的時候,它通常都是一個流水線嘛,前面做什麼事情,然後後面洗東西,最後封裝等等的,這個就是一個工廠的流程。

那我們在設計這個工廠的流程的時候,假如說有些環節出錯要怎麼辦,你可以想想看它有一個魔法喔,就是它可以說 stop !整個工廠都停下來了,那你可以走到每一個地方去看看這個流程它正在做什麼事情,有什麼事情在這一個時間凍結的當下它的狀況上有沒有出錯,或是它有沒有符合預期。類似工廠的流水線,然後還有時間暫停的功能,就是除錯,可以讓開發者在這個時候抓出設計錯誤的地方。

那還有一些比較常用的就是說我們會需要看到我們正在修改的網站,顯示的畫面是什麼,或是有一些終端機就是那個黑色,它通常都是拿來看一些開發資料的。那我在 Pair Programming  用 Live Share ,它可以讓這些東西全部都變成是共享的。

那在在編輯器方面呢,我們可以看到每一個遊標停在哪裡,它選了哪些東西,而且呢,在這個時候另外一個人假如說臨時想要打一些字,或是他想要說這個東西要怎麼寫的時候呢,他就可以直接的輸入,另外一個人也可以看到,這是變成了一個互動式的寫作。

那第二個就是除錯,那剛剛講的那個時間凍結的功能,它也很神奇,它可以讓兩個同時參與這個的過程。就是當你把程式停下來想要知道那個當下的所有的事情的時候,這個狀態也是共享,兩個人都可以在這個停止的當下去看到各式各樣的資訊,進而來討論就是說這東西到底有什麼不一樣,兩個人可以看到網站的畫面。就是說今天在我的電腦上開發,所以我的程式會在我的電腦上運作,但是另外一個人他可以連到我的電腦上,看到我正在開發的那個網站的畫面,然後一樣的這個也是可以拿來做為開發的這個需求。

所以這些都很重要,然後還有剛剛就講到終端機也是一樣,在 Pair Programming 的時候,另外一個也可以直接使用這個人的終端機來幫他做一些查詢啊,或是看一下這個結構裡面哪邊有問題等等,那這些東西 Live Share 這個軟體都可以做得到,那真的非常的好用。

它有一個缺點喔,因為這個 Live Share 它是 Visual Studio Code 裡面的一個延伸套件,在這個 Visual Studio Code 這個編集器裡面,我剛剛講到的這些東西可以看到。但是假如說你上網查資料啊,或者是你開了什麼軟體輔助來開發的話,是看不到的,通常這個時候我們就用  Tandem 做輔助。

我們其實 Tandem 有時候還是會開著螢幕的 share ,就算我們使用 Live Share 的時候。那有時候就是拿來看一下,喔這個人他說現在正在查資料的時候,他就不在 Visual Studio Code 裡面了,那這個時候就會由 Tandem 來輔助,來看他正在做什麼。

Titan所以說其實在 Pair Programming 實務上運作的時候,滿重要的一點應該是兩個人要可以看的到對方現在正在看到哪些東西,而不是只有 IDE 編輯器的這個畫面而已,對不對?

小朱對。

Titan就是包含他現在在看哪些參考資料,因為這樣子的話兩個人才等於是在一個同樣的脈絡底下一起做事,才可以真的比較模擬出兩個人實際坐在一台電腦前面的那個工作狀況。那可是這樣會有一個疑問喔,對我來說。

之前我在採訪 Tempo 的時候,他說他其實很討厭那種文字編集器的開發環境。他喜歡用  IntelliJ 這家公司喔,Kotlin這個程式語言的開發公司他們出的 JetBrains 的全家桶喔,他喜歡這種 IDE ,他覺得比較好用喔。

可是你們比較常用的是 Visual Studio Code ,那這個時候如果 Tempo 要加進來做 Pair Programming ,要怎麼做?

小朱這個其實就是我們經常遇到的問題,因為大家當然不是習慣的只有用一種文字編輯器或者是 IDE 嘛。正不巧的就是這個 JetBrains 正好沒有提供 Pair Programming 的工具,我們研究這個 Pair Programming 當然已經是很久以前啦。最新的進度我沒有追,搞不好現在已經有了,但是其實會遇到這種問題就是你使用你最慣用的那個軟體,它並沒有 Pair Programming  的功能,這個時候呢,通常我們就會退回到使用 Tandem 來做。

因為我剛剛講其實 Tandem 也可以做一樣的事情,雖然說它缺乏一些關鍵的功能,但是它這樣的視訊軟體,再加上你可以看到游標,基本上其實還是可以達成一個樣的功能。其實有一個軟體叫 POP ,我沒有深入的研究過,但是這個軟體它其實也是有相同的功能,或許也可以當作一個替代方案。Titan:剛剛小朱講的這個 POP ,是最近才改名叫 P-O-P 的,它以前叫 Screen ,我們在它還是叫  Screen 的時期喔,我們 Star Rocket Blog 有一篇文章在介紹這個產品,有興趣的聽眾,或是說你們其實有在做遠距工作的開發者,你們有時候需要共享螢幕做程式上面的討論的時候,可以參考一下這個產品那我們會把連結放在 Show Notes 。

Google 裡的大神級工程師也使用 Pair Programming

Titan因為我不是工程師嘛,我沒有實務經驗可以分享喔,不過我之前有讀過一篇文章我覺得蠻不錯的,我推薦大家去讀一下。很特別喔,紐約客雜誌,但是他們寫的是跟程式開發有關,上面有一篇文章 The Friendship That Made Google Huge ,故事的主角他其實是在講 Jeff Dean 跟 Sanjay Ghemawat ,這兩個人在 Google 共事20年來的工作模式,那其中就有講到  Pair Programming ,所以我想可以在這個地方跟大家講一下,推薦大家去看。

Jeff Dean 我想如果你是工程師,而且你是軟體工程師的話,那我想不需要解釋太多喔,他可以說是現在人工智慧領域非常重要的專家。他在 Google 已經算是非常資深,他從1999年就加入 Google , Google 是1998年成立的,所以他是非常早期就加入 Google 了。那他是現在在 Google 裡面算是 Senior 的 Google Fellow ,大概是職等喔,傳說中的 level 11,我不知道現在變怎麼樣,因為這篇文章是2018年的。

故事的開頭我覺得非常的吸引人喔,他在講 Google 2000年時遇到的一個大問題,當時  Google 的瀏覽器的運作方式是他們有一個網路爬蟲會一直去掃描索引這個網際網路,整理這些資料讓大家可以拿來搜尋。所謂的搜尋引擎並不是在搜尋整個網路,而是用 Google 已經幫大家做好的索引。當時發生一個狀況就是他們的網路爬蟲故障,使用者搜尋到的資料都是好幾個月前索引起來的。

那當時呢,其實 Google 的創辦人 Larry Page 跟 Sergey Brin 正在跟 Yahoo 協商,要把他們的搜尋技術授權 Yahoo 使用,賺取授權費。所以當時這個爬蟲故障了,對大家來說應該是個很嚴重的問題,因為可能會讓這個生意做不成。 Google 當時還剛成立兩年不到,還在燒錢,所以會少一筆收入,那對公司運作來說是蠻危險的。

那故事的開頭就在講說,後來就是 Jeff Dean 跟 Sanjay 兩個人合作 debug 非常久一直找不出程式上到底哪裡有問題,那然後來發現居然是在機械碼的地方,也就是我們程式寫完之後要  compile 機械語言,讓電腦可以看得懂,也就是所謂的0跟1的這個層級上面的問題。在原本應該要是0的地方變成1,原本要是1的地方變成0,那他們發現就是有一個固定的模式導致他們的爬蟲因此而故障。那原因是什麼喔,其實我覺得這個很特別,在宇宙裡面如果有一個超新星爆炸喔,就是一個質量很大的星球爆炸之後會散發出一些高能的粒子,那可能大家有聽過宇宙射線這種說法。

這個理論就在於說,當這個射線啊進來我們地球之後打到你的硬碟,打到你的電腦,可能會導致你的程式在這個時候出現問題,比較高級的、高階的或者說比較嚴謹的單位,他們使用的電腦都有針對這些事情做一些防護。

比如說大家可以想像 NASA ,或者是像 NSA 這種,他們的電腦很重要,可是當時的 Google  啊,是2000年的 Google , Google 一開始, Larry Page 跟 Sergey Brin 他們是去垃圾場撿大家不要用的硬碟回來組裝,做成他們儲存資料的設備。

那後來開始有資金之後,他們也是買消費級的硬體來做組裝, Google 的伺服器其實一開始就是在一個可靠度比較差的硬體上面運作的,所以導致會有這個狀況,硬體開始故障,而且你們的規模開始變大的時候,故障發生頻率就會越來越高,然後最後會導致整個系統沒有辦法運作,故事開頭就在講這個。

那這篇文章在中間的時候有跟大家介紹 Jeff Dean 跟 Sanjay ,他們兩個是怎麼工作,怎麼做  Pair Programming 的。記者有在旁邊觀察他們一天的工作,那其實早上一開始有他們兩個就真的是共用一台電腦,他們會用一個較大的螢幕,會有四個視窗喔,第一個就可能是一個網路瀏覽器,然後還有一個 terminal ,就是剛剛小朱講的終端機的畫面。那另外呢,就是他們用來開發的編輯器,他們是用 Emacs ,上面可能會把他們今天要做的事項也寫在編輯器裡面,然後還有這個程式。

他們的做法通常就是 Sanjay 會當 driver ,寫程式的那個人, Jeff Dean 就會在旁邊跟他討論說欸那我們今天要做什麼,那兩個人會真的從一開始就在討論。比如說,欸,那我們現在要幹嘛,我們今天要做什麼事情,文章裡面有描述到 Jeff Dean 跟 Sanjay 他們的風格,像 Jeff Dean  他比較擅長丟出新的概念,然後快速的做出原型,那 Sanjay 他比較嚴謹,他會把程式寫得可以長期的穩固的運作。裡面有講到說兩個人的個性其實不太一樣, Jeff Dean 比較外向一點,那 Sanjay 是很內向的。

可是在寫程式上面就相反,前面有說嘛, Jeff Dean 寫程式很快啊,很容易讓讀者眼花撩亂,所以他的程式其實是比較難理解的,可是 Sanjay 就不一樣,這篇文章寫得很有趣,他說是比較 social 的,所以就是比較好閱讀的。工程師很常需要閱讀別人的程式碼,所以這時候就會遇到一個狀況就是,啊你寫的程式碼別人好不好讀懂,總之我覺得大家可以去閱讀一下這篇文章。

兩個人一起工作的歷史或者是兩個人一起工作的模式喔,其實在很多領域都有被大家拿出來探討或者是研究過,有很多實際的案例,比如說我們知道披頭四裡面的 John Lennon 跟 Paul McCartney 他們兩個人一起創作,或者是在畫家、藝術領域裡面,像印象派可能莫內還有雷諾瓦還有像畢卡索跟 Georges Braque 有當初在一起研究立體派這個畫派的時候也是兩個人一起合作,那他們當時有一個特別做法就是他們會在畫布的背後簽名,如果這張畫要算有完成就是必須要兩個人都簽名這樣才可以。

所以我覺得大家也可以去研究一下說這種搭配一起工作中間的效果或者是它的過程,市面上有一本書算是比較近期的吧,中文的書名叫做《橡皮擦計畫,兩位天才心理學家一段改變世界的情誼》講就是快思慢想這本書,他的作者康納曼教授,他跟他長期的研究夥伴。那我想這件事情在學術界是滿常發生的,就是大家兩個學者一起合作研究一個議題,那通常可以得到比較好的效果。那有一些統計數據啊,比如說像過去35年來大概有一半的諾貝爾生理學或醫學獎的主題都是由這種兩個人一起研究的關係所獲得諾貝爾獎的,所以這個在學術上應該也算是蠻常見的。

用 Obsidian 做子彈筆記


Titan:節目最後啊,我們請小朱來跟大家分享一下他自己個人的工作習慣,因為我們的聽眾,根據我們的觀察,大家對這種議題是非常感興趣的喔,生產力工具還有工作的方法喔。

小朱:那其實第一個是我剛剛有提過的,就是番茄鐘的部分。我使用番茄鐘的話有一個週期就是原本就是會不使用番茄鐘,但是我覺得自己注意力慢慢的下降之後,我就會開始再試起番茄鐘來用,然後就是這樣一直交替著用,這是對我來講是一個滿好的一個方法。因為25分鐘、5分鐘、25分鐘、5分鐘,就樣的工作節奏,我覺得如果習慣之後,它是一個蠻好來完成工作的方法啦。

第二個就是子彈筆記,我是用 Obsdian 做的,其實我的子彈筆記,跟比較常在提到的子彈筆記有點不太一樣是…幾乎所有的子彈筆記都是用,比如說紙本啊,或是用 iPad 手寫的方法來做的,但是我不是這麼做的。

那這邊其實可以參考吧 Bob 他的文章,他跟我一樣是比較習慣用打字的方法來記錄事情,就會跟一般的不太一樣,但是我們使用這樣做之後,我覺得感覺其實也是蠻好的。那子彈筆記對我來講它是一個筆記,然後跟著就是我的 task 是合一的工作方法,所以我只用筆記來做我的所有筆記,也來做我的工作管理。

通常就是我會每天都有一頁,那這一頁裡面通常都會有我今天要做的事情,今天做的筆記都會把它記在這邊。那假如說我完成了一個工作就把它劃掉或是打一個勾。那我一天結束之後呢,我就來會來檢視這些筆記,一來是看一下我今天完成了什麼工作,那哪些工作我原本預計要完成但是還沒有完成。那我會想想這工作到底是足夠重要呢?我明天要繼續做。還是說OK我這個月不想做,我這周不想做,想要把它排在後面或是完全不重要就把它劃掉,然後把它調到明天去或是想想看它的重要程度如何,通常那時間也會順便檢視一下今天做了什麼事情,然後把它記下來。

那假如說我這一天有做一些筆記,那還沒有消化的,我在這邊也會看一下,看要不要再做額外的筆記,然後把它轉化成適合自己的東西,最近在看就是 ZK 筆記法。

TitanZettlekasten。

小朱那個我現在剛開始在看,但是我試著在一個筆記裡面同時用兩種做法。

Titan我想小朱講的應該是我們 107 集的時候,我跟財報狗的林威宇有談到這本書,那我們會把連結放在 Show Notes 大家可以去找來看看喔。(《星箭廣播》107 集––希望我們的第二大腦都不會太遲緩:聊聊學習生產力工具(ft. 財報狗林威宇

小朱覺得那本書很有趣,就是它也不是全然講筆記的事情,它講了很多不太有關的事情,但是我覺得非常的有趣所以推薦大家可以去找來看一下。

OK,那除了一天以外我還有一個月誌,就是一個月會有另外一頁,我說每天的結束之後會看一下我今天的做的事情嘛。那這個時候我通常會打開我的月誌,然後把我今天做完,我覺得值得紀錄的事情把它寫在月誌裡面。

我每天就是我要把我的工作搬到明天去的時候,我通常也會打開月誌來看一下,就是說我這個月有什麼事情要完成的但是我還沒有排到我接下來要做的事情裡面,那我今天是不是想要把這個工作給拿進來做。

在每一個月的時候,我一樣會做一個轉移,我這個月有哪些事項我原本說要完成的還沒有完成,或是我完成了哪些事情,接下來會打開下一個月的月誌,然後來思考一下我下一個月其實有可能已經排定要做什麼事情,那我這個月沒有完成的呢,到底是它不重要呢,還是它其實很重要只是我還沒有完成的,我需要把它搬到下個月去,它其實跟日誌是一樣的,只是它的轉移就是會在每個月的時候做一次。

那這樣推斷下來,其實就會有另外一個,就是半年誌的部分,那它其實跟日誌或是月誌一樣,就是因為我日誌會每天去看一下什麼東西要帶到下一天去,月誌會看這個月有什麼事情完成了,有沒有什麼東西要在下個月完成。那半年也是一樣就是它裡面會包含一個每一個月我預計要做什麼事情,那通常我這是每個月在做轉移的時候,也會打開這個半年誌來看看,我最多做到的就是半年誌,我沒有再更高的一個單位。

就是假如說有使用過子彈筆記的可能會不是很同意我的看法。對我來講,雖然說它不是一個手寫筆記,但是這樣有階層式的記錄我正在做什麼事情,哪些事情重要,哪些事情要帶過去,我可以考慮相對起來比較遠一點的計畫,然後也可以重新來 review 我做的事情。

那我在做子彈筆記以前呢,我是做 Getting Things Done ,我自己在做 Getting Things Done 的時候我覺得我比較沒有完成的是一些比較長期的計畫,那或許可能是我做的方法不對,但 Getting Things Done 讓我覺得我可以解決我當下的問題,我的事情可以一一的完成,相對於子彈筆記來講的話,我覺得子彈筆記提供給我就是可以思考比較長期的計畫。

就是做這些事情喔他們都有一個正統的做法,對我來講我比較不是那種說我會照著正統作法,它一定有一個一定要怎麼做,通常會取一些我覺得有用的部分來做。經過這一些各式各樣的處理工作的方法,那我現在覺得子彈筆記對我來講是比較適合,而且是一個不是很正統的子彈筆記,對我的幫助是還滿大的。

Titan你用 Obsidian 寫子彈筆記,大概用多久了?大概一天花多少時間做這些紀錄更整理?

小朱我現在做子彈筆記已經做了三個月,然後現在是是第四個月,所以其實也不是算非常長的時間。我用 Obsidian 的時間就是我做子彈筆記的時間,但是我剛開始是用 Notability 來做子彈筆記,後來覺得就它可能比較沒有那麼適合我,所以才改用 Obsidian 。那每天整理的部分,我大概是花15分鐘,但是我之前會花很長的時間做這個事情。後來我覺得這個真的是個死亡螺旋,這樣做其實不太好,所以後來會用更簡單的方法來做,我現在就是每天花15分鐘做這件事情,那我覺得這是滿合理的時間,現在還不錯。

Titan那接下來因為時間的關係喔,我想請小朱很快的跟大家講一下說他們公司在開發產品的時候有用哪些服務。大部分我想我們會列在 Show Notes 上面,大家有去看,我可能就請他針對其中一兩個比較特別的,比如說標準就是「啊,我也沒看過的。」請他來跟大家分享一下。

小朱我想要分享兩個喔,那第一個是比較通用的,它叫…應該是唸 Lokalise ,它是一個翻譯的寫作平台,因為你在開發程式的時候通常都會做一個翻譯的工作,那通常我們會用一個框架來把我們要翻譯的這些字串放在一個地方之後,然後可能會傳給比如說幫我們翻譯的人來做這件事情,這樣做的事情其實不是很好協作的喔。就是他可能會用不同的工具啊,可能會用 Google Scratch ,用什麼方法來做,但是在管理上都比較沒有那麼好管理,也比較沒那麼好的整合進入我們的開發流程。

那這個 Lokalise ,我可以把我已經翻譯好的,比如說英文檔,先上傳到這個平台去,然後我們可以在這個平台裡面去把我們的翻譯者一一的加進來,比如說法語的翻譯者,他就會負責翻譯法語的部分。

因為我們平常在開發的時候,我們會再去上傳我們更新的一個自傳,或是更新的文字,那這個時候法語那邊它就會出現說,喔新增了幾個文字,你還沒有翻,或是他翻完之後他就會標示說這個文字已經翻譯了,但是還沒有 review 等等。

甚至是說,假如說我翻譯的我原始的自傳,英文有改變的時候它會跟這個法語或者是日文的人講說這個文字已經變更過了,那你是不是要再看一下這個文字在你這個翻譯需不需要做調整,所以它基本上是一個翻譯的寫作平台。我們使用這個服務沒有多久,大概一個月而已,我們最近才做了翻譯的工作,那目前來我覺得還蠻不錯的東西。

Titan我覺得這個蠻特別的耶,它其實嚴格說起來是針對軟體設計或是多語言版本的情境做的設計嘛。比如說網頁設計有時候也要多語系,因為我們講到翻譯,大家可能想到的都是像文件啊什麼的。

小朱對對對,這樣說的話確實是,它比較不像是那種文件診斷的翻譯。比較像是我一個網站上我想要提供多元的時候,我有一個 button 是確認,英文是 confirm ,然後法文是什麼。那有時候可能想要把它改成不是改成確認,改成OK啊,或是甚麼,那這個時候其他的也會需要跟著翻譯。所以它比較像是這種網站的翻譯工作,但是比較不是那種長文本的翻譯工作,性質有一點點不太一樣。

另外一個我想要分享的是一個大家可能會比較少用到的軟體,就是跟區塊鏈相關的叫 tenderly ,那這個軟體其實除非你在寫區塊鏈,不然你不會使用這套軟體。我剛剛有提到就是說區塊鏈它其實是在一個區塊鏈上的一段邏輯,或是一段合約,這個合約基本上就是一段邏輯嘛,但是這個合約它可能依照你的輸入,它可能不見得成功的執行,但是你每次執行的時候它一定都會落到同一個錯誤。因為一定是一個什麼進去,然後它就是一定是一個什麼結果,所以它是有可能會失敗的,若是失敗的話一定是每次一樣的 input 它都一定會失敗。

其實區塊鏈沒有一個很好的工具可以提供除錯喔,那這一個工具它其實非常的厲害,就是你可以找到你錯誤的那一個,或是你成功的那一個,然後它會跟你分析這個交易,就是你執行的這個動作,執行的步驟有哪一些,可能有一百個,那你可以回放這個交易。

我可以讓它從這個交易,比如說從這個合約開頭的邏輯開始一直跑下來,它停在哪個部份,然後導致錯誤的原因到底是甚麼,都可以詳細的分析出來,所以這一個是算是非常厲害的一個除錯的工具喔。但是我比較少看到人提,當然也是因為現在區塊鏈的專案可能也沒有那麼多,但是對我們來講非常有用的一個工具,如果你不開發區塊鏈的話這個工具確實是比較少用到。

Titan那小朱最後我想請你再多講一下關於 Obsidian 喔,因為這種可以雙向連結的筆記軟體我們之前在節目裡面滿常提到的,之前都講比較多是 Roam Research ,但是通常還是會同時講到 Obsidian ,所以我也很好奇你的使用的心得是什麼。

因為之前我們上一集的來賓 Richard ,他有一天就跟我說他去報名了這種課程,在講怎麼使用 Obsidian 。那另外一個當然就是小朱反覆在節目裡面提到番茄鐘,那其實番茄鐘會搭配一個軟體來使用,我也想請他跟大家介紹一下他使用的番茄鐘的軟體。

小朱只要是最近的人在提到筆記軟體一定都會講到 Obsidian ,那我其實是在一個叫 Keep Productivity 的 YouTube 頻道裡面提到的。它裡面講到非常多生產力工具,如果對生產力工具有興趣的應該要去看一下這個 YouTube 頻道。

我是一個 Evernote 非常長期的使用者,我在我使用 Evernote 這段時間內我無數次想要離開它,但是我最終都沒有找到一個很好的解決方案。 Evernote 它就是讓我又愛又恨,我覺得它很難用但我就再怎麼也離不開它,但 Obsidian 讓我就是發現一線生機喔。

對我來講 Evernote 最重要的就是可能是我已經記錄了很多東西在上面,我用 Evernote 的時候我覺得它很糟糕,很多事情都做不到,但是我每換一套軟體的時候我才發現,啊其實我好像也沒辦法離開 Evernote。

我也不知道該怎麼說,因為你做筆記就是會有一個習慣,那你很難去取代它的。我試過 Notion 啊,我試過 OneNote ,還有試過各式各樣,像是 Bear 那些我都試過。那 Bear 我覺得非常不錯,但我最近都沒有用它是因為我需要在多平台裡面去使用。

那 Obsidian 最後解決了這個問題喔,因為我覺得它是一個如果你是工程師的話使用它會比較簡單一點,因為它裡面使用的語法叫 Markdown ,工程師其實非常收西這樣的一個語法,的二個是我覺得它的速度非常非常的快,使用上你只要使用的時候跟筆記軟體都不太一樣,比如說像 Notion ,我現在覺得 Notion 做得非常好,但它實在是太慢了。

我覺得有一個好處是它可以把所有的文件全部都保持在本地的一個資料夾底下,而且照著你原本分類的方法放。這件事情呢聽起來很簡單,但是沒有一個筆記軟體做的很好的,那 Obsidian 對我來講做的非常好,因為我可以直接把它放在 Dropbox 上或是我要用它 sync 的服務去同步我這個筆記,都可以做得非常好。所以這個就是一個契機,就是讓我最終可以停下我的 Evernote ,但是我當然還是繼續在付費,只是我現在已經比較不依賴 Evernote 了。現在開始把我所有的筆記都放在 Obsidian 上面,非常的好。

那另外一個就是番茄鐘軟體我試過非常多,其實番茄鐘你不見得需要軟體,你需要一個…….

Titan時鐘

小朱只要一個可以指定25分鐘跟10分鐘的時鐘就可以做了,所以你可以用鬧鐘,這個比較好的原因,其實也沒有什麼比較好對我來講是它夠簡單。它就是一個25分鐘、5分鐘跟15分鐘,一天的開始你其實先在裡面 key 上就是,喔,我今天要執行什麼工作,我覺得它要花費多少個番茄鐘才可以做到,那它也可以不要用,所以對我來講是一個很大的彈性。

所以我休一天的時候會規劃一下我大概要做什麼事情,會花多少的番茄鐘,然後接下來再開始工作。那我使用的一套叫做 Pomofocus 它是一個非常簡單軟體,它就是一個網頁,你只要上它的網站就可以使用,完全不需要下載,非常的方便,那以前也有用過很多套,比如說像是 Be Focused 。

Titan我電腦裡面好像有這個軟體。

小朱對,你如果有用 Setapp 的話你應該會有這個軟體在裡面,但是我是獨立買的啦,那這個軟體它也不是說不好,對我來講說它只能停在 Mac 的那個右上角,這個對我來講有點不太方便。因為有時候我也想要把它移到我的第二個螢幕去,不然的話其實我覺得它也是蠻簡易的,總之呢這個番茄鐘軟體基本上就是一個功能夠簡單,然後可以完成它要做事情對我來講就夠了,我後來使用這個 Pomofocus ,我覺得是一個對我來講蠻好的一個小軟體。

Titan好,那今天很謝謝小朱花這麼多時間來跟我們分享他們公司內部使用 Pair Programming 結對開發的這個過程跟實務上他們是怎麼做的,我覺得這個應該蠻值得各位有在業界工作的聽眾朋友來參考的。

那我們今天再次謝謝小朱來上節目,那我們今天就跟大家聊到這邊,如果對他節目裡面講到的東西有興趣的話,一定要去我們的 Show Notes 找來看看。

那我們就跟今天就跟大家聊這邊,那我們下一集見, Byebye 。

小朱: Byebye ,謝謝 Titan 。

本文為《星箭廣播》112 集——軟體工程師團隊怎麼工作?Pair Programming 結對開發實戰經驗談(ft. 資深工程師小朱)訪談逐字稿,為了方便閱讀,內容經過編修。本集節目介紹與相關連結請到此頁面閱讀。
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出
Previous

明星記者單飛中:值得科技人訂閱的六份 Substack 電子報

科技創業週報 #289:你的產品該用「無限滾動」設計嗎?

Next
Share via
Copy link
Powered by Social Snap