一個傻逼的部落格

        寫一個真的會有很多使用者在用並且會給你很多 feedback 的程式真的太有趣了。因為這支『 砸爛我手機 』本來就是一個白爛的惡搞作品，所以不管回應是好是壞，看得都津津有味，回味無窮。         本來打算一週出產一個白爛作品，沒想到第二個作品就卡在美工難產而跟著懈怠。如今第一個作品從 2010 / 11 / 28 日上架後也差不多經過整整一個月，來記錄一下截至目前為止的成績分享一下。         一個月來，這支小程式累積了將近三萬五千下載人次，安裝後未被移除的存活率約為 46% 不到一半，這已經遠遠高於我的預估了，因為我原本認為大家玩沒兩下就會移除它，畢竟這是個毫無實際用途的程式，沒想到竟然還可以每兩個人就有一人保存著！

        公司的專案最近開始產生無法壓制 bug 的成長速度攀升的困擾，終於，單元測試這件事開始被大家注意。事實上，單元測試的實行是需要許多開發技巧的搭配才能實施地有效果，而不是單純地會使用 Assert 而已。只知道 unit-testing 要使用 Assert ，往往會以為這對真實世界的專案開發沒有幫助而捨棄。         甚至有許多人認為單員測試不可能做到，或是認為這是浪費時間的事情，大部分的程序員抱持著這樣的觀念，讓人感到非常惋惜。

         最近，因為公司替即將上線的系統做壓力測試引發出許多問題，促使我開始重新思考一些開發流程的疑問： 先 SIT，UAT然後才進行壓力測試真的是正確的測試標準流程嗎？          會開始有這樣的疑問，在於壓力測試若沒有過關，若要解決關鍵的效能問題，有時候會導致更改低層設計的 re-design 發生，而偏偏測試走到這階段，正是系統即將上線前的 deadline，底層的重構 ( 尤其改資料庫結構 ) 常常動一髮牽全身，之前的功能測試的保證等於失效，想準時上線根本沒機會重測。在沒人敢擔下上線日期跳票的責任下，一個沒有 well-testing 的系統就這麼被推上火線對外營運了。

        自從我替自己的工作室建置整合了 SVN + Hudson + NANT 的 build server solution ，開始享受這甜美的果實，為了讓整體發揮最大功效，上個月我把原本使用 WindowsXP Pro 的伺服器重灌成 Windows 2003 Ent，沒想到從此我的專案建置開始變得愁雲滿天！

        最近幾週，公司在進行即將上線的系統的壓力測試。而故事發展往往是這樣的，平日跑起來沒甚麼異狀的系統，平平安安度過 UAT 與 SIT，然而壓力一來，各種匪夷所思難以解釋的現象開始一一浮現...。         這次就有個詭異到不行的莫名現象搞得我差點走投無路準備燒香拜拜，花了一週的時間終於在靈光一閃的狀況下背我看破端倪。

        最近公司在為了即將上線的產品進行壓力測試，產品內有個結帳功能是同事 A 先生的得意代表作，結帳功能在 A 先生信誓旦旦拍胸脯保證三百萬筆資料秒殺的信心下，平行作業卻發生了 Deadlock。