那些在Now.in學到的 – Software engineering practices

Now.in這個網站在2009年年底上線，在這幾天參加IDEAS Show之前終於來到了台灣前五百大，全球六萬名，這期間只花了一年半，而事實上這個網站早在我大學一年級約2006年左右就開始有這樣的想法，接著花了一兩年的時間開始構思和找相關的技術，2009年開始實作，從開始到上線只花了一年的時間，其中專案之龐大還有牽扯到的層面之廣，從架構的設計、後端伺服器的譔寫、前端網頁、Client端、伺服器管理、資料庫管理，很多人都不相信這只有我一個人完成的，而且還是在讀大學和碩士的課餘時間，直到最近上線的Android和iPhone才找了同學幫忙寫，感寫他們這幾週的辛苦

這整個過程的經驗，事實上多到可以寫一本書，不只是技術上的，之後有空我也會寫一些文章來分享我在其中所學到的一些東西，今天我要分享的是我在碩士一門軟體工程課以Now.in為主題所分享的一些經驗，主要是一些我在開發Now.in前後所體認到的一些經驗與想法，因為我發現很多人不是沒有技術，而是缺少對於服務、軟體工程等等的相關思維，或許這篇文章會有一些幫助，除此之外，我也希望能夠將我自己的想法記錄下來，當我要接受新的想法時，就可以回頭看看以前的自己為什麼會有這樣的想法

人越少，越有效

這樣的想法主要來自人月神話這本書，軟體開發不像是收割小麥，人越多越有效率，因為需要溝通，這意味著當你有越多人牽扯在這其中，所花的溝通成本也越高，每個人的平均效率就越低，除此之外，有一句話這麼說

讀程式比寫程式困難

相信有寫過真正程式的人都會有這樣的體認，寫程式的過程是將你的思想轉化為程式寫出來，而讀程式則是透過這些字句語法來理解程式原本的想法，就有如瞎子摸象一樣，因此當你的團隊裡有越多人寫同一份程式，光是在讀程式理解想法才能繼續寫的這整個過程中就損耗了不少生產力，因此甚至知名的電腦科學學者Dijkstra主張程式應該由單一個人來寫，因為它是一個人的想法

這樣的想法除了來自人月神話，也受最近出版的一本書Rework影響，它是來自37Signals公司的經驗，37Signals是一家小型軟體公司，雖然只有十幾個人的規模，但是推出的產品都很受歡迎，他們強調要找對的優秀開發者，還有開會是造成生產力浪費的原因之一，我認為Now.in之所以能以我一人之力完成，正因為我不需要開會做決策、不需要溝通，將我自己的生產力發揮到極致才有可能完成的

然而，如果是小型的專案能夠一個人寫當然是最有效率的，但是當專案的規模大到一定的程度，超過一個人或少數人能完成的地步，增加人力資源就是不可避免的事，不過在此之前，要慎重考量引入新的人力所造成的影響

保持敏捷

很常見的錯誤軟體開發方式就是一口氣推出一大堆功能，然後期待使用者會喜歡這些功能，但是可悲的事實是這些功能推出來通常都不是使用者所要的，就如投影片所表示的，一口氣在單一個開發循環中推出了一大堆的功能，這花了很多的時間與心力，但是卻發現使用者要的的只有一小部份和目前所做的有所重疊

在現實上，你總覺得你可以抓到使用者所想要的，但仔細想想會發現那是你自己想要的，並不一定每個人都跟你想要的是一樣的東西，一口氣在一個循環內開發如此多的功能，對於變化如此快速的網路世界來說，你永遠都趕不上變化

邊移動邊開火才是正確的方式，這有一部份的想法是來自約耳談軟體，如投影片所看到的，一開始先從最核心的功能做起就好，然後看使用者的反應與需求再來改版與新增功能，盡量保持每個開發循環很小，才能抓到使用者所要的

Now.in就是這樣的開發方式，就如投影片裡的抓圖，在一開始只有最核心的廣播功能，其餘的功能都是後來才加上去的，因我看見了需求，我看見使用者們邊聽廣播邊在PTT上推文討論，顯而易見的聊天是必需要有的功能，此後才開發了聊天室

右手邊這張圖是來自Rework裡的插畫，他們認為計劃就是在猜測，是的，沒錯，網路上充滿了創新與變化，很多東西是以前從來沒有人做過的，那麼你要如何計劃? 你沒辦法計劃，任何五年、十年計劃之類的東西都只是在賭博而已，不要浪費時間做太過長遠的計劃，邊移動邊開火才是正卻的做法，阿里巴巴的馬雲也說過，他們成功是因為

沒有資金、沒有技術、沒有計劃

這裡指的沒有計劃就是這麼一回事

老程式不死只是凋零

很多人會犯的一個毛病就是認為舊的程式都是很糟的，要完全砍掉重新寫才是好的，但是事實上從我的經驗告訴我，那些在線上跑經過多次修改的，遇過一大堆你在開發中想都想不到的詭異問題才存活到現今的，它們是如此的老練，有很多失敗的例子就是因為將舊有程式丟棄，直接採用全新的程式來面對實際的應用，事實上這樣就有如送沒見過世面的新兵上最慘烈的前線戰場送死是沒有兩樣的，我想或許Digg就是這樣的一個例子

Digg在去年推出全新的版本，但是不停地出現嚴重的問題，加上新的使用方式受到原本的使用者反彈，導至使用者大量且快速地流失，另一個例子是Netscape在推出新版時將舊的程式全部丟掉，在約耳談軟體的Things you should never do裡有提到

所以我們就一直使用舊程式就好了? 請別會錯我的意思，我想表達的是在前線跑的程式裡有太多是你重新寫不會想到的問題處理，請不要單純為了想砍掉重練而重寫，你需要的是重構而不是重頭寫過，就算你真的打算重新寫過，也請好好重視原本的寫法，以Now.in來說，有些東西就是從最早的版本傳承到現在的經驗

# XXX Workaround for fucking IE6, fuck you IE6!
response.cache_control = "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"

像是腦殘IE會cache不該cache的東西，這樣的經驗只有真的有在前線跑過的程式才有辦法知道，除此之外還有你想不到的不同奇奇怪怪問題，因此老程式需要你的一些尊重

效能通常不重要

效能很重要嗎? 很重要，但是只有在很少的場合發生，身為技術人員有個壞毛病就是很愛計較效能，這個跑benchmark，那個也跑benchmark，總得要挑一個最有效的方式來實作，但是花了這麼大的心力在於效能上，在現實中效能並不是在所有情況都這麼重要的，有很多程式，例如按鈕的事件回應，你需要花很大的心力去最佳化那段程式嗎? 通常是不用，但是如果是最核心的演算法，會影響到整體表現甚至使用者經驗的，那就是得花心力去處理的部份，但即使如此，現在的硬體越來越便宜，同樣的價錢可以買到的運算資源越來越多，雖然不代表你可以因此隨便亂寫，但是代表你可以花更多心力在更重要的事情上。

除此之外，單一機器的運行效能以現今的觀點看來已經不是太重要了，因為更重要的是架構上的有效，擴展性遠比任何某一段程式的最佳化還來得重要，以Now.in為例，並沒有花太多心力在單一程式的最佳化上面，但是花了不少心力在於思考分散式的架構，如此一來才能增加機器來提升整體的承載能力。

使用者經驗很重要

我想技術人員開發的產品最常犯的一個毛病就是以自己的觀點來開發產品，很常見到很多產品都強調他們有多少功能，多強大，但是使用者界面卻出奇地難用，或是因為那些過盛的功能導至產品太複雜沒有人會使用，對我來說服務就是完全關於使用者經驗的事情，從使用者的角度來思考，就會發現其實使用者根本不在乎你的產品能不能提供多少強大的功能，他們只在乎好不好用，能不能解決他們自身的問題而已，我想最佳的例子就是Dropbox與Syncplicity

明明Syncplicity比Dropbox還早推出，甚至功能更強大，Dropbox只能同步一個資料夾，然而Syncplicity可以同步任何資料夾，可是Dropbox大成功，Syncplicity卻乏人問津，這其中最大的問題就在於，Syncplicity沒有考量到使用者經驗，有人在Quora上問了為什麼Dropbox會比Syncplicity成功，Syncplicity自己的CEO自己就跳出來說為什麼，簡單的來說就是以功能導向在思考產品而不是使用者經驗導向。

那什麼又是使用者經驗? 使用者經驗扯到的範圍很廣，從他發現這產品的開始，到他使用產品本身，這整個過程與體驗都是使用者經驗，比較Syncplicity與Dropbox，Syncplicity光是名稱就輸一截了，想取Simplicity的協音，然而卻是複雜的體現，名稱的發音對很多人都是一個問題，而功能上因為太強大，使用者不知道怎麼用，亂用一通，甚至拿來同步Windows資料夾，而Dropbox只有一個資料夾，要同步就拉檔案進去，簡單易懂，當然是簡單的受到使用者歡迎，而非功能強大的

技術只不過是一張軟體樂園的入場卷

身為技術人員，我會跟你說技術很重要，但重要到什麼地步? 只不過是一張入場卷，我會這麼說。

為什麼這樣說? 原因很簡單，你想進來這圈子玩一玩，沒有技術我會告訴你，門都沒有，然而你如果有很強的技術，恭喜你，你的入場卷比別人的大張，你可以享有優待，你可以玩最新最酷炫的遊樂設施，如果你的技術很爛….，那麼很抱歉，你只能玩別人不想玩的無聊遊戲，沒人排隊的地方，玩玩就回家去吧，但是即使你有很大張的入場卷，也沒辦法滿載而歸，因為除了技術以外還有太多東西值得你去玩，不管是市場的遊樂設施、商業上的、金融上的，軟體的開發不是只有技術而已，光是你要去哪裡找人才，市場的定位等等，都不是那麼容易的事情，常常見到很多人有一身的技術，但最後淪為技匠，空有一身本領但是還是沒有舞臺，沒有很好的發揮，我自己很久之前就有這樣的體認，因此我對自己的期望不只有技術上的進步，我也花不少時間在接觸不同的事物上，思考技術以外的問題。

沒有銀彈

最後，套用一句軟體工程的名言 「沒有銀彈」 ，也就是沒有一種可以解決軟體工程上所有難題的方法、或是想法，這些是我在這過程中學到的經驗，並沒有辦法適用到任何的情況上，至今想法還是多少會有改變，但次每次的改變都是透過深刻的體認和思考才做出的結論，並不是隨波逐流的想法，我講的不一定是對的，在讀我文章的同時，希望也能仔細思考這其中的涵意和你們自己的體驗，找出最適合自己或團隊的想法，才是最重要的事。