創意競擇 Creative Selection 閱讀心得
對我來說這本書給了我許多啟發,身為工程師的許多啟發
這本書以一位工程師 Ken Koclenda 的視角介紹他在 Apple 的研發生涯(參與 Safari、iPhone、iPad 等軟體的開發),開發途中的經歷與體悟。
我認為這是本質得任何工程師、或對程式設計有興趣的人花點時間翻閱的書,不僅能讀到開發頂尖產品的幕後故事,了解工程師們的幕後工作流程,還有些情境除了引人省思外又令人感同身受的會心一笑。
接下來會以三個角度分享我書中的收穫:
- 問題不限定解法 — 找對方向,盡力執行
- 簡單明確的目標 — 只有提升效率才能修改
- 培養設計的品味 — 軟體鍵盤設計
問題不限定解法 — 找對方向,盡力執行
如今,多數人覺得瀏覽器的存在理所當然,不只是手機、電腦內建就有,甚至有事沒事而然就打開瀏覽器在網上閒逛。這些時候我們不會意識到「瀏覽器」這個已經深入日常使用習慣的東西也是一種需要開發的技術。
作者肯在前公司破產後跳槽到Apple,那在那裡他接下了第一個任務:為 Apple 設計一款專門的瀏覽器。當時 Apple 剛推出自己的 Mac OS X,但上面仍然搭載微軟的 IE 瀏覽器。Apple 認為網路是未來電腦、通訊的重要部分,並希望能夠在這個新興領域掌握自己的命運。
肯之前完全沒開發過瀏覽器,直覺的想法是先找開源的軟體移植到 Mac OS 上才能節省重複開發的時間,但很快就碰到問題了。由於 Mac OS 才剛面世三個月的作業系統,且這項瀏覽器是保密項目,肯沒有辦法把問題貼到網上或詢問其他非專案的同事。
他們花了六週的時間研究這個 150萬行的開源瀏覽器的程式碼,完全沒有進展的情況下… 甚至還打算在 Mac OS 上重建開源瀏覽器的設計環境,重寫部分「C語言庫」,這對軟體而言就像移植大腦手術一樣的大工程。
▍做最有價值得事,排出優先順序
肯與當時的團隊成員都是資深工程師,但卻對這個問題毫無辦法,好在他們也有同時在招募新成員,這位新招募的成員理查在兩天內就推出一次展示,在螢幕上展示出能動的瀏覽器。
並不是說理查的能力有多麽超群,他在第一天就判斷出肯他們的方式將 150萬行開源算體移植到 Mac OS 短時間是不可能的。
所以理查僅列出三個要達成的目標:載入網頁、點選連結、返回前頁,並且從不同的開源程式中拼湊出上述功能。這個展示並沒有與 Mac OS 的系統整合,也沒有精簡化複製過來的程式碼。因為這些並不影響展示這個目標。
理查很明白「展示」是關鍵,比起一開始就嘗試將一切都做好(移植 150萬行的程式碼),展示能動但不完美的雛形才是當時最有價值的行動。
▍沒有理所當然,一切的基礎就是程式碼
這次的展示讓 Apple 高層對新建構瀏覽器的計畫有了充分的信心。他們也開始要將原本展示用的程式碼優化,並移植到 Mac OS中。
作者將程式移植用「食譜」來做比喻。例如:當我們要做章魚燒時,食譜中會有一行寫:請參考第 XX 頁如何做美乃滋,這樣交叉引用的方式讓書本變得精簡,避免一本書重複提到數十次怎麼做美乃滋,保持食譜的精簡和可讀性。
如果我們不小心翻錯頁,或者食譜中將「美乃滋」拼錯字,我們就無法在 XX 頁找到美乃滋的做法。而程式其實就是個大型食譜,各個程式間充滿了交叉引用,只要拼錯字或者找錯檔案,就無法啟動對應的功能,程式就會報錯。
由於先前展示時是複製開源軟體,是不能商用的。移植到 Mac OS 時必須將交叉引用的內容轉移,如果 Apple 內部已有相似功能,就改成引用 Apple 的,如果沒有就重新寫一份。
這部分就是枯燥乏悶的「運行 → 報錯 → 修改 → 再運行 → 再報錯 → 再修改 的循環」。這麼不斷重複枯燥的兩個多月後… 這隻瀏覽器的程式終於能運行了!再厲害在強大的程式,背後都是一行行不起眼的程式碼。而這個瀏覽器正是內建於所有 Apple 產品的 Safari。
簡單明確的目標 — 只有提升效率才能修改
雖然瀏覽器的程式已經能動起來了,但離正式上架還遠著,這就好像爬一座山,通過山頂固然值得高興,但仍得安全下山才算真的完成。
▍過早優化是萬惡之源
程式設計師把大量的時間浪費在思考或擔心程式非關鍵部分的速度上。當我們顧及程式除錯與維護時,那種對效率的追求其實有很大的負面影響。大多時候(大概97%的情況下),我們不該執著那種微不足道的效率。
舉個例子,一位工程師花了幾天時間優化某個功能,成功將其效率提升一倍,然而這功能卻只啟動少少的幾次,雖然該功能效率確實提升了一倍,但在整體的角度上感覺不出任何差別,但卻實實在在浪費許多研發時間,因此過早優化是萬惡之源。
理想上,多數設計團隊會先確認程式能運行,等到多數故障排除後,再來提升速度。先搞定功能,在做效能優化,這是典型的做法。
事實上,完成的功能的時間往往比預期的還久,而交付時間表又無法改變,最終只能放棄效能的優化。
▍簡單才會明確
賈伯斯對瀏覽器的效能有明確的要求,由於產品對標 Window 的 IE,因此網頁的載入速度便是關鍵。當時的 IE 載入速度極為緩慢… 載入一張圖片,從模糊變清楚往往要等數十秒到幾分鐘。為了不讓使用者有機會質疑為什麼不使用 IE,Mac 的瀏覽器必須能快速載入。
如前面所述,雖然瀏覽器已經能運作,但還只能龜速運作、並且時不時載入網頁會呈現亂碼、放入購物車會遺失、登入按鈕會失敗… 還有一堆功能性問題待解決,修復這些功能佔用了大量時間,根本無法抽空去優化效率。
為此他們想到一個解決辦法:寫一個能偵測效率的工具 PLT (Page Load Test),每次載入固定的網頁,計算載入網頁的平均時間,並且規定「每次修改不能慢於比前一次才可以更新」。
PLT 是針對瀏覽器的載入速度計型量化的指標,這傳達很明確理念:「我們的瀏覽器只會越變越快,不可能會變慢」。
▍功能與提升效率的交易
多數情況修復問題並不影響對 PLT 的分數,如果新的修改可以讓 PLT 維持或著加快就可以過關,有時還有意外之喜,解決了某個困擾已久的 bug 後,速度大大提升!這是因為品質較好的程式碼往往運作的也比較快。
若修改對後 PLT 的分數變差就比較棘手了,必須要找出拖慢速度的原因並且優化它。
但有些時候就算做了最精細的調查與研究,仍然不夠。要加上新功能時一定會拖慢速度。例如:實作「上一頁」的功能,這需要瀏覽器記得「上一頁」的網頁資訊,儲存上個網頁肯定會使 PLT 分數更慢。
「上一頁」這個功能太重要了,不能放棄又找不到不影響速度的方法時,只好設立一個交易機制,從既有的程式碼中找加速一段不相干的段落,藉此「彌補」新功能帶來的效能成本。
這種優化並不容易,且找問題的過程不見得有趣,不過確實讓整個團隊對整支程式更佳熟悉、也將其打磨的更精細。
培養設計的品味 — 軟體鍵盤設計的啟發
在 Apple 並沒有太多時間沉浸在成功的喜悅
如果你已經出色地完成了某件工作,你就應該嘗試其它有意義的事情,不要再一件事情上停留太久,多想想下一步該做什麼。
— 史蒂夫·賈伯斯
“I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.”
— Steven Jobs
肯也很快往下個專案發展,這次他們的挑戰是為 iPhone 設計一套軟體的鍵盤。要知道那是多數螢幕都無法觸控的年代啊!沒有人有軟體鍵盤的開發經驗,因為當時世界上根本沒有人做過。
▍從使用者的角度思考
專案啟動時,負責人對 iPhone 的要求是使用介面能一個直觀的操作:於是他在桌上鋪了一張紙,伸出食指壓住這張紙,靠著食指把紙張移來移去,然後說:「系統應該這樣運作!」
這種觸控式螢幕的直觀操作,如今已被視為常態,但當時無疑是劃時代的創新。任何工具使用時都需要時間熟悉,而手指頭則是人們已習慣使用的工具,幾乎沒有學習成本。Apple 為了將直觀操作的效果最大化,決定配合將功能整合到這個觸控式螢幕上。
鍵盤怎麼移植呢?最直觀的想法是把鍵盤完全照搬到手機上,但iPhone 的螢幕還不到半個實體鍵盤大小… 若直接移植,指尖按壓屏幕的面積就蓋住了 4~5 個按鍵,因此照搬是不可能了,一定要對原有鍵盤做調整,那怎麼調整呢?
▍實際演示勝過文字報告
當時也沒有人知道該怎麼設計「軟體鍵盤」,於是所有的工程師被迫暫時中斷手頭任務,一同參加一場「鍵盤大賽」,集合所有人之力一同克服這項技術障礙。
鍵盤大賽,實際上是所有人一人設計一款鍵盤後,大家再聚在一起互相展示。就如同 iPhone 上的每個主要功能都是從演示開始的,而一個實用的演示必須具體又明確。如果沒有實物說明也很難有建設性的討論。
…
舉例來說:請想像一隻「可愛的小狗」,你可以閉眼想一下… 越詳細越好!
想好了嗎?我也想好了!我覺得我想的小狗比較可愛!
…
上述情況雖然看似很荒謬,卻是現實中很常出現的討論,這種比較根本無從分出高下,也沒有具體細節可討論的… 但如果有實體的照片能展示就簡單了。
實際演示能將一個概念從無形轉化成有形,雖然演示很難很麻煩 (因為你不能光說不練),但是能讓這種不可能進行的討論變得可能!
▍演算法與策略
肯想既然照搬實體鍵盤的按鍵太小,那就放大按鍵讓使用者不容易按錯。放大按鍵後沒法塞入所有的字母,就將數個字母整合在同一個按鍵中。按下對應的按鈕系統自動算出機率最高的單字!肯靠著「自動選字」的功能從一眾鍵盤中脫穎而出。這個「自動選字」的功能就是演算法。
自動選字的運作基礎是從字典中找出最相近的單字,當使用者想要打出字典中不存在的字時,系統反而曲解了使用者的意思強行修正成最相近的字。舉例來說:使用者打 oooorr 想要強調「或」,但是系統卻自動判斷成 polite。超過某個臨界點後,不用自動校正功能效果反而更好。而訂出這個臨界點就是策略。
演算法與策略都需要反覆設計、調整、和實驗,累積足夠多經驗後才能確定哪個選擇較為適合。這也是為什麼需要許多的實體展示。唯有找到演算法與策略的平衡點,才能開發出讓消費者滿意又流暢的產品。畢竟「設計」是看產品如何運作的!
結語:科技與人文的交會點
身為一位開發者,這本書給我許多感觸,在產品開發方面:沒有一個設計從一開始就是完整的,而是經過無數次迭代與修正,結合使用者的使用體驗才能逐漸完善的。
身為一名工程師,我看到如何拆解問題,把大問題化小、把模糊變具體,說到底一切都會回歸基礎的那一行行程式碼,產品就是由這皆微小的基礎堆疊而成的。
身為一名使用者,我感激被我使用到的產品,一個好的設計離不開打造和維護其運作默默付出努力的人們。
身為一位讀者,感謝作者肯將這段經歷寫成書出版,我更深刻體會到日常中的不尋常。
最後感謝讀到這裡的你,有你們的支持我才會能堅持撰寫與分享。<創意競擇>是一本資深工程師的自白書,作者在分享自己的解題思路的同時也分享他的從中學到的收穫,很值得我們參考,推薦給任何有在開發或對開發有興趣的朋友們!
<創意競擇> Readmoo 傳送門: https://moo.im/a/5kprBC