目前我們的project內是一連串的程式碼，全部擠在一起不太好閱讀，所以今天我們來看看如何找出重覆的地方，將其獨立出來。

1. 在建立同一種Entity的時候，只有fields部份會有變動，deck及element_type是不變的。因為我們希望針對建立不同Entity時，都可以有相對應的creator function，分別有create_node、create_shell、create_mat、create_sec、create_set及 create_contact，預計於[Day12]完成。

2. 要想完成上述function，有幾個問題需要先處理。

• 如何處理當建立Entity時，需要輸入不容易記憶字串的問題。
  • 利用Enum來儲存這些字串，預計於[Day09]完成。
• 如何替每個Entity取一個容易辨識的名字。
  • 建立一個自動產生名字的function，預計於[Day10]完成。
• 如何妥善處理安排Entity的id。
  • 建立各Entity的id系統，預計於[Day11]完成。

3. 建立能夠有邏輯產生node及element Entity的架構，預計於[Day13~14]完成。
4. 建立一些utility function來設定邊界條件、control及database card、輸出k檔及求解k檔等，預計於[Day15]完成。
5. 使用Base.ImportV1快速建立大量node及element Entity，預計於[Day16]完成。
6. 使用context manager來簡化Base.ImportV1的使用流程，預計於[Day17]完成。
7. 寫點test，預計於[Day18]完成。
8. 利用Streamlit於本機端產生config檔，預計於[Day19]完成。
9. 利用Streamlit於遠端產生config檔，並上傳至Linode Object Storage，再於本機自Linode Object Storage下載config檔，預計於[Day20]完成。
10. 部署Streamlit App至Streamlit Cloud，預計於[Day21]完成。

說說心底話

這個project太簡單了，我們面臨的題目哪有那麼容易處理，自動化只能做些玩具騙騙不懂的啦!

或許這是諸位看本系列文到目前的感想？我們理解業界實務面臨的問題五花八門，要說自動化可以解決所有的問題，我們自己也覺得這樣說是不是太吹了呀。

我們認為CAE的自動化，不應該視為一勞永逸的解方，而是一種逐步導入的概念。一開始自動化1%，發現效果不錯，再增加到5%，之後再增加到10%，直到面臨該次應用的瓶頸為止。或許加以時日，無論是科技的進步又或是知識的累積，又可以再次推高自動化的百分比。

自動化除了減輕我們繁複的操作，讓我們將時間放在更重要的地方。另一個優點是可以減少能源的消耗，因為自動化後出錯的機率較低，效率也較高，在這個需要節省減碳的社會，咱們CAE領域也是時候來響應一下了。

這個project的許多code，是從我們過去開發的經驗抽取並簡化而來，可能諸位會覺得某些功能有所侷限不夠通用。但相比於code本身，我們更想傳達的是如何開發，如何從ok到better。所以決定採用逐步精進，而非一步到位的方式來講解這個project。

在CAE世界裡，我們或許不是最懂ANSA的一群，也或許不是最懂LS-DYNA的一群，甚至絕對不是最懂Python的一群，但我們應該是少數願意分享所知的一群，希望這系列文能讓諸位滿載而歸。