初次見面。
我是 PRUM 股份公司的 masa。
今天我想寫給工程師初學者，談談如果先理解現場整體的開發流程，以及實作前後各個階段的意圖，再開始實作，會帶來什麼改變。如果你有興趣，歡迎讀下去。
一個功能完成前有 5 個步驟
在學習程式設計時，很容易產生「寫程式＝開發」的印象。但在實際現場，寫程式其實只是整體流程中的一個環節而已。
大致整理如下：
- 企劃・假設驗證 ── 確認「做出這個功能，是否對使用者有價值」。現代主流做法是快速做出 MVP（Minimum Viable Product，最小可行產品）來驗證
- 需求定義 ── 把「要做什麼」具體化。現場有時會從一頁左右的規格書開始
- 設計 ── 決定「要怎麼做」。例如基礎架構的配置、資料的保存方式、類別與模組的切分等
- 實作・測試 ── 撰寫程式碼。同時也會撰寫自動化測試，以便確認功能沒有被破壞
- 程式碼審查 ── 團隊成員彼此閱讀程式碼，確認是否有問題
對於沒有經驗、剛進公司的人來說，這 5 個步驟中，幾乎都是從「實作・測試」開始參與。剛開始很少有機會接觸企劃或設計。不過也正因如此，是否理解「上游到底決定了什麼」，會直接影響實作的品質。
先知道「為什麼這樣做」再實作，真的會有改變
進入現場幾個月後，前輩對我說的一句話，我到現在還記得。
前輩：「開始做這個任務之前，你有讀過這個功能的設計文件嗎？」
我：「啊，還沒。不過內容不是都寫在 ticket 裡了嗎……」
前輩：「讀一下吧，裡面有寫為什麼要設計成這個結構。」
那天我先讀了設計文件再開始實作，結果真的明顯不一樣。當我理解了「為什麼資料表要這樣拆」、「為什麼這個 API 會收這些參數」之後，實作時需要做判斷的地方變少了。更重要的是，我清楚知道「自己現在動手是在為了什麼」，這也讓我更能感受到開發的有趣與成就感。
知道「為什麼會變成這樣」和實際參與設計，本來就是不同的事。參與設計的機會會隨著經驗增加而慢慢變多，但「讀懂設計意圖」這件事，從今天就可以開始。
程式碼審查不是「修正」，而是「對話」
實作完成後，會發 Pull Request，請團隊成員幫忙審查。剛開始時，老實說我很害怕。
「自己的程式碼會被看見」的壓力，加上「如果被指出問題怎麼辦」的焦慮，讓我在送出 Pull Request 前反覆確認很多次。
但實際做了之後，印象其實差很多。
前輩：「這裡的處理方式也可以用別的方法，為什麼你選這個？」
我：「老實說我想不到……只想到這種做法。」
前輩：「原來如此，那我們一起看看吧。」
這不是「被指出錯誤的地方」的場域，而是「一起回顧當初怎麼思考、怎麼做出來的」的場域。如果是在理解設計意圖後才開始實作，這種對話會變得更深入。因為你可以用自己的話說明「為什麼要這樣實作」，所以程式碼審查會從令人害怕的場合，慢慢變成可以學習的場合。
其實，是否理解這種心態，也會影響你在實作中的做法。當你知道「之後會被問為什麼這樣做」時，就比較不會只是憑感覺往下做，而會更有意識地選擇：是先問前輩，還是自己先查資料。
程式碼審查不是在實作完成後才開始，而是和實作當中的思考緊密相連。試著在實作時也把程式碼審查意識進去吧。
總結
「會寫程式」和「能在現場開發」其實有點不同。
在現場，很多事情在你開始寫程式之前就已經決定了。會有企劃、需求，還有設計。當你了解這個流程，知道「自己現在寫的程式位於哪個環節」，並且一邊思考「為什麼要寫這段程式」一邊實作時，猶豫的次數會減少，在程式碼審查時也能表達更多想法。
實際參與設計的機會，會隨著經驗慢慢增加。不過，「讀懂意圖並採取行動」這件事，不管你目前的實力如何，都可以開始嘗試。
下次拿到實作任務時，在開始之前，先試著問某個人一次「為什麼需要這個功能」。我認為光是這樣，就會讓你寫出來的程式品質有所不同，請務必試試看。
也推薦你從 PRUM 股份公司所經營的文章網站補充知識。
如果你有興趣，也可以看看最近很受歡迎的文章👇
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
