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

這才是開發(fā)人員面臨的真正挑戰(zhàn)。

本文將會介紹助你實現(xiàn)超級代碼狀態(tài)的5個原則。

[[313956]]

1. 代碼一目了然

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

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

2. 你并不需要它

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

這一原則規(guī)定在必要時才實施。這是每個開發(fā)人員都應(yīng)該遵循的一條建議。

3. 不要重復(fù)

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

這一概念的反義詞為WET代碼：所有內(nèi)容都重復(fù)一遍 可以創(chuàng)建一個公共函數(shù)或?qū)⒋a抽象化，以避免代碼中的任何重復(fù)。

4.關(guān)注點分離(SoC)

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

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

圖片來源：Wikimedia

5. 避免過早優(yōu)化

我們都希望優(yōu)化自己的代碼。但是該原則指出不應(yīng)該在開發(fā)的早期階段優(yōu)化算法。

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

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

結(jié)語

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

編程快樂!