Prototype, Prototype, MVP … 誒?

“In writing, you must kill all your darlings.”― William Faulkner

Prototype一詞目前最常見的翻譯為『原型』,意指在實際製作成品之前,先用較簡易的方式將概念具現,以求能以低成本早期取得使用者回饋。這放在工業設計上,可能是從早期數百種草圖中挑出來幾個做成的紙板模型;從app UI/UX上,可能是用invisionproto.io製作的;遊戲上就更精彩了,因為沒有既定形式,各有各的獨門絕活。我個人最喜歡的例子是Journey:

比較一下完整的Trailer:

他們用簡單到不可置信的方式成功捕捉遊戲的核心機制,並有效進行調整。

我的經驗上,相較於這些許許多多的設計師,軟體工程師在prototype上的概念比較薄弱。或許是職業使然吧?設計師因為是擘劃藍圖的人而不是實際下地抹水泥的人,這類實務對他們不但是習以為常,更是實際跟工程師溝通時不可欠缺的工具。但工程師因為可以直接做出來,常常覺得prototype只是多了好幾次工,增加麻煩而已。

但我們還是需要prototype:prototype某項設計、prototype某項功能、prototype整個產品的最小集成看看感覺。因為實作成分多,結果就是常常看到有人說要給prototype,給出來的卻是MVP(minimum viable product,最小可行產品)。

繼續閱讀 “Prototype, Prototype, MVP … 誒?"

『我們處在太空時代』

Clojure作者Rich Hickey的這段2012年的演講:The Value of Values,這陣子一直忍不住在腦海裡玩味,完整演講請右轉infoq: https://www.infoq.com/presentations/Value-Values,總長58分53秒,有空嗎?買包洋芋片配著看吧,絕對值回票價。

他首先定義何謂"place-oriented programming",到"value-oriented programming",最後推衍到為何我們可說是處在編程的太空時代,為何我們應該要建立全新的資訊系統來符合這個時代。

繼續閱讀 “『我們處在太空時代』"

關於pull request這檔事

之前寫過關於code review這檔事,那反過來說,關於發pull request這檔事呢?(或者說發patch也適用,以下就姑且都說PR吧,節省篇幅愛地球。)

Automattic的夥伴們都挺愛挑毛病修細節的,PR來回修個幾週才進、打掉重寫,或是要拆細重發等等多不勝數,所以以下也算是個人在敝公司發PR的生存守則:

  1. 單一目的
  2. 測試方法清楚簡單
  3. 迭代大於完美

繼續閱讀 “關於pull request這檔事"