昨天，我們創造出了一個響應時間為 1 m 19.44 s 的後端 API，今天，我們一起看看，當 PG 將問題回報給 Product Owner 後，將如何優化與處置。

問題分析

昨日有提到，檔案大小與掃描點數直接影響了程式的響應時間，若再深入探討的話，K-means 在三維座標中的隨機起始座標，也有可能會影響迭代的次數。過多的點數分群計算，也可能導致 JVM OutOfMemoryError 發生，這時，我們可以一同測試與審視掃描的點數與響應時間的關係，還有它對最終 Output 的影響。

這裡以一張解析度為 300 萬像素 (1536*2048) 的照片為例，在分群皆為 5 的情況下，逐一增加 x, y 軸掃描點位的間距 (i = i + n)

轉換 X 軸為掃描點數，Y 軸為響應時間:

從圖表可以發現，響應時間隨著掃描的點數成指數性的下降，然而，比較掃滿 300 萬個點與三萬個點去計算的顏色分群結果，事實上在中心的偏差並不高 (上排為 300 萬的結果，下排則為 3 萬)。

到此，我們可以暫時下定決策，藉由判斷照片解析度的大小，來調整 x, y 軸的間距，後續還需要測試在不同解析度下，x 與 y 軸的最適間距。

關於測試驗證與回報

測試可能會遲到，但絕對不會缺席

開發過程中若你不測我不測，到最後就會交由用戶來幫忙測，如果一不小心測出問題，若本身是甲方，那麼你的 PM 會撕裂你，若是乙方，則你的違約金會受難。在開發的過程遇到問題及時向團隊反映，並讓團隊能夠提前準備，迅速做出決策，正是敏捷的精神；反之若 PG 在發現問題後抱持著 "反正前端再壓縮就好了"、或 "這就讓後面去煩惱吧" 的心態，則有可能造成後續開發上的困難。

我們在Day3: 淺談敏捷開發 的時候有提到:

在敏捷開發的過程中，常會先規劃大概的方向，並逐步讓規格的顆粒度由粗轉細；經 UXR 研究與 SA 訪談後，先建立顆粒度較粗的規格交由 SD/PG 試做

針對核心需要驗證的內容，ColorCodeTag 其實是先實踐核心方法 (如 K-means) 並執行測試，快速驗證問題與可行性後，再投入其他方法的開發。另外本次單元測試先針對 K-means 方法撰寫 Unit test，則不特別說明。

Review & Sprint 3 !

製作可接收照片，並回傳一組色碼的 API，並以 Postman 測試 Response

這期的 Sprint 完成了後端的開發，並且成功的將照片的顏色進行分群，獲取出五個具代表性的顏色，同時，我們也新增了要確認解析度與間距比例的代辦事項。

第三期的 Sprint 我們將要完成前端 Angular 的程式撰寫，並且由前端向後端發送請求，將接收到的色碼轉換為顏色方塊。

今日結語

這次的 Sprint 完成了後端的開發，同時對發現的問題設定策略；在開發的過程中，PG 們所撰寫的程式，都會影響產品最終的效能、以及好不好維護，也因此才會有許多 Design Pattern、Clean Code、以及 Jvm 等知識，等待著我們不斷的精進自己。

明天，我們將開始前端的開發，並恭喜各位度過這個 Blue Monday。