Rails  炸機實務
Upcoming SlideShare
Loading in...5
×
 

Rails 炸機實務

on

  • 2,303 views

 

Statistics

Views

Total Views
2,303
Views on SlideShare
2,302
Embed Views
1

Actions

Likes
3
Downloads
30
Comments
0

1 Embed 1

http://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Rails  炸機實務 Rails 炸機實務 Presentation Transcript

  • Rails 炸機實務 如何不要炸爛你家機器 和你老闆的臉
  • About Me
      • Manic Chuang
        • http://tech.manic.tw
        • http://www.manic.tw
      • PIXNET (2008~), PHP Programer
      • Half Rails Developer since 2009
      • PIXNET Rails Team in 2011, April
  • 前言
      • 這是在講測試的, 只是順便講怎麼炸掉你家網站
      • 在現有專案導入測試碼撰寫
      • 使用 Rspec
      • 使用真實範例
      • 演講者自己也是新手
      • 適合聽眾 :
        • 沒寫過測試但有興趣的人
        • 想了解測試但不知道如何下手的人
        • 想看看別人怎麼炸他們家專案的人
  • 關於本章要提到的測試 指的是自動化測試
  • 為什麼我要寫測試 ?
  • 可不可以不要寫測試 ? 要如何避免炸機 ?
  • 星期五的時候不要 Deploy Code 腦袋通常都不太清楚
  • 網站炸掉了 星期一 deploy code 後炸掉了
  • 進化 : 星期五的時候不要 Commit Code 那可不可以也不用來上班 ?
  • 一旦釋出程式碼, 可能的話不要動他 Code freeze if possible 通常是不太可能
  • 不得不動它的時候 還是不小心炸掉了  
  • 寫的時候請小心謹慎 正式的行政命令
  • 檢查程式碼有沒有錯誤 開發端要自己跑一次 開瀏覽器看看有沒有問題 在你每一次更改時 重覆以上事項
  • 還是炸掉網站了 錯誤是在別的環節, 因為這次的修改引發
  •  
  • 在你每一次更改時 重覆以上事項 注意這個重覆
  • DRY D on't R epeat Y ourself 為什麼要堅持不寫測試啊 ?
  • 每件事都有它的代價 一個開發所需時數約 10 小時, 上線 1 個月的活動網站 一個開發所需時數超過 100 小時 上線已經超過 2 年的專案 且持續有調整與新功能的社群網
  • 實際範例 : PIXNET 化妝台
      • 暱稱 Pixlovely
      • http://channel.pixnet.net/lovely
      • 歷經三版本
        • PHP 時代 : http://channel.pixnet.net/lovely  
          • ??? ~ 2009.07
        • Rails 2.3.4 版本 http://belovely.tw  
          • 2009.07 ~ 2011.06
        • Rails 3 版本 http://channel.pixnet.net/lovely
          • 2011.06 ~ 
          • 2011.07 開始寫 ( 補 ) 測 
  • 在 2011 年 3 月開始開發 在 5 月 ~6 月時連續發生慘案
  • 慘案發生原因 : 規格
      • PM 是產品部門,企畫的是美妝部, 開發的是技術部
        • PM 並非技術出身
        • 規格時沒考慮到一些例外狀況處理
        • 溝通不統一
        • 開發端發現規格有問題, 與企畫討論後修改了規格。 但是 PM 端不知道這件事
  • 慘案發生原因 : 時程
      • 2011 年 3 月第一個程式碼提交, 6 月要上線
      • 5 月加入開發,此時進度約 50%
      • 只檢測功能正不正常,不管程式碼品質
        • 上線後再回來修
        • 長輩名言 : 拋掉羞恥心程式就可以寫很快了
        • 結果來回的次數變多
      • 驗收功能的是 PM 部,他站在你後面而且很火
  • 慘案發生原因 : 外部網站介接
      • Session 與 PIXNET 本家 (PHP) 共用
      • 使用 PIXNET 相簿作圖床 (Oauth API)
      • 使用 PIXNET 的 Solr 作為 Search Engine
      • 開發與檢測驗收都很費功夫
  • 決定補測試
  • 事前準備
      • 選擇並學會使用你的 Test Framework
        • 在此使用   RSpec Rails
        • 清單
          •   http://ihower.tw/rails3/testing.html
          •   http://www.slideshare.net/ihower/rspec-7394497
          •   http://pragprog.com/book/achbd/the-rspec-book
  • 事前準備
      • 整理並確認專案規格
        • 企畫端寫 User Story
        • 規格必須由開發單位撰寫,由企畫端驗收。
        • PM 由技術部成員擔任
        • 測試就是一種程式規格, 程式的規格就是滿足測試條件。
  • Rspec-Rails
      • 和 Rails 一樣依照 MVC 架構分別有 Model, View, Controller 
      • Integration Test: Request specs
      • 其他 : Route specs, Helper specs
  •  
  •  
  • 進一步整理
      • 未登入前會看到登入資訊
      • 登入後會看到自己的暱稱 (PIXNET) 與三個管理連結
      • 登入後如果有未回覆的玩試用 ( 問卷 ) 會顯示通知
  • 因為是事後補測試
    • layouts/application.html.erb
    針對對應的程式碼來寫測試
  • 寫出相對應的測試碼
    • spec/views/layouts/application.html.erb_spec.rb
  • Failed
  • 錯誤的部分與測試內容沒關係 那不重要 !
  • Fake It! ( 作假資料與假回傳 )
  •   測試絕大部分花費的時間 是在處理這些假回傳 以及準備需要的假資料
  •  
  •  
  • 範例 : 錯誤的測試
  • 測試碼不能檢查到 程式碼的錯誤 那就是沒有用的測試
  • 補寫測試的流程
      • 補寫 Spec Code 使測試成功
      • 確認如果更動 Spec code 會使測試失敗
      • 確認如果更動被測試的 code 會使測試失敗 
  • 好處
      • 可以在不怕炸機的狀況下 Refactor 程式碼
      • 重新確認規格與程式碼是否符合
  • 注意事項
      • 專注於被測試的項目,讓其他部分用 假資料 (Fixture) 與假回傳 (Mock & Stub) 來處理
      • 確保你的測試可以有用: 試著”故意”寫錯程式碼讓測試失敗, 藉此練習想像各種的錯誤情況,以提早預防
      • 當局者迷,可以找另一個人幫你 Review 或 Pair Programing
  • 測試不是萬靈丹
      • 不用追求最完美,只要能不炸機就好
      • 人工測試也有其優點
  • Q&A