on
[rust] zero2prod 實做紀錄 02 - User Story
這本書特別的地方是並沒有一開始就進入寫code的階段，第二章花了一些時間在講"開發"這件事。我的第一份工作是工廠裡的產線工程師，轉職軟體工程師後，有幸第一份工作接觸到了敏捷開發，跟著公司的週期跑的過程鮮少有時間想為什麼要這樣。這本書在第二章簡單的講了一下軟體開發流程，在工作一小段時間後再看覺得或多或少有一些理解。這篇文章不打算直接進入寫code，反而我想花一點時間再看一次這一章。
##從問題中學習
Choose a problem you want to solve. Let the problem drive the introduction of new concepts and techniques.
其實不管什麼事情都是要想辦法解決問題，並且透過這些問題會讓人學習到一些新的東西，但不知道為什麼在軟體業比較願意去討論或接受這件事情。會需要開發軟體一定是為了解決某些問題，而我們希望這些問題可以：
- 足夠小，不會複雜到難以解決
- 足夠複雜，讓各個層面可以組織成完整的系統
- 要有趣，才有動力去完成它
這幾個要點蠻基本的，但是工作一陣子後卻也很容易忘記，尤其是最後一點，當把工作視為一個例行公事後，真的很容易忘記"有趣"驅動自己想要達成某些事情的感覺。
##User Story 敏捷開發中常常會提到User Story，書中把User Story整理成某種固定的格式
As a …, 身為什麼身份 I want to …, 我想做什麼事 So that … 來達成什麼目的
以這本書想要做的部落格文章通知系統，就可以整理成
我是一個部落格作者 我想要寄信給我的讀者 讓他們知道我寫了新的文章
整理成這樣的格式，目的就是要讓開發人員容易對焦一個目標，不會想要開發通知系統結果跑去做文章編輯器？ 那麼有了第一個目標後，就要來拆解我們需要達成的事情，仔細看這個簡單的story，研究之後可能會多了很多問題，比如說是否要支援多國語言，或者寄信的內容要是樣板還是使用者可以自行定義，信件要支援HTML或者是純文字....，我們可以拆出很多的小task來完成整個story，接下來就進入這章最大的重點了 ####這麼多Task做完都不知道多久以後，當全部完成後搞不好根本沒有人要用你的產品 我們可以把每個環節作到極致，得到一個完美的系統，但不符合市場需求，或者我們可以提供最基礎的功能，再接下來每一次的迭代中一步步優化或是加入缺乏的功能，這就是敏捷的精神。聽起來很美好，但在往下讀後發現與其說要達成不簡單，或者作者心目中符合快速迭代的作法跟我想像中的非常不一樣。
Instead of going deep on one story, we will try to build enough functionality to satisfy, to an extent, the requirements of all of our stories in our first release. We will then go back and improve: add fault-tolerance and retries for email delivery, add a confirmation email for new subscribers, etc.
為了達成足夠的功能性，需要有策略的對任務優先度排序，讓系統可以容錯並且容易擴充，則要用到各種技術手段。敏捷並不只是注重速度，在後面的章節可以體會到要透過足夠流暢的開發，同時以測試之類的技術維持系統的穩健，像是作者會先寫整合或單元測試再補足產品程式碼，因為產品程式碼成行的過程中早就經過無數次的測試，甚至比我憑空想像補足程式碼，再靠IDE的Debug工具慢慢試錯來的有效率。 下一篇文章就要開始進入開發了，不知道進度會被拖的多慢，我預計把書中運用到的套件版本更新到最新，這中間也會遇到一些坑(像是有遇到套件引用的sqlx跟我安裝的cli工具版本不同導致離線模式build不過，CI整個死去)，希望不要半途而廢了。
註：SQLX是rust眾多資料庫連線套件之一，可以在編譯時期檢查SQL語法是否錯誤，但有時候編譯是不能連線資料庫確認的，就要開啟離線模式，SQLX有提供cli工具生成離線模式所需的文檔。