# 開發日程


## 詳細說明

* [10.06 Sprint #1](/Fpm-TogMRvK9_AUhE3_fNg)
* [10.11 Sprint #2](/efgP39JxSj2evONa4NBtmg)
* [10.14 Sprint #3](/QFO8QB89Tqm180LIpBlU0Q)
* [10.17 提交指定功能](/EeKJKML3QlKpZR41TIDsYw)

:::warning
**DoD 中規定至少要有一次 demo**
(可能在 Sprint #2 & Sprint #3 進行 2 次 demo)

:::spoiler 如何進行 demo？

**Demo (review) day 建議流程**

在每次 sprint 結束前設定 demo day，也就是 review 這次 sprint 進度的日子。

在 demo day 中，需要：

1. 確認目前已完成 features 與尚未完成的 features
* 使用小組的 task list 來確認
* 尚未完成的 features 通常指放在 backlog 裡的 tickets

1. 演示正向流程 注意 demo 不是 acceptence criteria 驗收，「正向流程」指的是：
* 依照 user story 選定一條單一角色 (user or admin) 能從頭到尾跑完的過程 (指不需要reset user或資料)
* 規劃 demo 流程時，考量重點是「能夠呈現出目前已完成功能的最大價值/特色」
* demo 過程要盡量簡短，在最短的流程內呈現最大的價值
* 一邊示演產品的操作，一邊口頭說明產品內涵與特色
1. **若在 demo 中出現 block 的地方，需說明可能預期的解決方式**
1. 確認了 task list 進度，並完成 demo 瞭解產品體驗後，小組共同討論：
* 到下一個 sprint check 要做的事情
* 列出要變動的需求 (可能因時程需要縮減或者改動)，也就是針對 backlog 的項目一起進行 refinement。

**誰來 demo？**
* 通常是由開發者根據自己負責到的功能，規劃一個正向流程，輪流進行 demo。
* 若採用前後分離的開發模式，通常由前端進行 demo（前端很累辛苦了）

**用什麼版本 demo？**
* 為了能早早發現「本地都沒問題，上線後就有問題」的神秘 blocking
* 在 demo 時盡可能使用 production 環境
* 若是開發中途的 sprint checkin（例如 Sprint #2)，有可能仍使用 local 環境 demo，但上線前的 Sprint #3 應使用 production 環境來 demo。

### DoD 中覆核 demo day 的方法
在 DoD 中有指定一條「小組共同 demo 完整正向流程」，基於教學的立場，AC 會逐條覆核小組有沒有確認達成 DoD。

我們會透過「會議紀錄」來覆核小組是否有進行至少一次的 demo，請小組記得指派紀錄人員。

會議紀錄應包括：
* demo day 日期
* 到場名單
* demo 流程紀錄
* 由誰負責 demo 了什麼內容
* 是否發生 block，什麼原因？預期如何解決？
* 其他討論紀錄

:::

<!-- 10.21 Twitter 結業～求職順利～撒花 🌸 -->

## 前後分離開發模式

### 前端

:::info

**技術層面**

* 前端框架 Vue 深度應用（例如：Vue router、Vuex）
* 多頁面切版
* 預處理器在實際開發的應用（例如：SCSS）
* class 命名規範（例如：BEM）怎麼加快開發速度
* 非同步串接後端 API，針對回傳的 status 做不同處理
* 前端驗證：像是錯誤處理的訊息提示，或是使用者輸入了不符期待的資料時，* 如果處理完再傳送給後端

**專案專注點**

* 畫面精美度：是否 100% 還原設計稿，及新增使用者互動細節（例如：hover 效果、按鈕禁用效果）
* 前端框架的使用：是否正確及妥善使用 vue 指令、功能來完成專案
* 使用者體驗：包括錯誤通知、提示通知，以及網站動線等設計
* 網頁效能：網頁操作的流暢度、資料載入速度等
:::

### 後端
:::info
**技術層面**

* API 文件撰寫
* 設計 API 提供的資料內容，包括 API 設計的可讀性（RESTful API設計風格）
* 了解如何處理 CORS
* 熟練版控工具（Git）進行離線溝通及線上即時溝通
* 資料庫設計（table、column、關聯性、哪些要加密或雜湊）
* 資料庫 query 撈資料的效能考量
* 後端驗證：例如前端送來的資料驗證、使用者認證等

**專案專注點**

* 以通過測試為第一優先
* code 的可讀性（輸入的參數有沒有包裝、邏輯是否易懂）
* 程式碼是否有系統性的整理（例如：使用 MVC 架構，把同性質的 code 另外包裝）
* 資料庫撈資料的效能（例如：打太多次 API、沒有善用 join、各個 table 的 column 關聯設計不良、有沒有正規化等等 ）
* 後端驗證：使用者認證是否能運行，及是否有對前端送來的資料進行驗證
:::

\
[回到首頁](https://hackmd.io/@2022-Oct-Twitter/Hk9m-Pn-j/%2Feax7gnB7R3KcclDqf27iDA%3Fview)