前言
市面上軟體開發相關的書籍和課程，已經提供許多標準化的流程可以使用了，但是在新創、中小規模或是制度較為不完善的公司，因為各種問題，可能比較難套用所謂的標準流程，難免會顯得開發流程一團亂、無所適從。因此這篇文章想要提供根據個人實際開發上的經驗，提供一種流程給新人作為參考。
流程
流程如下，以下會簡單說明各階段該做什麼：
- 聆聽需求與理解需求
- 思考與設計
- 實作與測試
- 驗收
1. 聆聽需求與理解需求
這個階段其實就是看清楚題目，看看要主管、前輩、客戶到底想要你做什麼。
這個階段還沒開始寫程式，但卻是最重要的一個階段，因為如果沒有在這個階段弄清楚，後面所做的，都很有可能是白工。
需求者可能只會把他們的需求用簡單的幾句話帶過，像是「客戶想要在某個API上加上時間戳記」、「我想要在點擊頁面上的某個按鈕之後，自動發信通知管理者」、「可不可以讓某支程式執行完之後，會自動更新某個資料庫欄位」，或是更抽象點的說：「想要自動刪除沒人看的文章。」
這些敘述聽起來很簡單、但是常常會遇到一個問題是，提出問題者會跟你處於資訊不對等的狀態，他所想像的需求、跟你認為的需求，往往會有一定程度的落差。又或者對方可能只是一時靈光一閃、信手捻來的一個想法，其實也沒有很清楚自己到底想要什麼。但這並不是需求者不願意跟你講清楚，而是對方認為你的認知跟他一樣，他不知道你並不清楚他想要什麼。
通常遇到這種情況，你要主動降低雙方認知的差異。在聆聽需求時，有聽到什麼覺得模糊、或是覺得怪怪的地方，或者是有想到什麼例外情況，最好馬上提出來跟對方確認。比如說，什麼叫做沒人看的文章？多少人以下叫做沒人看？以前很多人看、現在沒人看算是沒人看嗎？釐清這些部分，才有助於更加理解需求。
2. 思考與設計
針對題目，思考並提出適合的解法。
這個階段算是事前準備，屬於比較概念性或是大範圍的，有人會問說，為什麼不一邊實作一邊思考就好？但對於開發經驗不足的工程師來說，邊實作邊思考常常會導致整段程式前後程式邏輯、或是到了最後一步才發現前面所寫的，沒辦法滿足需求，必須要全部打掉重練。所以說，開始實作之前，好好思考是很重要的。
我們可以從確認身邊可用資源以及哪些資源可能受影響開始開始思考。所謂的資源包含：負責執行程式碼的伺服器、系統或專案現有的程式碼、外部的儲存裝置如資料庫、快取、硬碟、工時和你自身的能力等。
通常丟給新人的案子、不會太複雜，重點會在於程式碼的部分。如果今天要做的是一個全新的功能，那就比較單純，只要設計出可以符合需求的程式就可以了。但如果是要在既有程式上做擴充的話，可能就要先讀懂該部分的架構，順著架構的邏輯去設計新的程式或修改既有程式，而不是像個違章建築般，硬是加上一段程式，如果不熟原本的架構，最好還是向前輩請教，或花一點心力去看懂它。
如果有包含到資料庫操作的部分，就要研究一下會用到哪張資料表、哪個欄位，並看看這些資料表、欄位是否符合需求？會需要新增新的資料表或欄位嗎？如果這個功能的讀取頻率很高，就要考慮是否需要新增一層快取來暫存資料。如果要寫入的表格有其他功能有用到，就要確保寫入這張表格後，其他功能還能正常運作。
如果有時程很趕的話，這部分也是要被考慮進去的，或許就不能採用太複雜的想法或者要限縮研究的時間。
總之在思考解法的階段，最重要的就是盡可能掌握所有可能受影響的部分，想出解法後，在腦海中大概順一下邏輯，沒問題就可以往下走，有問題就在重新思考解法，或者甚至要回到上一步去確認是不是需求有什麼邏輯不通，或做不到的地方？不能只專注在需求本身，否則很容易設計出難以維護、難以閱讀或者是有嚴重副作用的程式。
3. 實作與測試
將思考後的結果寫下來，並且要記得檢查做驗算
這部分大概就是單純的勞力活，把該做的事情一步一步做完就好。有些公司可能會採用TDD的開發方式，有些公司則是直接就開始寫了，每間公司的開發流程和開發環境不一樣，就按照情況處理囉。遇到不知道如何實作程式概念的時候，可以多多利用google或是既有的程式碼作為參考。
如果是要改動原本的程式碼的話，建議不要一次改動太大的部分，每次只改一點點，免得自己錯亂了，不小心改到不該改的部分。
實作完成的每段程式一定要經過測試，也就是至少要執行過並確認結果符合你的預期，完全沒測試過程式甚至可能會犯下初階的語法錯誤。所以思考如何測試新寫的程式也是很重要的，有些公司可能已經有完整的解決方案了，可以直接參考前人做法，但如果沒有就要想一下。比如說：功能有包含資料庫寫入的部分，要怎麼確定資料有成功寫入？如果資料庫不能任意寫入的話，有沒有其他方法可以驗證程式可以正常運作？諸如此類的。
4. 驗收
寫完考卷後交卷，讓需求單位改考卷。
實作完將程式交付給需求單位驗收後，對方會用自己的方式確認成品是否符合他們的預期，如果在第一階段有做好的話，通常差異不會太大，只會有小地方需要調整。但最不樂見的就是差異過多，要嘛就是第一階段沒做好，只好摸摸鼻子回到第一階段重新來過，要嘛就是對方突然改變心意卻沒有及時提出，這樣就有點微妙了，看公司氣氛決定如何處理。
那如果驗收沒有什麼問題，這個案子就這樣算是告一段落了。
結論
其實大部分的標準化流程，大方向來說也是在做這樣的事情，只是在每個步驟可能切得更仔細，或是有其他人負責，像是規劃或測試，只是小組織來說，你可能要一手包辦這一切XD所以我認為，可以先用這樣的流程試試看，再去思考有什麼可以改進、或不足的地方。