開始編程時遇到的第一個挑戰是編寫功能代碼。但成為開發者后，編程技能也會隨之增長。你的代碼應該從普通的功能代碼發展為簡潔、高效、可理解且可維護的代碼。

這才是開發人員面臨的真正挑戰。

本文將會介紹助你實現超級代碼狀態的5個原則。

[[313956]]

1. 代碼一目了然

程序的大小增加時，代碼的復雜性也會隨之增加。代碼也會變得很難調試，因為調試復雜的代碼是一項可怕的任務。沒有人喜歡維護復雜的代碼。這個原則指出應該始終保持代碼的簡單性。如果代碼復雜，請努力將其分解成更小、更易維護的代碼。

編寫簡潔的代碼比編寫復雜的BS代碼更困難。作為開發人員，隨著技能不斷成熟，你的代碼就應該越干凈、越有意義。

2. 你并不需要它

有時應當未雨綢繆，但不是在編程方面。人們傾向于編寫將來可能需要但現在還不需要的代碼。這些代碼不必要地增加了程序的大小，因為編寫的代碼從來沒有實現過。更重要的是，大多數程序員將來都不會使用這些代碼。程序員的這種習慣會使代碼不必要地膨脹。

這一原則規定在必要時才實施。這是每個開發人員都應該遵循的一條建議。

3. 不要重復

這一原則對于編寫簡單且易于修改的代碼至關重要。重復的代碼是程序員常犯的錯誤。這個原則指出，一段代碼應該在源代碼中的一個地方實現。如果注意到同樣的代碼塊重復出現，說明違背了這個原則。

這一概念的反義詞為WET代碼：所有內容都重復一遍 可以創建一個公共函數或將代碼抽象化，以避免代碼中的任何重復。

4.關注點分離(SoC)

關注點分離原則：管好自己的事——就是字面意思。這個原則建議將復雜的代碼劃分為不同的部分或域。每個部分相互獨立，因此每個部分可以獨立處理。而且，維護、更新和重用代碼也更加容易。

SoC一個很好的例子就是MVC架構。該架構將程序分成三個區域：數據(模型)、邏輯(控制器)和最終用戶看到的內容(視圖)。MVC在現代框架中大量運用。

圖片來源：Wikimedia

5. 避免過早優化

我們都希望優化自己的代碼。但是該原則指出不應該在開發的早期階段優化算法。

此原理與YAGNI原理非常相似。不同之處在于，YAGNI原則談到了實現不必要函數的趨勢，而該原則談到了在必要之前加快算法速度的趨勢。

過早優化的問題在于，直至出現問題之前，你永遠無法真正知道程序的瓶頸在哪里。當然可以猜測，有時猜測甚至可能是對的。但是更常見的情況是，你會浪費寶貴的時間來嘗試加速一個并不比預期慢的或者不像期望的那樣經常被調用的函數。

結語

成為開發人員后，你會意識到項目的成功在很大程度上取決于你的團隊。上面的原則可以幫助你編寫可維護的代碼——不僅是你自己，將來任何人都可以維護這些代碼。畢竟，團結就是力量。

編程快樂!