The Art of Readable Code && High Performance Comments

我常常覺得,網站之於規劃,就像漫畫之於設定。

良好的規劃能讓網站定位明確,簡化開發流程。網站規劃並沒有特定的方式,其深度、廣度、排程、形式也因團隊風格有著高度的分歧;舉例來說,最近某公司在搞的 Agile Software Development 也只是把每次規劃的深度/廣度相較於傳統 (Pitfall) 開發縮短,來達成定期交付可見成果 (end product) 而已。

當然,有些神人號稱他寫程式不需要做任何規劃,但那多半是因為他們已經將關鍵項目倒背如流牢記心中,光用舔的就知道弱點;剩下的有一半是因為被逼著趕工(這種公司遲早會被維護成本拖垮),還一半則是正努力用維護成本拖垮公司。

一份良好的網站規劃,我認為至少應該包含下列資訊 (形式隨意):

  • SA 部份
    • 資源限制
      • 人力
      • 開發時間
      • 硬體
      • 軟體
    • 使用情境
      Functional Specification, Scenerio, Use Case 都可以包含這部份的內容
    • 運作流程
      • 資料流
      • 操作動線
    • 實做功能要求與清單 (如果需要交付驗收)
  • SD 部份
    • 開發框架
      • 必備
        • 源碼管理系統
        • Issue Tracking System
        • 自動文件產生/管理
      • 建議
        • 自動建置
        • 自動測試
        • 開發工具
    • Coding Standards
    • 介面定義
    • 物件架構 (繼承、功能區隔、實做分層)
    • 頁面列表
    • 實做功能/物件功能/頁面 對照表 (如果需要交付驗收)

底下是這個點名網站的部份規劃:

  • LAMP ,掛在我的 Amazon 機器上
  • 一人開發,預定一個月內完成(刻 blog 花的時間大概是開發的 5-10 倍 T_T)
  • 估計使用者人數:40 人,每人每週瀏覽不超過 10 次 !
  • Functional Spec :
    • 使用者登入這套系統以後,會依權限等級分成三類:管理者、團隊領導、成員,進行不同操作。
      • 成員可以設定自身所有的遊戲角色,檢視目前公開的活動,並設定自身與角色對這些活動的出席狀態
      • 團隊領導可以建立/修改/刪除 活動、檢視/修改活動報名狀態
      • 團隊領導可以做到成員能做的事
      • 管理者可以設定使用者的權限等級
      • 管理者可以做到團隊領導能做的事
    • 資料定義與關聯
      • 使用者可以持有多個「角色」,每個角色對應至魔獸裡的一個角色
      • 角色
        • 紀錄其職業、裝備等級、熟練天賦、能執行的定位(坦、補、輸出)
      • 活動
        • 可以包含多個時段,並以其聯集作為活動的時間
        • 當有多個時段時,全部能出席者,視同能出席該活動;全部缺席者視同缺席,其他設定為部份出席
        • 能見度可設定為開放(所有人可檢視、報名)封閉(所有人可檢視,特定使用者能報名)與秘密(特定使用者能檢視、報名)
        • 使用者能根據時段,填入出席、缺席、部份出席,並加入註記。註記只能新增,不能修改;紀錄發言者與發送時間。
        • 某時段開始之後,使用者就不能改變該時段的出席狀態,但團隊領導可以
      • 名單
        • 為了簡化輸入,在團隊領導編輯活動成員時,能以「名單」方式快速引入一群使用者
        • 預設名單:所有人、沒有人、團隊領導、某次(可點選) 活動/時段參加(出席/缺席/晚到)名單
  • 實做要項
    • 物件導向開發,底層 ORM 使用 Doctrine 2
    • 開發工具為 NetBeans/PHP,並以 svn 管理原始碼,在 source tree 裡處理 issue
    • 使用 phpDocumentor 註解並產生文件
    • 若時間許可,試驗 MVCP 四層架構;否則直接 MC 搞定
    • 物件內容、實做、文件參考源碼 (這叫 規格書的委派!真的做專案不可以這樣喔)

發表迴響

分類

%d 位部落客按了讚: