隨著科技雲端數據應用普及，未來這個領域，英文溝通能力於商務領域那樣，具備基礎程式撰寫能力會是基本技能。
學習程式編碼（coding）是一種訓練利用邏輯進行思考及解決問題方法。
透過程式撰寫習慣養成，不但可大大提高工作效率，可減少不必要失誤。
於出現問題，我們可利用已有軟體資源：例如數據資料、程式結構、設計模式、軟體工具軟體環境，來提高程式組件重覆利用性。
複雜數據結構、物件或子程序，可利用圖形來輔助説 (ex.使用UML來繪製)，文字描述要。
複雜問題拆成數個解決問題來一一處理，後解決方案彙整，讓問題變得解決，這整個流程模組化一種過程。
模組化做法是處理問題、或具有行為函式 (Function) 相似性進行分組，集合成一個類別 (class)。
各類遵循單一職責原 (Single Responsibility Principle)，一個類別負責一個responsibility，實作上盡可能Robert C. Martin説每個類應該有一個可變因素（A class should have only one reason to change）原則，來進行職責分配。
如此，未來某一類進行相應或加入額外需求時，會一個職責相關改變，而牽連到其他程式碼，破壞了整個系統運作，從而可達成高內聚、耦合目的。
當所有職責有區分時，程式會變得擴充維護。
“Don’t Reinvent The Wheel”(不要疊牀架屋)意思是説，如果有大家公認程式碼或函式庫，很多情況下足以應付多數需求，需要重頭建構，以免浪費無謂時間。
於出現問題，我們可利用已有軟體資源：例如數據資料、程式結構、設計模式、軟體工具軟體環境，來提高程式組件重覆利用性。
此外，功能函式要提取出來，不要全部寫同一支程式裡。
程式碼撰寫原則是要讓使用者時間內能理解並弄懂。
但大部分撰寫者來説，可能覺得程式只要能執行，而選擇忽視程式碼編排規範，想要留待日後有時間來整理，但這些造成後維護困難耗費許多額外除錯時間。
改善程式可讀性有許多途徑，像縮排分段、名稱命名、註解以及利用區塊及函式組織程式碼幾個基本項目是。
a. 適時調整縮排斷行，每行程式碼80個字元基準。
程式碼不但閲讀、不用擔心使用端(terminal) 編輯器換行，可顯著增加排版上。
b. 命名規則要，並使用有意義名稱，讓閲讀人名稱可以瞭解該函式變數功用及意圖。
軟體開發過程中，版本控制系統有助追蹤過程、檔案文件差異進行快照//合併/回復先前狀態，發生問題時，藉由查看時間點或開發者提交修改項目來找出原因所在。
延伸閱讀…
d. 利用註解來描述作者想法、解釋演算法、或是紀錄程式碼缺陷。
註解應保持語意，使程式碼理解。
但若程式碼本身足以讓人瞭解用途，那麼加註解反而；要知道：一個程式「壞程式加註解」。
e. 透過類別和函式程式所需功能切割及封裝，一個函式只做一件事，且函式語句結構要。
有需要運用功能時，只要透過引用類別並呼叫函式可達到目的，如此才能提高複利用率，並有利於維護。
f. 確立規則和術語，開發中交流和協作需要有慣例和詞彙基礎，如此可加快開發速度，並降低維護困難度。
軟體開發過程中，版本控制系統有助追蹤過程、檔案文件差異進行快照//合併/回復先前狀態，發生問題時，藉由查看時間點或開發者提交修改項目來找出原因所在。
延伸閱讀…
如此，即便是一人開發，能夠鬆維護開發環境。
版本控制，人見做法檔案一有變複製一份存放，檔案名稱命名。
一開始可能記得哪裡做了，但過了一段時間，程式碼多，一次想不起來了。
許多人開發情境下，即使每次是存放位置取出檔案修改，可是當修改後上傳時，如何確保時間沒有其他人上傳檔案，這時候覆蓋檔案情況可能發生。
目前流行分散式版本控制系統，例如Git、Mercurial，開發者可以同時扮演貢獻者，以及擔任接受其他開發者提交程式碼公共儲存庫；儲存庫之間能傳送，並透過工作流程，協作方式。
而開發需求還可以建立分支 (branch)，例如：進行錯同時想添加實驗性功能特性，那麼可以建立分支來區隔工作，如此擔心改到同一個檔案。
我們可以分支之間反復切換，確保完成分支特性通過測試後，可分支合併，發佈或進行下一階段開發。
重構 (refactoring) 主要目的提升程式碼可讀性，或簡化結構、無用組件，這些是影響程式原有行為原則下進行，讓日後因應修改或擴充。
什麼時候該考慮重構？其實，重構是開發過程中進行，是讓後續開發進行，而不是另外安排時間來做工作。
於進行重構沒有規範，開發過程某些適當時機點可以搭配重構一起進行；例如：a. 添加功能時候
當原本設計方式讓我們需求添加功能時，程式碼做調整改善現有設計。