昨天提到的內容鎖定在當前寫好的工具多方整合的分享，而今天的內容會著重在純技術解決方案時遇到的挑戰，以及經過一些嘗試和測試後對於技術面評估的心得分享。
從初入職場到現在遇到的需求，也是從純寫程式開始滿足計畫以及使用者提到的需求，但當時開發一個段落之後也會去思考開發的模式和功能的重構可行性，所以當時也花了較多的時間去蒐集可以參考的相關範例(ex : 開源專案或者是社群的技術文章)。
接著在轉換工作環境後遇到的相關需求因應部門的屬性，傾向使用已導入的共用平台或者是評估新的工具是否能夠滿足，反而在純寫程式的解決方案比例有降比較低。
但純寫程式比例降低也可以說是依照當前可以應用的平台(ex : Jira、Confluence、other Microsoft service etc)相關功能為主，但如果要進一步客製化就需要確認該服務是否可以純寫程式碼，所以其實開發到中後期的時間有大部分的功能還是需要純程式碼實現(ex : Jira scirptrunner或者是另外開發Web Api跟平台做資料交換)。
而在這樣的過程中也可以透過平台提供的功能，進而去思考如果哪天需要純程式開發的時候，可以照這樣的模式去設計和發想，對於新的系統的架構與流程有一些啟發。
如果要用一個情境來比喻例如今天的需求跟簽核流程有關，這時候可以看跟簽核有關的工具(ex : BPM)，或者是微軟的Power Automate的核准功能(參考資訊)。
但要透過程式的話可以尋找有沒有可以參考的開源專案，例如這個awesome-workflow-engines裡面有不同程式語言的開源workflow engine，可參考這類型的資源了解當前的開源專案有做到甚麼程度，而較複雜的商業邏輯就可以依循在使用中的Low code，進而發想程式碼可以怎麼去實現。
上述的結果最後提到用程式碼去實踐參考的商業邏輯，但還是需要一些可以加強純開發的相關知識，接下來就分享一些可以學習或者是啟發的相關網路資源。
依照前端和後端較常使用的語言為例如下
總和今天的內容，主要分享了在純開發與應用導入的平台和Low Code交互使用後的心得，並且如果在純程式開發的部分可以參考的資訊。
iThome鐵人賽
看影片追技術
看更多
