我們上週花了一些篇幅介紹一些「寫程式」的內容，實際上我並沒有花很多時間在這些內容上，因為並不存在「怎麼寫才是 FID」的問題，而是「怎麼寫才是好的程式」的問題。這個問題的答案是：「寫出來的程式可以被人看懂，並且可以被人維護」。

包括常見的 SOLID，clean code，functional programming，DDD，這些都會是使用到的技巧，但是這些技巧都是為了「讓程式碼更好讀」而存在的。

怎麼使用其實並沒有限制，反而我是在思考，竟然大家一開始都是用了自己認為最好的方式來寫，但為何最終大家都無法寫出稱心的程式碼呢？又或者執行專案的時候，需求和程式碼的差距為何會如此大呢？

於是我才漸漸統整並歸納這些方法，其中包括這週需要寫的各種執行機制，包括今天的回饋機制

發布

發布的重點：

1. 發布功能小而獨立
2. 發布的頻率高
3. 測試集中在發布的功能上

在開發新產品的時候，我們會希望能夠快速的發布，這樣才能夠快速的獲得使用者的回饋，並且快速的修正問題。但是在開發的過程中，我們會發現，有些功能是很難獨立發布的，因為他們彼此之間有相依性，這時候我們就需要思考，如何將這些功能拆分成獨立的功能，並且讓他們可以獨立發布，這個過程難免，至於如何拆分，我在之前的文章中有提到過，這邊就不再贅述。

糾正

糾正的重點：

1. 使用者如何使用
2. 怎麼做可以加快使用者的速度
3. 使用者的痛點在哪裡
4. 不要請一個騎馬的人去試開車

在試用的時候，我們會發現，使用者的使用方式和我們的想像不太一樣，尤其當開發者的必須自己使用多次，需要用苛刻的態度來使用，才能夠發現問題，但是使用者不會這麼做，他們會使用最簡單的方式來使用，但不管如何，我們都需要去糾正這些問題，並將問題分成各種等級。

最後一個常見的問題，如果你再設計一個「全新」的產品，你需要找一個「全新」的使用者來試用，而不是找一個熟悉你的人來試用，因為他們會用他們熟悉的方式來使用，而不是你想要的方式，這樣的測試永遠都無法做出突破性的改變。

開發

開發的重點：

1. 完成被驗證且確認好的功能
2. 移除不需要的功能
3. 重構不好的程式碼

在得到回饋之後，對於回饋和需求做一個整合，並將這些內容分成不同的難易度和優先順序，然後依照這些順序來進行開發，這時候我們會發現，有些功能是不需要的，有些功能是需要重構的，有些功能是需要重新設計的，這些都是我們需要做的事情，而在這個時候，你還可能需要不同「領域」的同事協助。

而「領域」同事並不直接參與產品開發，他們只是針對產品的「領域」提供協助，例如：設計、部署、監控這類的工作，這些工作都是需要專業的人員來協助，而不是開發人員來做。

整合

我們收到來自不同「領域」和部門的協助之後，需要做資源的調配和整合，重點有

1. 資源的調配，例如：人力、時間、金錢
2. 你用了那些資源，回饋給對應的部門
3. 你需要那些資源，向對應的部門提出需求

這個時候，你會發現其實你也是別人「回饋」機制的一個環節，你需要將你的「回饋」給到對應的部門，並且向對應的部門提出你的需求，這樣才能夠讓整個產品開發的流程更加順暢。

發布（再次）

經過上訴流程，會再發布一次，並在執行一次剛剛的事，這個時候，你可能已經獲得了使用心得並且功能通過。

這個功能就會進入「維護」的階段，這個階段的重點是：

1. 維護功能的穩定性
2. 將維運的功能進行優化
3. 這類工作是「重要但不緊急」

穩定

穩定了功能表示了某程度解決了一些問題，我們可以根據這些問題來進行優化，優化的重點是：

1. 優化使用者的體驗和速度
2. DX 的優化
3. 提煉出共用的功能

總結

一個新產品的發布，需要有一個回饋的機制和流程，以上是回饋機制的一個簡單的流程，這個流程是可以被應用到任何的產品開發上。

回饋方法可以是任何的方式，例如：使用者的回饋、程式碼的回饋、測試的回饋、部門的回饋，這些都是回饋的方式，而回饋的方式可以是任何的方式，例如：使用表單、jira、excel，任何能紀錄的方式都可以。