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只有一個資料夾,要同步就拉檔案進去,簡單易懂,當然是簡單的受到使用者歡迎,而非功能強大的
技術只不過是一張軟體樂園的入場卷
身為技術人員,我會跟你說技術很重要,但重要到什麼地步? 只不過是一張入場卷,我會這麼說。
為什麼這樣說? 原因很簡單,你想進來這圈子玩一玩,沒有技術我會告訴你,門都沒有,然而你如果有很強的技術,恭喜你,你的入場卷比別人的大張,你可以享有優待,你可以玩最新最酷炫的遊樂設施,如果你的技術很爛….,那麼很抱歉,你只能玩別人不想玩的無聊遊戲,沒人排隊的地方,玩玩就回家去吧,但是即使你有很大張的入場卷,也沒辦法滿載而歸,因為除了技術以外還有太多東西值得你去玩,不管是市場的遊樂設施、商業上的、金融上的,軟體的開發不是只有技術而已,光是你要去哪裡找人才,市場的定位等等,都不是那麼容易的事情,常常見到很多人有一身的技術,但最後淪為技匠,空有一身本領但是還是沒有舞臺,沒有很好的發揮,我自己很久之前就有這樣的體認,因此我對自己的期望不只有技術上的進步,我也花不少時間在接觸不同的事物上,思考技術以外的問題。
沒有銀彈
最後,套用一句軟體工程的名言 「沒有銀彈」 ,也就是沒有一種可以解決軟體工程上所有難題的方法、或是想法,這些是我在這過程中學到的經驗,並沒有辦法適用到任何的情況上,至今想法還是多少會有改變,但次每次的改變都是透過深刻的體認和思考才做出的結論,並不是隨波逐流的想法,我講的不一定是對的,在讀我文章的同時,希望也能仔細思考這其中的涵意和你們自己的體驗,找出最適合自己或團隊的想法,才是最重要的事。
很好的觀點,而且您也做到,令人折服。
Pingback: 那些在Now.in學到的 – Software engineering practices | 程式設計 遇上 小提琴 - Dennis' Blog
值得尊敬的一篇心得
真是棒的文章!
講的真好,很棒的文章
寫得非常好,感謝你的心得分享,
也恭喜 Now.in 在 IDEAS Show 上的傑出表現! 🙂
Great points…I think the same way also fit into many different scenario such as late comer facing first mover with comprehensive sku’s.
勝讀十年書!
相當用心的分享。:)
身為一位非理工科系的人,很佩服您有考慮到使用者的觀點,我也是now.in的常客,非常棒的網站:)
這些觀念我在其他地方有讀過…
但最棒的是您用實務經驗來驗證 !
很棒的文章,
我換了公司後才深刻體會到「技匠」永遠跳不出「技匠」的思考模式
software除了技術外,還有很多東西也必須學習的
Pingback: links for 2011-07-31 : Not Even Wrong
很棒的觀點跟心得分享!!
Pingback: 網路創業家必懂的九大重點 « 優福網資訊有限公司
您好:
我是輔大資管的學生。看到您寫的文章十分讓人有淒淒之感。
想分享這篇文章在我們的討論版上,請問可以嗎?
這是我們的討論版:http://eoffice.im.fju.edu.tw/phpbb/index.php
Pingback: Twitted by Tasuka
剛醒來時,看到網友貼了這文章的連結就這樣過來晃晃。
看完內容,去Now.in逛一下,著實覺得博主的學習經驗真是豐富。
畢竟一個大學畢業剛唸碩士的人來說,有這麼豐富的實務經驗實屬少見。
其實就樣博主說的,軟體設計沒有一個正確的答案。
很多學弟才會問有沒有正確的寫法,但依照題目的難度、開發時程、技術門檻來考量,正確答案未必能符合結案必需交出的標準。
當然,如果針對特定架構或方向,能透過大量實務經驗獲得通一的架構是最好,不過那必須花費長時間的研究與觀察,多少有些不切實際,但就長時間研究來說會是個好方向。
綜觀整篇的內容,雖然用的解釋方式不盡相同,但博主的觀點時為正確。
不過幾個觀點,是鄙人近年來實務上的結論,和博主分享一下。
>> 讀程式比寫程式困難
這點鄙人毫無反駁的意思,因為這是鐵打的事實。
只是在帶領小團隊時,鄙人卻發現,讓這現況顛倒過來,團隊的合作才能穩定。
身為程式設計師,不論多某不甘願,必要情況下都是要閱讀別人的程式碼,即便那是天殺的爛。
但是當程式碼進入計劃內時,計畫成員必須能用最快的方式吸收起來,統一的閱讀格式、習慣將會對眾人有所幫助。
雖然過於強調格式統一會導致設計師有依賴,但是,最低限度的規範與要求,對團隊的合作會有很大的幫助,擅用UML也是其中一種方式。
>> 沒有資金、沒有技術、沒有計劃
其實這點,稍微不能太同意;程式設計師必須保持靈活性,這是事實,在起步階段確實如此。
問題是,完成的作品日後的發展方向與定位,如果完全依照使用者回饋來決定,那這樣的設計會隨著不斷學習而導致過適,最後成為毫無意義、毫無關聯的設計。
舉個例子來說:
如果,哈利波特的結局是依照閱讀者的期望來撰寫,那故事還能有期待性。
如果,房子當初只算蓋一樓,後來加蓋了三層,這地基還能穩固嗎?
任何軟體的初期,都源自一個特徵點,畢竟沒有這點軟體的出發就不存在。
只是使用者是善變的存在,雖然這樣的變化能符合現況,確不一定能符合軟體結構。
而軟體發展若隨使用者而決定路線,存在的危險是架構的複雜化與崩潰的危機。
雖然有計劃的建構會出現使用者不需要的設計,但毫無計畫也會出現隱藏的錯誤程式。
不過,真要討論這問題,鄙人會回到最初原則,去思考這軟體最重要的目的為何。
至少以一個設計者來說,自己的初衷與目標不應該被大量的使用者回應給掩蓋,即使這初衷和大多數人的期望背道而馳。
其次深度的軟體發展,不如廣度的軟體發展。
任何軟體都有存在的目的,如果目的達成,最好讓這階段停下,並保留可對外互動的機構。
然後針對其他功能獨立建設,並將上個軟體的對外互動與此結合。
保持兩方的獨立性,但又不牽扯過深。
換個說法,多用複合、少用繼承。
說了那麼多,其實是想說。
放空一切的隨意發展,其危險度高於長時計劃的安定性;沉著思考的長期計劃,其可變性小於隨即設計的應變性。
但是,大量的功能會失去軟體本質的特性,也失去一個作品該有的特質。
還有,長期計劃的最初設計原則是‧‧‧
“不要去思考使用者應該如何操作,而是思考使用者什麼都會做。”
以上是看完的心得,與博主分享。
@東之月
感謝你的心得分享,其實你說的我也都同意,在原本的呈現中,其實還有幾點是被我刪掉的,因為我覺得我沒有表達得很完整,像是有一點是
“向使用者說不”
這想法,就如同你提到的,如果使用者說什麼就做什麼,到最後會是很慘的,這個觀念Rework裡也有提到,針對使用者的需求做改善,當然是只限於不違背最初的目標為原則
至於軟體體的規劃與設計,我認為沒有設計是相當糟糕的事,這點我也很注重,但是我發現其實很多時候都會陷入一個常見的錯誤
“過度工程”
為了太多的未來可能性,把原本一件簡單的事情弄得很複雜,這是當設計師學會了Design pattern,和如何運用OO之後很常犯的錯,所以其實整體看來,我認為優秀的開發者要能夠懂得設計,並且知道做到什麼樣的程度是洽到好處,而不是一味地只強調低藕合、開放封閉等等
十分的中肯
要點都記下了…
希望有一天真的做了什麼出來 ^^
這篇文章真的讓人非常感動並讓人覺得啟發,也道出了所有寫軟體的人應該要遵循的事情。
不過我必須說,舊版的 now.in 跟現在的 now.in 讓我會有我得了散視的錯覺,比起筆者的部落格的賞心悅目文情並茂加上讓人點頭稱好,now.in 感覺比較像是適合用耳朵去欣賞的網頁。
@曾昱華
我個人不是學設計出身的,所以網頁設計就只能有最基本的排版,沒什麼美感我自己也很清楚,不過我們最近有找人重新設計過
http://beta.now.in
會在這兩天內取代掉原本的網頁
請問在nowin當dj一定在線上嗎?
ps 我不懂程式啦 不過文章寫的我看的懂 呵呵~
Pingback: 那些 - www 網頁熱搜“那些”
pretty good
第一段倒數第2行 感謝(感寫)