軟體只是傳遞價值的一種方式

從硬體廠離開到軟體廠後，大多數的時間都還是在學習跟讀文件中度過。

不過終究理解到，大量的軟體工作，不論是修改API或是前端版面，大多只都是為了把價值傳遞，而個別產業的domain know-how則是透過軟體的編輯工作做出來的，而這些所開發出來的不論是scrum、CICD或是各種的開發流程都只是為了將這個目的貫徹而已。若忽略了這個目的而一味的追求程式寫法的高超或是做高深的套件，大概都忘記了本身軟體在個別產業所要服務的目的。

近期越看越多CICD的東西，後來才理解到，終究早期的開發流程中間每個區塊都有著一個隔閡，而不同公司的CICD的熟悉方式，最終就是一個符合那個公司個性的解方，也只有這個解方可以讓最終的成品可以更便利的把價值傳遞這件事情達成，而且是盡力如期、如質、如預算的達到目標。

不論談的是Gitlab、Github action、Jenkins或是近期又很夯的GitOP都是為了目的而服務的，最終沒有最對的方法，而是要找到最符合團隊的狀況(但還是要很多基礎的東西要做，至少環境變數要記得版控。最近看到有人很喜歡用google全家餐，每次環境變數都開一個雲端資料夾放裡面都快吐了）而團隊開發有著自己的默契，能習慣有共識就是最好的，畢竟程式開發越來越龐大，而最終也不可能單幹可以做完整個專案，而好維護好共事的流程，絕對只有團隊自己試過才知道，試錯了下一次換工作的時候也是會用著的。

公司也因為一些變動改變了走了scrum，有時候本意良善，不論是scrum master定位不明，PO總是很喜歡生出很多表格跟甘特圖給我們填寫，總覺得後來都變成了文書作業多，而敏捷的部分就越來越少，不如本來瀑布流的開發速度，最終也演變成徒有其表的敏捷，為了敏捷而敏捷，最終也只是多了那個形式，而不知道最終他的目的還是要將價值傳遞這件事情做的完整完美。

前陣子也很喜歡自己專案找些套件套上去，反正只要能快速符合需求，就可以下班結案。但後來聽了奶綠的講解之後才逐漸理解，若一個feature要長期使用，要引入什麼套件就要有共識，沒有必要的套件就不要使用，寧可花一點時間好好把他寫好，也不要最終因為亂用套件而產生一堆技術債，最終又要做一堆改寫或是換人維護產生一堆時間成本。用什麼新的套件都很簡單，但最終的目的還是有利於團隊維護，把整個價值傳遞的事情做得完全。

開發這條路好像就是這樣，不停的踩坑跟磨難，作為一個開發路上的新手，大概也只能走走看看，幸好路上有多位大神有樹蔭能夠乘涼，就能夠在走遠走長一些。