在這一系列文，若下「解決」的關鍵字，會找到滿多篇裡都有提到解決問題這件事。這近 30 天裡，常常提到身為程式設計師的我們，主要職責就是要解決問題，這個問題通常來自於客戶的問題。但身為開發現場的我們，也會遇到許多與開發流程上相關的問題，卻常常顧著解決客戶的問題，而沒有餘力再去處理我們遇到的問題。但是這些問題長期積累下來，會直接或間接的導致軟體品質下降以及團隊產能的穩定輸出，我們應該要和主管或是組織其他部門協商，除了解決客戶的問題以外，也要留點時間解決開發團隊在流程上遇到的問題。

遇到重複性高的任務，我們要想著將它自動化。像是程式碼風格檢測自動化、建置自動化、測試自動化、部署自動化、封裝成安裝檔自動化、資料庫備份自動化。這些若沒有撥時間去做，會消耗團隊更多的時間，而且會因為軟體越趨複雜，這些成本會隨著時間過去也越來越大。

遇到軟體階段定義不明確時，我們也要花時間討論各階段的定義、進版的滿足條件，並且持續和團隊與組織溝通。到底什麼是 Staging、Beta、Production，哪個版本是穩定的、哪個版本可以作為驗收待測對象的、哪個版本是給客戶使用的。當軟體進到哪個階段是不再新增功能的、哪個階段是不再修復缺陷的、哪個階段是要下架的，這些如果沒有釐清，也會讓重複的溝通成本不斷地流逝。

目前團隊在版本控制上是否有一套標準流程？若是沒有應該要時間討論，不然錯雜、無用的分支會盤根錯節的扎在程式碼專案中，造成協作的困難；沒有被檢視過的程式碼，可能會在其他同事拉下來時爆炸；無意義或是語意不明的提交訊息會讓人在追溯程式碼歷史時昏頭眼花。這些合作上的阻礙也會拖慢團隊開發的速度。

使用者遇到缺陷時，我們應該要能得到足以除錯的資料。除了仰賴建立一個完整的問題回報報表外，或許花點時間去建立程式崩潰或出錯時，能夠將相關資訊存進某個伺服器，完整相關訊息，會是更好的做法。甚至能等到使用者打電話給客服以前，我們就已經將問題給扼殺了。詳細的資訊能縮短除錯的時間，透過程式自動回報資訊也可以降低客服的接到電話頻率，更重要的是，一堆不知如何重現的問題也逐漸不再出現。

知道什麼是技術債嗎？又知道技術債該怎麼被管理嗎？知道設計模式嗎？又知道設計模式在各語言中該怎麼實作與正確應用嗎？知道敏捷開發嗎？又知道敏捷開發到底是怎麼一回事嗎？知道要怎麼有效率的規劃產品待辦項目嗎？除了 DevOps，其他人知道 AWS 該怎麼用嗎？知道測試有分哪幾種嗎？又知道測試該怎麼寫嗎？軟體開發領域有太多知識等待我們去學習，這些知識都能幫助我們在軟體開發創造更高、更穩定的產出，若是組織總是要我們一直工作、一直加班，那我們的能力或許就無法提升，那組織在產品常遇到的困境或許也永遠無法解決。需要不斷學習新知識，也是個問題。

在軟體開發領域上，有太多細節無關於程式語言了，這些細節衍生出來問題，很多時候是只有遇到才會想到、才會思考該怎麼做。解決這些在軟體開發上與我們相關的問題，也是我們應當重視的。