許多軟體工程師從入行到資深的這段成長過程中，經常會自問：我的程式碼到底寫得好不好？怎麼樣才可以寫得更好？ 這不是一個相當容易得到清楚答案的問題，諮詢十個工程師，可能有七種說法。常見的具體建議，舉例來說：使用 Linter 規範統一的程式風格、閱讀 Clean Code 這本書學習撰寫乾淨的程式碼、運用常見的 Design Pattern 設計模式來做程式開發。 然而，除了這些常見的操作學習項目之外，是否有更根本的基礎評估方式存在？我們是否可能在特定的情境中，做出獨立的判斷，而不是單純依賴前人所提供的經驗呢？ 有的，以下幾點，或許可以讓我們用來獨立判斷一隻程式在各個面向上的表現，提供給大家參考。 --- ### 一、正確性 Correctness 程式邏輯是否能正確的解決目標問題，這是任何程式的最基本需求！ --- ### 二、完備性 Completeness 程式碼邏輯是否有把各式各樣的狀況都一併考慮進來，並處理完善。例如，程式能驗證非預期的輸入並給予回饋、程式能處理意外的 I/O 錯誤、程式有考慮到一些少見的、特殊的邊際條件，都能有效的處理。 --- ### 三、執行效率 Performance 常見的程式執行效率衡量標準包括： - CPU Time：程式具體的執行時間。 - Response Time：應用程式回應使用者的體感速度。 - Time Complexity：時間複雜度，排除硬體差異的演算法效率評估方式。 根據實際需求，選定衡量標準，在相同的資源條件下，執行效率越高越好。 --- ### 四、可讀性 Readability 如果把一段程式碼交給一位具備基礎背景能力的開發者，對方會需要多少時間來讀懂這段程式碼的功用是什麼？這就是程式碼的可讀性。 包括基本的變數命名、程式碼撰寫風格、適時的關鍵註解，以及進一步的釐清定義程式碼責任和獨立性等等細節，都會影響到程式是否容易被他人輕易的理解。 --- ### 五、可維護性 Maintainability 對於一隻需要長久運作的程式而言，可維護性非常的重要。 沒有任何程式是完美的，總是會有沒注意到的疏漏，需要在未來的某個時間點去補充修正。那麼，有良好可維護性的程式碼，能夠在發生問題時，更快的被找出問題根源並解決。 程式碼是否有良好的切割，每個模組負擔的責任是否清楚？部份出錯時，能否在不影響其他正常程式的狀況下，進行修正？是否有清楚的錯誤紀錄資訊等等細節，都會影響到程式的可維護性。 --- ### 六、可延展性 Extensibility 軟體產品總是需要隨著時代演進，才不會被淘汰，而運作中的軟體產品，要花多少的額外開發成本，才能滿足新的商業邏輯呢？ 具體來說，高延展性的程式能透過環境設定檔來改變程式的行為、共用模組可以預先支援常見的潛在需求、接受外部程式插入到核心運作流程中，提供額外的中介功能。 --- 當然，以上是我們單純以技術為考量的評估方式。在現實的商業環境中，若把實際可運用的資金、時間、人力資源考慮進來，那會有更多值得探討的議題，就不在本篇文章的討論範圍中。