熱狗攤與專案管理

上圖為加拿大熱狗名店Japadog的hot & spicy,我是覺得不怎麼辣,倒是薯條鹹到我快中風;整家店就看我一個人拿著張餐巾在那邊邊帶著複雜的表情邊對薯條不知道磨蹭些什麼,想來畫面應該挺微妙的 …

好啦,言歸正傳,這篇的重點不是熱狗,我們來想想一個問題:

『如果要經營一個超棒的熱狗攤,最重要的要素是什麼?』

這個問題並非我原創,是我在Rapid Development一書中讀到的,作者Steve McConnell試圖用貼近生活的問題來帶領讀者思考專案開發中最核心的問題。

那答案是什麼呢?

你今天把產品弄壞了嗎?

昨天台灣時間凌晨1點前後,咱家WordPress.com分享至社群網路的功能Publicize全面炸裂長達4小時,只見論壇上哀鴻片野,眼看俺們公司就要被鄉民給放火燒掉 …

這件事詳細的原因不方便明說,就姑且說是某位夥伴不慎上了一個patch把整個功能弄壞吧。這段時間受害的用戶上萬,從system team到product team頃全力救災,最後仍有些損壞資料無法恢復。好像很嚴重吧?揪~竟這位夥伴事後受到怎樣慘絕人寰的處置呢?

關於Code review這檔事

說到code review這件事,相信這年頭凡是吃碼農這行飯的,多多少少已經成為工作的一部分了( 啥?貴公司沒在做這件事甚至反對這件事?塊陶啊~~~)

如果估狗『how to code review』、『code review guidelines』等關鍵字,很容易就可以找到許多不錯的參考文章,但很多都是超過十項的點檢表,我實在不擅長記憶這麼多項目,常常邊看邊忘,在腦內只留下了浪漫模糊的輪廓。

點檢表是非常有用的,特別是在初期對一個code base還很不熟悉的時候。例如咱家WordPress VIP code review guidelinesWordPress theme development checklist、這篇Kevin London的Code Review Best Practices也曾被轉載一陣。待對code base熟悉到一個程度以上後,記憶幾個好記的思考源作起點再從之延伸,對我來說比較容易掌握:

  1. 我了解整個patch / PR的目的嗎?
  2. 我知道該怎麼測試嗎?
  3. 每一行變更的意義我都完全了解嗎?
  4. 我們能做得更好嗎?

輕快的檔案巡覽組合:Unite + unite-git

demo-unite.gif

Github repo連結:

寫程式工具百百種,個人在工具選擇上較偏好用多種專做一件事的工具鏈而非一個整合一切的IDE。單一工具的功能愈單純愈輕量愈好,有點像是Unix的『do one thing and one thing well』原則。愈單純通常代表了高泛用性,讓我不管在哪個平台、開發哪種語言,都可以使用同一套工具;也因此,vim一直是我慣用的文字編輯器。我知道它有點像藍紋起司或納豆,喜歡的人看到就心臟蹦蹦跳,討厭的人聞到就吐得不能自己。

vim畢竟是文字編輯器,巡覽檔案並不是它的強項;它沒有『專案』的概念,原生不帶IDE必定會有的專案內檔案快查功能。我以前靠FuzzyFinder,但它真的很慢又不穩定,後來發現了Unite,簡直是發現新大陸。Unite + unite-git用起來就如上圖,我可以透過Unite的fuzzy search來快速巡覽git ls-files --cached的輸出,加上這個指令的輸出本身僅會列出目前所在工作目錄下的檔案,即使是像calypso這樣大型的專案也可輕鬆巡覽。

從WordPress REST API到WordPress Compatible

去年底WordPress 4.7熱鬧登場,在諸多熱辣辣的新功能中,要算將WP REST API納入核心使得人人有REST API用,影響最為深遠了。這代表往後任何人只要實作了與此API溝通的app,自動就有像天上星星那麼多的WordPress網站是你的潛在用戶;討厭php嗎?理論上你可以用任何你喜歡的toolchain實作這個API,那些透過此API與WordPress網站溝通的app,自然而然就能用在你的網站上。(不過後者恐怕還要等使用者認證、授權等API穩定後才較實際)

其實這不是什麼新概念,所謂interface as contract的概念早在web前就有了,令人想哼起經典老歌:Everything Old is New Again:

之所以放在WordPress上好像鑲金了,主要還是『像星星這麼多』這件事,造成它不容忽視的影響力。看看那個知名的content injection漏洞吧!甫一露出就十幾萬網站爆炸呢 ^.<

函式的兩易一難

正文開始前,分享一段個人非常喜歡的演講:Philip Wadler的『Propositions as Types』:

其中有一段很讚的話:

Computer Science. There are only two things wrong with it: Computer and Science.

身為CS出身的碼農真的是被婊到心坎裡 …

這句話背後的意義是,我們真正在做的事情,其實是資訊的構築與轉換,計算機或程式語言不過剛好是我們用來處理這些問題的工具,也因此他認為較適合的名稱其實是Informatics之類的東東。什麼意思呢?例如Int版的toString如果用Haskell type annotation來寫,大概是

toString :: Int -> String

也就是從一個結構為整數的資訊到一個結構為字串的資訊的轉換。sort則是

sort :: Ord a => [a] -> [a]

從[a]到[a]雖然沒有發生資訊的類型轉換,但輸出的[a]會是排序過的。這件事通常不會表現在type annotation上,但硬要幹的話應該也不是不行;例如定義一個type叫OrderedArray,上式就變成

sort :: Ord a => [a] -> OrderedArray a

雖然骨子裡我們做的是如此充滿數學與工程的事情,也許正因為語言扮演要角吧?寫過幾年程式後,大家都會發展出自己的風格,為了避免一個code base被搞得像超現實主義的大雜燴,於是有了各式各樣的coding standard來做基本規範。一個好的coding standard,個人覺得會像是制定一個基本框架,讓大家能在維持基本結構統一的情況下發揮創意,就好像七言絕句或詞牌一樣,與各種programming paradigm交叉組合下,漸漸地寫程式這樣聽起來如此geek的事情,本質上好像與更為貼近了。

可能因為個人偏好functional programming吧?我寫程式喜歡以函式為單位開始,而不管用哪個語言,我寫一個函式的原則是兩易一難易讀、易測、難誤用

OP: 進入業界前,該先學什麼呢?

『在學生時期最好先準備好哪些技能,在業界生存會更容易呢?』
『剛離開校園的菜鳥碼農,最好開始學習什麼?』
『回顧這幾年來的碼農生活,你認為哪些技能最重要?』
『…』

在這個瞬息萬變的資訊業界,只要累積一定年份的資歷,上列問題總是會被問過個幾次的。所謂他山之石可以攻錯,前人踩過的屎坑能不踩當然是不踩比較好;如果能從自己的經驗中提取些什麼,讓後輩可以走得比自己更快更遠,又何嘗不是美事一件?世代更迭,不就是這麼回事。

像什麼追蹤一些重要人物的twitter啦、讀一些經典好書啦、精通至少一項程式語言什麼的,我不覺得我有辦法寫得比Joel on SoftwarePragmatic Programmer之類的更好,但我倒是想推薦大家花點時間去學習一個許多人都忽略、甚至不屑分神照顧的事:

投資理財。

可能資訊產業實在是太夯了,我們從學生時代就聽過數不清的成功故事。創業成功、剛畢業就被網羅入Google、Facebook等大公司薪水多到花不完等等,在在告訴我們:code中自有顏如玉,code中自有黃金屋,放手去闖吧!更何況鑽研演算法和各種酷炫的科技坦白說刺激好玩太多了,結果許多資訊人認為投資理財很遜,根本懶得去碰。

面對現實吧!這些成功故事都屬於那些不到1%天賦異稟的人。像我這樣屬於其他99%的普通人,靠的就只有咬合力100T的牙齦,埋頭苦幹個10年終有小成,才發現黃金屋是有,只是還要再花10年自己蓋。

就我個人的經驗,其實學一些『正常的』投資理財概念不會花很多時間,卻受用無窮。類似的觀念甚至可以用在平日工作的時間分配與專案管理上。而且我認為,如果一個人沒辦法把10元用好,給他10萬元他也沒辦法用好。這就是為什麼經常聽到某些人中了幾百幾千萬的大獎,第一件事就是去買名車,然後過個一兩年還得賣車外加打工還債。

試在心中回答以下問題:

  1. 請問上個月您的儲蓄增/損多少錢?
  2. 請問上個月最大筆的支出來自何處?
  3. 請問您的儲蓄目標為幾年存到多少錢?

如果您很快就可以回答,恭喜您,請左轉ptt去讀些比這篇更有料的東西吧。然而,如果沒辦法不看任何紀錄就大致知道以上的答案,那您很可能跟以前的我一樣,對自己的財務漠不關心,還請你留下來聽我講講古。

以下彙整幾項個人覺得比較重要的概念簡介。