無瑕的程式碼番外篇：專業程式設計師的生存之道

這是一本很容易讀的書, 只要是軟體工程師, 一定能在某個章節裡面找到共鳴. 推薦序裡面講的小故事很有當頭棒喝的感覺,  專案經理一向對於工程師說出的 NO 不放在眼裡, 覺得只要再耍賴, 施壓一下就能解決, 但是他卻接受了法務人員說 NO. 為什麼會這樣呢？

我想是因為工程師說的"Yes"與"No"的界線都太模糊了, 以致於一個功能, 兩種解讀. 專案經理說登入的功能要完成, 意思是所有流程, 包括沒有登入過的使用者要導到註冊流程, 輸入錯密碼會有錯誤訊息, 忘記密碼可以寄信更改, 登入後可以登出等, 但工程師說"Yes"可能只有包含"輸入一組已經存在的使用者帳號與密碼, 可以登入系統"這樣一條成功路徑. 大叔在書裡面舉的例子都是很寫實的例子,  前線的人最常說的話是: "我已經答應客戶了", "如果我們不這麼做, 我們就會失去這張大單..",  工程師有時消極的回答"我盡量試試看", 專案經理就駝鳥的當成是承諾; 有時專案經理或 Sales 會塑造一種"只有你能拯救我"的氛圍, 工程師也很愛掉入這種陷阱裡面, 但過往的經驗總是一再證明, 急就章的東西拯救不了任何人, 現在欠下的債以後總會回頭來找你. 我們可以把一切推給溝通問題, 但要改善這個問題, 無疑就是需要更多的練習, 說"不"的時候解釋清楚, 說"是"的時候更要確認雙方認知一致. 有趣的是, "拙於溝通"通常是軟體工程師的刻板印象, 甚至還有些"引以為傲"的味道, 有人會說:"我就是不喜歡與人社交, 才當工程師的呀....", 但那只是對自己專業能力要求太低的而已.

我一直覺得測試非常重要, 但不少工程師覺得測試不在自己的工作範圍裡, 或是 debug 不算在開發時間裡, 但是提交有明顯 bug 的程式碼其實就代表沒有自己驗收過交付內容, 等同於沒有完成工作, 我們不見得要採用 TDD 的開發模式, 但是為每個涵蓋邏輯寫測試是基本的要求. 曾經有組員跟我爭論過這個要求, 他說這些邏輯都很直觀, 他不可能會寫錯, 為什麼要寫測試？但測試不只是驗收當下的 code , 也是為了確保之後新加的 code 沒有破壞之前的邏輯, 從測試項目也可以清楚的檢視是否有涵蓋所有要求, 重構的時候也可以回溯當初的 spec, 好處多多. 當下修復測試出現的問題也是基本紀律, 但很多人會以"不嚴重,  只是警告而已"來忽略,  忽略久了, 對測試出現的紅字習以為常, 測試就失去意義了. 所以要嘛就修正 code, 要嘛就修正測試, 不要得過且過的放任紅字成為日常.

作者大大推崇"pair programming", 但我真的無法忍受有人看著我寫 code (尤其我有很多 type 的怪癖), 不過絕對推崇"code review", "沒有被 review 過的 code 不可以被 merge 進來" 是基本紀律. code review 對雙方都有益處, 整個團隊的coding basic style 可以被確立下來, 多看別人的 code, 不只是挑錯, 有時更是學習不同的思考方式; 想到自己的code 會被其他人 review, 在提交前一定會整理確認一下, 不犯下低級錯誤. 另外, 也可以透過code review 了解專案的其他功能, 而不只是專注在自己實作的部份.

MINEBOOK掘冊連結:
https://www.minebook.tw/book_main_page.php?bookid=20_700416

武漢肺炎籠罩的美國

一月底離開台灣的時候, 那時台灣已經全國戒備,限制口罩出口, 每天都開記者會報告最新狀況, 美國還一派詳和, 剛來的時候, 還參加了社團, 可以一起 出去打球, 吃飯聊天. 二月中以後, 開始急轉直下, 西雅圖, 舊金山, 紐約的感染人數大量增加, 原本一直說肺炎與流感無異的美國政府終於開始採取措施, 限制聚會, 人數上限一直下修, 從百人到五十人, 到十人, Austin 的盛會 SXSW 也遺憾的取消了.

三月中, 宣布學校停課, 公共設施關閉, 餐廳不得內用, 老公的公司也開始在家工作, 同時間美股在一個星期裡四次熔斷, 聯準會短時間內宣布兩次降息, 還是救不了股市, 感染人數一直攀升, 沒有見到轉折點, 公布出來的失業人數高達三百萬, 有史以來的新高, 漸漸的, 我開始感覺到一種風雨飄搖的感覺. 要長期抗戰, 需要做好準備卻發現自己是前所未有的脆弱狀態, 來到一個新環境, 不信任這裡的醫療體系, 沒有親人的後援, 沒有工作.

昨天聽了"This American Life" Podcast, 訪問了紐約州的一些人. 紐約州是現在美國最慘的地方, 感染與死亡人數都是全美之冠. 第一個訪問是急救中心的負責人, 他說每天都要處理六, 七件急救扣應, 比 911 時還要慘, 救護車根本不夠用, 民眾打電話進來, 也無法獲得幫助. 他提到他的一個組員, 夫妻兩人都是醫護人員, 老婆確診在家隔離, 老公雖然想請假照顧她, 但沒有辦法, 因為人手短缺. 結果有一天, 老公回家, 發現老婆已經過世了, 當場崩潰, 但他無法擁抱安慰他的同事, 因為他有極大的機率也是確診病患.

第二個訪問是一個爸爸, 有一個幼兒, 他們夫妻倆都確診, 但老婆狀況比較嚴重, 只能臥床隔離, 他雖然也生病, 但還是要肩負照顧全家的責任. 他不能擁抱他的小孩, 所以只能跟小孩腳碰腳來安慰他. 小孩知道媽媽生病了, 躺在房間裡, 所以看不到媽媽. 雖然他沒說, 但小孩還是知道爸爸也生病了, 他會央求爸爸講全部的人都生病的故事, 包括他自己, 也許這樣就會感覺沒那麼孤單.

第三個訪問是一個女兒, 她的媽媽住在療養院裡, 需要呼吸器, 無法言語. 她是個中國人, 一開始聽到武漢肺炎傳到美國時, 她就打電話請求照護人員戴口罩與手套, 那時她聽到電話那頭的訕笑聲:"你知道的, 中國人嘛..."她沒有感到憤怒, 而是感到絕望, 她知道如果發生院內感染, 她的媽媽一定撐不過去. 兩個禮拜前, 是她最後一次看到媽媽. 雖然她一直跟媽媽說:"我很快就會再來看妳!", 但媽媽彷彿知道了什麼, 一直掉眼淚. 她一個人的時候, 會止不住的亂想, 擔心媽媽的呼吸器會被拿走, 給更有希望存活的人. 她想待在媽媽身邊, 但又知道媽媽會希望她即使一個人也要撐過去, 活下來.

第四個訪問是住在上海的美國人, 她說中國正在慢慢恢復正常, 火車復駛, 但她還是盡量不搭大眾交通工具. 中國政府推出了"健康碼", 基本上出入公共場合, 餐廳或是辦公大樓, 都要出示健康碼, 只有代表健康的綠色才能進入. 中國政府透過手機與該 app 追蹤每個人的路徑, 如果你的路徑與確診的人有重疊, 健康碼就會顯示黃色, 甚至紅色, 這個 app 讓她感覺安心, 但她也同意這種追蹤的行為, 美國人一定不會同意.

我必須記錄下來這些所見所聞, 日後才會知道, 在2020, 我們都經歷了什麼, 包括"武漢肺炎"這個名字也應該被留下來.

Changelog - postman的下一步

前言

大部份的後端工程師都有使用過 postman, 它是個用來送 API request 的工具, 去年六月, postman 拿到 B 輪投資五千萬美金, 這篇 postman 創辦人 Abhinav Asthana 的訪問, 讓我們更了解這個從零到五千萬的故事.

起點

一開始, postman 只是一個 side project of chrome extension, 為了解決自己碰到的問題. 所有的後端工程師都需要反覆嘗呼叫 API, 有時需要帶不同的參數, 有時是不同的環境, 第一個痛點是想要把這些分開的步驟整合在一個工具裡面, 記錄下來送過哪些 API 與參數, 第二個痛點是希望本機端的 API 測試, 參數, 與環境設定可以帶到其他電腦.

Abhinav 很熱愛收到 postman 使用者的回饋, 花在上面的時間越來越多. 後來決定辭掉工作, 和兩個朋友一起來做postman, 但此時 postman 還只是個open source project, 雖然有 "donate" 按扭, 但基本上沒有辦法獲利, 所以Abhinav 做了一陣子的顧問兼職, 這樣他可以兩天做顧問賺錢, 剩下的五天專心做 postman.

有一天, 他接到 Google 的電話, 告訴他會將 postman 放到 chrome store 上的推薦 app, 他們開始感覺可以認真的考慮成立公司, 專心經營 postman, 也因為 postman 的高人氣, 開始接到投資者的電話. 雖然這中間有其他公司談過收購 postman, 成為該公司的產品之一, 或是加入其他公司, 一樣做postman的開發, 但 Abhinav 感覺自己會是最在乎 postman, 想要讓它變好的那個人, 所以決定自己成立公司.

要怎麼讓產品變成7百萬使用者的產品?

最大的轉捩點是提供collection import/export, 因為 A 使用者把 postman collection 給 B 使用者, B 使用者也會開始認識並使用 postman, 這種擴散效應非常迅速且明顯, 因此 Abhinav 開始讓 postman 朝更多協作功能發展.

開了公司以後, Abhinav 更加認識使用者是怎麼使用這個產品, 因此有了更多的靈感. 例如團隊有了可以共同編輯的workspace, 當 A 編輯了新 API, 團隊裡其他組員就希望可以收到通知, 同時也有了權限控制的需求, 哪些 API 可以被哪些組員看到. 有些敏感的資料, 例如API key, 密碼只能留在本機端, 不能任意同步等.

postman 的未來

未來的世界會越來越 API 化, 不管是政府, 或是企業, 都會開放 API 讓使用者可以讀取資料. API 也給予消費者更大的彈性, 利用資料來打造更適合他們的用途.

Abhinav 期待 postman 可以成為 API 的平台, 例如企業可以把他們的 API 放在 postman 平台上, 使用者可以直接使用, 可以對 API 評等, 送 issue, user case, 甚至可以 fork 出來改成自己的版本 (就像是github).

另外一個方向是打造更適合非軟體工程師也可以使用的工具, 例如記者, 他們可以利用描述性的語法來說明 API , 而 postman 可以將 API 的內容實做出來.

Reference Source:
https://changelog.com/podcast/360