終於談到跟這個系列標題比較吻合的內容了!最後一個月上線前該做些什麼事?
在 本系列(一) ,我提到了無論如何最後一個月是測試期。這一個月又分成
close alpha 的對象是開發組以及營運組人員。也就是與核心較為相關的組別。此時針對的測試目標是這個 project 業務上應該被「實作」的 functionalty。比如說是食譜網站,就應該可以
如果是討論區,要應該可以
另外測試時要擬定使用「未登入會員」、「登入會員」、「營運權限」、「Admin 權限」各測過一次。
因為開發組成員在撰寫功能時,為了方便,幾乎都是以 admin 帳號在開發,如果不制定測試步驟和角色,很容易沒測到死角。
此時的修復重點放在 feature complete ( 或取捨 ) 以及 functionaly 是否正常運作。
請不要在此時進行任何 UI 動線調整 。
close beta 的對象是全公司所有人,公司員工的親朋好友,可以信賴的死忠會員等等…etc. 此時針對的測試目標是這個 project 的 UI 動線。
如果是討論區:
此時已經是視同準上線了(所以 Close Alpha 階段的資料會清掉),所有營運組的人必須視同營運狀態一樣運營站務,以避免正式開站遇到狀況時手忙腳亂。
(這一招是從參訪壹電視時學到的。當時壹電視快開台時有受邀去內部參訪,當時聽到他們已經內部試 run 報新聞 run 了一年時,震撼非常…XD)
此時的修復重點放在 UI 動線的調整,以及運營方針、步驟的調整,避免開站之後網站就變成死城。
我在開發階段時,最常向 RD 宣導的事情是:我不想管你這個功能怎麼寫出來,但我要你準時交出來。(但最少要符合內部寫程式規範,有辦法讀懂)
原因是:網站最重要的是 Deliver 上線。而不是站上的 feature 用了多屌的技術,用了多棒的 best practices,沒有用戶會在意這件事。而「貪玩」「遲交」會砸了一切。
直到 Open Beta 期,Optimized 這件事都不會被提到。因為在網站稍微 stable 之前,所有的 optimized 都毫無意義,做了也是白作。因為會發生效能瓶頸的地方,永遠在你設計時意想不到的地方。
如何作 Performance Tuning?
幸運的是,我的專案都是 Rails Project,有New Relic 這套軟體可以用。它可以幫你找出你的網站哪一段 Ruby Code 特別沒效率,哪一段 code 製造出來的 SQL query 特別 slow。
其他技巧請看:Rapid development with Rails P.54- P.59
這是其他題目了。有空我會再整理 update 一篇 Rails Performance Tuning 的文章。
既然已經進入 Open Beta 期了,這時候手上應該可以拿到這個網站最常造訪和效率最差的頁面。
可以使用 ab 去對網站進行壓力測試。
再決定是要 refactor slow code 或者是先上 cache 檔著先。
影響網站使用者感受最大的其實不是 backend 的效率,而是 Browser side 的效率。上線前我會
其他技巧請看:
以上說的都只是 Performance。但是這跟實際運營沒有那麼大的正關係。我擅長開發的是「內容網站」以及「社群網站」,這一類的網站重點其實是 SEO 以及社群穿透力。
比如說:這是在 T 客邦累積出來的兩套 gem。
網站的每一個頁面都會確保分享至社群網站是正常的。
靠廣告賺錢,所以要調整廣告板位
或是邮件反馈可也:
askdama[AT]googlegroups.com
订阅 substack 体验古早写作:
关注公众号, 持续获得相关各种嗯哼: