Monthly Archives: July 2011

那些在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, … Continue reading

Posted in 中文文章 | Tagged , , , , | 26 Comments

技術應為服務而生

在前面的一系列文章裡,我發現有些人有些很有趣的想法,有些人覺得使用Windows是很落後的事,或是要用vim、gcc、gdb來寫程式才顯得有技術,我自己也是從小玩技術長大的人,事實上我很能理解這樣的想法,或著說我以前也是這樣的想法,但後來漸漸地想法就改變了 在大學時有位組合語言很強的傳說中的教授,他的組合語言課真的很令人印相深刻,他從來不帶課本,一上台就開始畫圖,然後用很粗俗易懂的例子講解,可以看得出他對低階的這塊領域實力有多深厚,有一次他在上課談到 我以前在做賭博電玩時,有人來跟我推銷繪圖晶片,可是我跟他說,不用,我覺得自己寫一個pixel一個pixel畫才有技術 可是後來發現別人用繪圖晶片來畫圖,一下子就做出來了,我還在刻低階的繪圖功能 後來因為這樣做不過別人就不做了 聽了之後仔細想想我自己也是這樣的想法,以前在寫遊戲時最初是用Direct Draw,後來覺得使用現成的函式庫沒什麼技術,在之後重寫的版本中,就自己寫畫圖的函式庫,一個pixel一個pixel去填,半透明混色也是自己去算,甚至想自己寫3D的繪圖引擎,雖然確實在這過程中學到很多東西,但事實上整個寫遊戲的過程中有好一大半的時間是花在底層的這些基礎繪圖功能上,後來漸漸理解,重覆利用別人做好的輪子是很重要的事,只因為覺得 “那樣才叫有技術” 而去自己做別人已經做好的東西是很不成熟的想法,後來我終於理解到 技術只不過是在工程中完成目標的手段,並不是最終的目的 除了技術以外,事實上在整個軟體的工程當中,還有太多值得注意的事,從你學習那項技術需要花多少心力,技術相關的社群,如果你是商業公司還得考慮到有沒有支援商業服務,還有你用這項技術的話能不能找到人來接替你的位置? 你用了這項技術生產力有因此而提升嗎? 以先前提到的例子,用gcc直接下指令編譯,用gdb下指令除錯,你的生產力有因此而提升嗎? 為了從一般的IDE環境下切換到這樣的環境需要多少的學習成本? 如果你找一個人來接續你的工作,他是否有辦法像你一樣熟練地使用這些工具? 如果你要教新來的人熟悉你的環境,你需要花多少時間? 我相信,大部份提到要使用這些工具的人都沒想過這些問題,這很正常,因為他們熱愛技術,但是實際的工程應用這些都會是很重要的問題。 人適應工具 而在這些提到的一些工具中,有個很極端例子,那就是vi/vim,我自己有用vim,因為打大量程式會比較有效率,或在Linux下改程式都得用到,為什麼說vim是很極端的例子,因為它的設技概念與我們一般常見的IDE是相反的,一般的工具都是設計工具來適應人,然而vim卻是設計工具要人去適應它,因為如果需要打大量的字,手一直保持在鍵盤上是最有效率的,所以它設計讓你手都不用離開鍵盤,就能進行所有的操作 Vim cheat sheet 來自 http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html 當然,缺點是它的學習曲線很陡,在一開始你可能打幾個字都會弄得灰頭土臉,身為技術人員如果你覺得打大量的字是很常有的事,這投資是值得的話,學一學vim確實是不錯,但推薦初學者學vim就不是什麼好事 所以,當你很興奮地覺得這個東西才算有技術,或著是開源萬歲之類的理由,推薦給別人時,想想你自己花多少時間學這東西,別人又能因此得到什麼好處好嗎? 而當你開始設計產品時,你想想如果Apple的Macbook廣告詞是 經過三個月的練習,使用我們的系統工作效率提升了50%!! 你覺得還會有人買這樣的產品嗎? 工具適應人 另一種設計的想法,也是主流的設計思維就是讓工具去適應人,大多數你能在市面上看到的產品都是這樣的設計,我們舉一些例子,Visual Studio最近推出了一種新的UI,叫Debugger Canvas,是將整個debugging trace的過程以泡泡視窗的方式串聯在一起,讓你可以很直覺地理解程式呼叫的過程 [yframe url=’http://www.youtube.com/watch?v=3p9XUwIlhJg’] 有這樣視覺化的輔助,除錯的過程會輕鬆許多,在有現代化工具可用的情況下,除了學習以外的炫技理由堅持使用原始的工具,就只是浪費寶貴的開發時間而已 再舉另一個例子,就是git或mercurial在送commit之前,我個人都會對送出的內容review一次,以免將測試用的程式也送進去,例如像是這樣糟糕的例子 def auth(user_id, password): # … Continue reading

Posted in 中文文章, 嘴砲 | Tagged , , | 16 Comments

常見的Linux暴炸原因

今天看大家在搶COSCUP報名,報名頁面一如往年掛掉了,以我自己的經驗看來這樣等級的流量樣打掛Nginx應該還有很大的距離,我自己處理過Now.in在運行中遇過無數各種奇奇怪怪的問題,所以很多常見的Linux暴炸原因都見怪不怪了,對於上千等級連線的伺服器這些是很常遇到的事,如果沒有弄好的話很容易就整個Linux卡住或炸掉,以下介紹一些我所知道Linux會被塞暴的主要原因,都是參數沒設好為主 最大檔案數沒設好 我想這是最多常犯的錯,當然我也犯過,linux預設每個user可以開1024個檔案,嚴格來說是file descriptor,當然socket也算在內,如果這個數字沒有調的話,就算你的Nginx或是什麼鬼伺服器再怎麼威猛,1024這麼少的數字,稍微大一點的流量,都一樣是被塞暴的下場,因為執行伺服器的使用者開不出新的檔案、socket來,而這個問題最常遇到是因為一般情況下你的網站連線數量要達1024不是每天都會發生的,可能發生一下子就沒了,等到哪天真正大流量來時才會發現整個網站暴炸了,但是1024個以上的同時連線數對於目前的now.in伺服器來說隨時都在發生的,所以如果我有哪台伺服器忘記設,很快的就會炸掉 至於要怎樣提高檔案數限制,請參考 Linux Increase The Maximum Number Of Open Files / File Descriptors (FD) ip_conntrack已滿,丟失封包 另一個常見被塞暴的是ip_conntrack,是iptables用來追蹤連線用的表,如果滿起來的話,新進來的封包會被丟掉,你可以在/var/log/message裡看見 Jul 15 19:22:30 hostname kernel: ip_conntrack: table full, dropping packet 這樣的訊息,可以透過修改最大值來解決,參考Linux Iptables ip_conntrack: table full, dropping packet error and solution 或是重開iptables service也可以洗掉目前的table … Continue reading

Posted in Linux, 中文文章 | Tagged , , , , | 3 Comments

你沒遇過的編譯器鬼打牆,許功蓋問題

我想在前面的文章裡很多人可能都沒遇過所謂的鬼打牆,大學四年中我遇到最多鬼打牆的狀況全是Dev C++引起的,其實如果都一一記下來應該是個很長的列表,只是問題解決通常我自己也忘記了,其中一個我印相最深刻的鬼打牆問題不是由Dev C++引起的,而是Visual C++ 6.0引起的,程式碼大略像這樣 class SocketHandler { // 此函數會被呼叫以通知連線成功 void onConnectionSuccess(); }; void SocketHandler::onConnectionSuccess() { // some code here } 這是我自己寫的一個socket連線程式,不管怎麼試,編譯器總會跟我抱怨它不認識onConnectionSuccess這個函數,從表面上看起來程式也沒有任何問題,所以問題到底出在哪裡? 答案是許功蓋問題,看到了嗎? 註解的最後一個字是”功”,而我們知道”功”在 big5 其中最後一個字元是 “/”,且VC6不懂得unicode,它會以ASCII的方式來處理程式碼,所以程式碼就變成 // 此函數會被呼叫以通知連線成 void onConnectionSuccess(); 如此一來,註解就被延伸到了下一行,onConnectionSuccess的宣告就因為這樣被忽視掉了,為了找到這個問題,我重讀了好多次程式碼,都找不到任何缺陷,一整天的時間就花在這個上面 這個故事告訴我們什麼? 從此之後我就強迫自己改用英文寫註解,我想沒有多少人有機會遇到這問題,而誰也想不到註解也會造成程式的編譯問題,這個故事告訴我們,工具的好壞遠比你想像重要,不要以為這種缺陷沒什麼,事實上是那些缺陷可以讓你debug一整天都找不到原因,除了你的工作時間浪費了,學習的時間更是浪費在其中,更慘的是還帶來了嚴重的挫折感,再一次,工欲善其事,必先利其器,學習更是如此

Posted in C/C++, 中文文章 | 5 Comments