當需求評估到一個段落後接著會有一個部分需要確認可行的方案，這時候大部分的工程師應該會想到的是看怎麼直接用程式實踐這個需求，但如果公司或者是部門內部已經有導入相關的系統，也許.....是不是可以都不用自己造輪子呢?

Low code的應用情境(以開發網站為例)

從英文的解釋可以知道在使用相關的工具或者是服務時，部分的功能可以不需要純寫code的方式就可以完成，這個部分可以舉一個開發網站的例子。假如今天的需求是要開發一個網站，而這個網站在畫面的呈現或者是功能上不需要太複雜，這個時候就可以使用Wordpress這類型的服務快速建立網站，並且可以透過後台的外掛商店進一步安裝需要的功能。

客製化的極限

剛剛提到的情境比較可以滿足很基本的需求，所以當畫面和功能越來越複雜的時候，就需要考量一下是不是需要用程式碼開發，不過像是這一個情況對於專門開發Wordpress外掛的廠商，可能就會變成付費的方式去滿足比較進階的功能，而提到這個地方就需要考量以下幾點。

應用的low code相關工具和服務的支援和版本穩定度

首先這個個人覺得還蠻重要的，因為在使用工具的當下已經是一個包好的產品(意思就是不能直接去改他原生的功能)，所以如果在某一個版本使用的相關套件有風險的時候，可能就要仰賴提供這個工具的公司是否能提供即時的更新修補。

接下來需要留意的是剛剛提到的外掛套件，如果遇到版本的大更新或者是哪一天停止這個產品，反而對於後續尋找替代的方案和測試相對就會多花一點時間。

備註 : 上述提到的情況如果提供工具或者是套件的公司是有規模，並且產品都已經是很成熟的階段發生的機率也會相對較低

兩者做法的總結

簡述完Low code的情境和想到可以的做法後回頭來看純寫code的解決方案，在這個部分基本就是看使用者的需求後，接著就是選擇擅長的程式語言與相關的框架做開發，中間可能遇到的困難就是開發過程中的程式錯誤排除，或者是效能上與程式面的優化。

所以說這兩個選項最終還是會回歸幾個面向，首先是這個系統開發完成後的維護loading，哪一個的負擔會比較小或者是當前負責的產品一多的時候可以快速延伸開發。再者也可能會因為當前的開發單位的發展走向，部分的需求就只能使用Low code的工具或者就是要強制造輪子都是有可能的。

如果是我，我會怎麼選擇

最後再把評估的角度透過我目前遇到的相關需求做個分享，個人會比較在意的部分是協助開發這個需求後的maintain loading，如果需求基本上現行的工具都可以滿足的話就不會額外純寫code，但若需求談到最後需要純開發的話，需要做的事是除了寫程式之外，規劃出來的功能和寫出來的東西，是否能夠當作共用的元件也是其中一個很重要的規劃。