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

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

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

[[313956]]

1. 代碼一目了然

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

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

2. 你并不需要它

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

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

3. 不要重復(fù)

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

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

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

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

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

圖片來源：Wikimedia

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

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

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

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

結(jié)語

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

編程快樂!