Tag Archives: 軟體工程

那些台灣軟體產業所缺少的 – 自動化測試

你是否有計算過,你在寫專案的過程中,測試過了多少次的程式? 我想是沒有,我也沒有,但是你是否有曾想過,或是感覺過,隨著專案的膨漲,你要測試的項目也跟著變多了? 這是理所當然的事情,當專案小,測試還算很輕鬆,因為程式的功能不外乎就那幾樣,一轉眼就測完了,常見的寫程式流程會像這樣 撰寫新功能 測試新功能 當然,也有修正bug的情況 修正bug 測試bug 如此一直循環,當你寫了新功能,理所當然地會去測試新功能,看是否如你預期地執行,那舊功能呢? 或許你記憶力不錯,在寫新功能的同時,想到先前某個舊功能是依賴現在改的東西,這麼一改可能會造成舊的功能出問題,於是你也順便測了一下舊的功能,當程式還小 撰寫新功能 測試新功能 測試舊功能 嘿,不怎麼樣吧? 只佔了開發時間的三分之一,好吧那如果有更多的舊功能要測呢? 撰寫新功能 測試新功能 測試舊功能 測試舊功能 測試舊功能 …. 發現了沒有? 隨著你的專案越來越大,如果要確保整個系統所有的功能都是正常運作的,無可避免地,在你修改程式之後要測試的項目會越來越多 這表示你每寫一行新程式的成本增加了,身為以減低成本為傲的島國 國民: 台灣人…,你說,簡單! 不要測舊功能不就好了? 是的,我想這可能就是最常見的情況,不要測試舊功能理所當然地,每寫一行的程式成本都保持一樣很低,但這代表著舊程式可能出錯的風險也跟著增加了,當你喜滋滋地覺得你幫公司省了成本,結果在一個月後因為舊程式缺乏測試,因改動了核心的部份造成舊的功能將所有資料外洩,公司損失慘重,這就是不重視軟體品質的後果 舉真實生活上發生過的例子,PTT曾經有過改程式未經好好地測試,造成每個人都能以管理員的權限登入的事情,知名的檔案同步平台Dropbox,也曾經發生過因為認證的程式改版有bug,造成任何人都可以登入別人帳號的事,我也有曾聽聞一些網站因為工程師為了測試方便,把認證的函數暫時改成 function authenticate(user_id, password) { return true; // do authentication here // … Continue reading

Posted in 中文文章, 分享, 嘴砲, 資訊安全 | Tagged , , , , , , | 5 Comments

那些台灣軟體產業所缺少的 – 版本控制系統

這幾年來,多多少少接觸了不少業界的人,雖然我自己還不算有真正待過業界太久,但是這期間看到不少業界的現象都令我挺驚訝的,例如在聊天時提到你們公司用的版本控制系統是什麼,有很多人都會回答 「那是什麼?」,一直以來這些在國外的主流開發環境都基本常識或是標準配備的東西台灣業界居然很多都連有那樣的工具存在都不知道,或著是對於某些東西有錯誤的認知,所以我想大略提一下常見的幾個問題 版本控制系統 我想這是最常見的毛病,很常發現很多公司在開發軟體時從來都不使用版本控制系統,最誇張的狀況就是管它三七二十一直接修改   除此之外,常見的土法鍊鋼有聽說過資料夾複製,然後將資料夾名稱命名為版本1之類的方法,高級一點還有搭配Excel來記錄改過了什麼之類的 更進階的還有多人共同開發,還架了FTP來放這些檔案 但這些都有很大的問題,而且其會遇到的問題都正好是版本控制系統所要解決的,所以到底是什麼樣的問題非用版本控制系統不可? 首先,用資料夾copy有個很大的問題,一來是copy的過程很容易出錯,而且更糟的是出的錯很難發現,你怎麼從資料夾的內容來判斷這到底是哪個版本? 最常見的做法就是回想你到底在哪個版本改了什麼,然後去看對應的位置,是否有那些改動,但你有可能記得嗎? 要是程式不是你改的呢? 因此依賴資料夾名稱來得知檔案的版本是極度不可靠的做法,再者,如果你不幸改到錯誤的版本,辛辛苦苦改了半天,才發現改到舊版本了,那你要如何把你改的和正確的版本合在一起? 如果你只改了三行,這還好辦,但如果你改了三百行,那該怎麼辦? 用Excel來記錄改動的事項和版本一樣不會有幫助 那多人開發使用FTP來分享檔案呢? 老天,事情更慘了,原先只是你自己的開發,自己改錯了就算了,如今變成多人開發,有時出問題還不是你改的,這樣想好了,FTP上有個檔案 hello.py 今天張三載回去改了,變成 hello.py (張三版) 不幸的是,王五在張三上傳回FTP之前,也載回來改,變成 hello.py (王五版) 接著,張三把它的檔案上傳了,所以FTP上的檔案變成了 hello.py (張三版) 然後好戲發生了,王五也把它改的東西上傳了,所以FTP上的檔案被蓋掉,變成 hello.py (王五版) 發生了什麼事? 張三改的版本被蓋掉了,你可以想見張三在demo給老闆看時發現改的地方被蓋掉了,翻過辦公桌衝過去揍王五的情景了嗎? 像這樣還只是最簡單的情境,以這類土法鍊鋼的方式,還有太多太多預料不到的複雜情況會發生,什麼? 那你說,如果我們規定每人都得把資料夾以自己的名稱命名,加上版號,再上傳,這樣就不會錯了吧? hello_project-王五-rev123/ 拜託,何苦呢 ? 版本控制系統就是用來解決這些問題而開發出來的,學一套新工具有這麼難嗎? 常見的理由可能會有什麼沒時間學、不信任工具等等,事實上那些都不是理由,只要是程式碼的開發,都得使用版本控制系統,現在已經是2011年,如果你的軟體開發沒有使用版本控制系統,我說這不叫落後,這是原始 用了版本控制系統,最重要的好處是 你可以安心地放膽去改程式 … Continue reading

Posted in 中文文章, 分享, 嘴砲 | Tagged , , , | 9 Comments

那些在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