程序設(shè)計的好與壞，早在我們青蔥歲月時就接觸過了，只是那是并不知道這竟如此重要。能夠立即改善程序設(shè)計、寫出“好”代碼的知識有以下幾點：

•面向?qū)ο笪鍌€基本原則；
•常見的三種架構(gòu)；
•繪圖；
•起一個好名字；
•優(yōu)化嵌套的 if else 代碼；

當然，其他技術(shù)知識的豐富程度也決定了程序設(shè)計的好壞。例如通過引入消息隊列解決雙端性能差異問題、通過增加緩存層提高查詢效率等。下面我們一起來看看，上面列出的知識點包含哪些內(nèi)容，這些內(nèi)容對代碼和程序設(shè)計的改善有何幫助。

面向?qū)ο笪鍌€基本原則

本書作者是 2010 級學生，面向?qū)ο笫亲髡咔嗍[時期發(fā)展火熱的編程范式。它的五個基本原則是：

•單一職責原則；
•開放封閉原則；
•依賴倒置原則；
•接口隔離原則；
•合成復用原則；

下面我們將通過對比和場景假設(shè)的方式了解五個基本原則對代碼質(zhì)量的影響。

立竿見影的單一職責原則

沒錯，立竿見影、效果卓越。對于我們這些自學編程無師自通的人來說，能把功能實現(xiàn)就可以了，根本沒有時間考慮代碼優(yōu)化和維護成本問題。時光流逝，竟在接觸編程很長一段時間后才發(fā)現(xiàn)它竟如此重要。

俗話說只要代碼寫的夠爛，提升就足夠明顯。以一個從文件內(nèi)容中匹配關(guān)鍵數(shù)據(jù)并根據(jù)匹配結(jié)果發(fā)出網(wǎng)絡(luò)請求的案例，看看大部分程序員的寫法：

import re
import requests


FILE = "./information.fet"


def extract(file):
    fil = open(file, "r")
    content = fil.read()
    fil.close()
    find_object = re.search(r"url=\d+", content)
    find = find_object.group(1)
    text = requests.get(find)
    return text


if __name__ == "__main__":
    text = extract(FILE)
    print(text)

需求已經(jīng)實現(xiàn)，這點毋庸置疑，但是問題來了：

•如果讀取文件的時候發(fā)生異常了怎么辦？
•如果數(shù)據(jù)源發(fā)生變化該如何處理？
•如果網(wǎng)絡(luò)請求返回的數(shù)據(jù)不符合最終要求怎么辦？

如果你心里的第一個反應是改代碼，那你就要注意了。完成一件事中間的某個環(huán)節(jié)發(fā)生變化，改代碼是在所難免的，但是如果按照上面這種寫法，不僅代碼越改越亂，連邏輯也會越來越亂。單一職責原則表達的是讓一個函數(shù)盡量只做一件事，不要將多件事混雜在一個函數(shù)中。

上面的代碼如果重新設(shè)計，我認為至少應該是這樣的：

def get_source():
    """獲取數(shù)據(jù)源"""
    return


def extract_(val):
    """匹配關(guān)鍵數(shù)據(jù)"""
    return


def fetch(val):
    """發(fā)出網(wǎng)絡(luò)請求"""
    return


def trim(val):
    """修剪數(shù)據(jù)"""
    return


def extract(file):
    """提取目標數(shù)據(jù)"""
    source = get_source()
    content = extract_(source)
    text = trim(fetch(content))
    return text


if __name__ == "__main__":
    text = extract(FILE)
    print(text)

把原來放在一個函數(shù)中實現(xiàn)的多個步驟拆分成為多個更小的函數(shù)，每個函數(shù)只做一件事。當數(shù)據(jù)源發(fā)生變化時，只需要改動 get_source 相關(guān)的代碼即可；如果網(wǎng)絡(luò)請求返回的數(shù)據(jù)不符合最終要求，我們可以在 trim 函數(shù)中對它進行修剪。這樣一來，代碼應對變化的能力提高了許多，整個流程也變得更清晰易懂。改動前后的變化如下圖所示：

單一職責原則的核心是解耦和增強內(nèi)聚力，如果一個函數(shù)承擔的職責過多，等于把這些職責耦合在一起，這種耦合會導致脆弱的設(shè)計。當發(fā)生變化時，原本的設(shè)計會遭受到意想不到的破壞。單一職責原則實際上是把一件事拆分成多個步驟，代碼修改造成的影響范圍很小。

讓代碼穩(wěn)定性飛升的開放封閉原則和依賴倒置原則

開放封閉原則中的開放指的是對擴展開放，封閉指的是對修改封閉。需求總是變化的，業(yè)務方這個月讓你把數(shù)據(jù)存儲到 MySQL 數(shù)據(jù)庫中，下個月就有可能讓你導出到 Excel 表格里，這時候你就得改代碼了。這個場景和上面的單一職責原則很相似，同樣面臨代碼改動，單一職責原則示例主要表達的是通過解耦降低改動的影響，這里主要表達的是通過對擴展開放、對修改封閉提高程序應對變化的能力和提高程序穩(wěn)定性。

穩(wěn)定這個詞如何理解呢？

較少的改動或者不改動即視為穩(wěn)定，穩(wěn)定意味著調(diào)用這個對象的其它代碼拿到的結(jié)果是可以確定的，整體是穩(wěn)定的。

按照一般程序員的寫法，數(shù)據(jù)存儲的代碼大概是這樣的：

class MySQLSave:

    def __init__(self):
        pass

    def insert(self):
        pass

    def update(self):
        pass


class Business:
    def __init__(self):
        pass

    def save(self):
        saver = MySQLSave()
        saver.insert()

功能是能夠?qū)崿F(xiàn)的，這點毋庸置疑。來看看它如何應對變化，如果要更換存儲，那么就意味著需要改代碼。按照上面的代碼示例，有兩個選擇：

•重新寫一個存儲到 ExcelSave 的類；
•對 MySQLSave 類進行改動；

上面的兩種選擇，無論怎么選都會改動 2 個類。因為不僅存儲的類需要改動，調(diào)用處的代碼也需要更改。這樣一來，它們整體都是不穩(wěn)定的。如果換一種實現(xiàn)方式，根據(jù)依賴倒置的設(shè)計指導可以輕松應對這個問題。邊看代碼邊理解：

import abc


class Save(metaclass=abc.ABCMeta):
    @abc.abstractmethod
    def insert(self):
        pass

    @abc.abstractmethod
    def update(self):
        pass


class MySQLSave(Save):

    def __init__(self):
        self.classify = "mysql"
        pass

    def insert(self):
        pass

    def update(self):
        pass


class Excel(Save):
    def __init__(self):
        self.classify = "excel"

    def insert(self):
        pass

    def update(self):
        pass


class Business:
    def __init__(self, saver):
        self.saver = saver

    def insert(self):
        self.saver.insert()

    def update(self):
        self.saver.update()


if __name__ == "__main__":
    mysql_saver = MySQLSave()
    excel_saver = Excel()
    business = Business(mysql_saver)

這里通過內(nèi)置的 abc 實現(xiàn)了一個抽象基類，這個基類的目的是強制子類實現(xiàn)要求的方法，以達到子類功能統(tǒng)一。子類功能統(tǒng)一后，無論調(diào)用它的哪個子類，都是穩(wěn)定的，不會出現(xiàn)調(diào)用方還需要修改方法名或者修改傳入?yún)?shù)的情況。

依賴倒置中的倒置，指的是依賴關(guān)系的倒置。之前的代碼是調(diào)用方 Business 依賴對象 MySQLSave，一旦對象 MySQLSave 需要被替換， Business 就需要改動。依賴倒置中的依賴指的是對象的依賴關(guān)系，之前依賴的是實體，如果改為后面這種依賴抽象的方式，情況就會扭轉(zhuǎn)過來：

實體 Business 依賴抽象有一個好處：抽象穩(wěn)定。相對于多變的實體來說，抽象更穩(wěn)定。代碼改動前后的依賴關(guān)系發(fā)生了重大變化，之前調(diào)用方 Business 直接依賴于實體 MySQLSave，通過依賴倒置改造后 Busines 和 ExcelSave、 MySQLSave 全都依賴抽象。

這樣做的好處是如果需要更換存儲，只需要創(chuàng)建一個新的存儲實體，然后調(diào)用 Business 時傳遞進去即可，這樣可以不用改動 Business 的代碼，符合面向修改封閉、面向擴展開放的開放封閉原則；

依賴倒置的具體實現(xiàn)方式使用了一種叫做依賴注入的手段，實際上單純使用依賴注入、不使用依賴倒置也可以滿足開閉原則要求，感興趣的讀者不妨試一試。

挑肥揀瘦的接口隔離原則

接口隔離原則中的接口指的是 Interface，而不是 Web 應用里面的 Restful 接口，但是在實際應用中可以將其抽象理解為相同的對象。接口隔離原則在設(shè)計層面看，跟單一職責原則的目的是一致的。接口隔離原則的指導思想是：

•調(diào)用方不應該依賴它不需要的接口；
•依賴關(guān)系應當建立在最小接口上；

這實際上是告訴我們要給接口減肥，過多功能的接口可以選用拆分的方式優(yōu)化。舉個例子，現(xiàn)在為圖書館設(shè)計一個圖書的抽象類：

import abc


class Book(metaclass=abc.ABCMeta):
    @abc.abstractmethod
    def buy(self):
        pass

    @abc.abstractmethod
    def borrow(self):
        pass

    @abc.abstractmethod
    def shelf_off(self):
        pass

    @abc.abstractmethod
    def shelf_on(self):
        pass

圖可以被購買、可以被借閱、可以下架、可以上架，這看起來并沒有什么問題。但這樣一來這個抽象只能提供給管理人員使用，用戶操作時需要再設(shè)定一個新的抽象類，因為你不可能讓用戶可以操縱圖書上下架。接口隔離原則推薦的做法是把圖書的上下架和圖書購買、借閱分成 2 個抽象類，管理端的圖書類繼承 2 個抽象類，用戶端的圖書類繼承 1 個抽象類。這么看起來是有點繞，不要慌，我們看圖理解：

這樣是不是一下就看懂了。這個指導思想很重要，不僅能夠指導我們設(shè)計抽象接口，也能夠指導我們設(shè)計 Restful 接口，還能夠幫助我們發(fā)現(xiàn)現(xiàn)有接口存在的問題，從而設(shè)計出更合理的程序。

輕裝上陣的合成復用原則

合成復用原則的指導思想是：盡量使用對象組合，而不是繼承來達到復用的目的。合成復用的作用是降低對象之間的依賴，因為繼承是強依賴關(guān)系，無論子類使用到父類的哪幾個屬性，子類都需要完全擁有父類。合成采用另一種方式實現(xiàn)對象之間的關(guān)聯(lián)，降低依賴關(guān)系。

為什么推薦優(yōu)先使用合成復用，而后考慮繼承呢？

因為繼承的強依賴關(guān)系，一旦被依賴的對象（父類）發(fā)生改變，那么依賴者（子類）也需要改變，合成復用則可以避免這樣的情況出現(xiàn)。要注意的是，推薦優(yōu)先使用復用，但并不是拒絕使用繼承，該用的地方還得用。我們以一段代碼為例，說明合成復用和繼承的差異：

import abc


class Car:

    def move(self):
        pass

    def engine(self):
        pass


class KateCar(Car):

    def move(self):
        pass

    def engine(self):
        pass


class FluentCar(Car):

    def move(self):
        pass

    def engine(self):
        pass

這里的 Car 作為父類，擁有 move 和 engine 2 個重要屬性，這時候如果需要給汽車涂裝顏色，那么就要新增一個 color 屬性，3 個類都要增加。如果使用合成復用的方式，可以這么寫：

class Color:
    pass


class KateCar:

    color = Color()

    def move(self):
        pass

    def engine(self):
        pass


class FluentCar:

    color = Color()

    def move(self):
        pass

    def engine(self):
        pass

類對象合成復用的具體操作是在類中實例化一個類對象，然后在需要的時候調(diào)用它。代碼可能沒有那么直觀，我們看圖：

這個例子主要用于說明繼承和合成復用的具體實現(xiàn)方式和前后變化，對于 Car 的繼承無需深究，因為如果你執(zhí)著地討論為什么右圖中的 2 個 Car 不用繼承，就會陷入牛角尖。

這里的合成復用選用的實現(xiàn)方式是在 2 個 Car 里面實例化另一個類 Color，其實也可以用依賴注入的手段在外部實例化 Color，然后把實例對象傳遞給 2 個 Car。

常見的三種架構(gòu)

了解多種不同的架構(gòu)可以使我們的知識面更寬廣，面對一類問題的時候可以提出其它解決辦法。同時，了解多種架構(gòu)可以讓我們在設(shè)計階段做好規(guī)劃，避免后續(xù)頻繁的重構(gòu)。常見的三種架構(gòu)分別是：

•單體架構(gòu)；
•分布式架構(gòu)；
•微服務架構(gòu)；

單體架構(gòu)

單體架構(gòu)是我們平時接觸較多的架構(gòu)，也是相對容易理解的架構(gòu)。單體架構(gòu)把所有功能都聚合在一個應用里，我們可以簡單地將這種架構(gòu)視作：

這種架構(gòu)簡單、容易部署和測試，大部分應用的初期都采用單體架構(gòu)。單體架構(gòu)也有幾個明顯缺點：

•復雜性高，所有功能糅合在一個應用里，模塊多、容易出現(xiàn)邊界模糊，而且隨著時間的推移和業(yè)務的發(fā)展，項目越來越大、代碼越來越多，整體服務效率逐漸下降；
•發(fā)布/部署頻率低，牽一發(fā)而動全身，新功能或問題修復的發(fā)布上線需要多方協(xié)調(diào)，發(fā)布時間一拖再拖。項目大則構(gòu)建時間長、構(gòu)建失敗的幾率也會有所增加；
•性能瓶頸明顯，一頭牛再厲害也抵不過多頭牛合力的效果，隨著數(shù)據(jù)量、請求并發(fā)的增加，讀性能的不足最先暴露出來，接著你就會發(fā)現(xiàn)其它方面也跟不上了；
•影響技術(shù)創(chuàng)新：單體架構(gòu)通常選用一類語言或一類框架統(tǒng)一開發(fā)，想要引入新技術(shù)或者接入現(xiàn)代化的服務是很困難的；
•可靠性低，一旦服務出現(xiàn)問題，影響是巨大的。

分布式架構(gòu)

分布式架構(gòu)相對于單體架構(gòu)而言，通過拆分解決了單體架構(gòu)面臨的大部分問題，例如性能瓶頸。假如單體架構(gòu)是一頭牛，那么分布式架構(gòu)就是多頭牛：

當單體架構(gòu)出現(xiàn)性能瓶頸時，團隊可以考慮將單體架構(gòu)轉(zhuǎn)換為分布式架構(gòu)，以增強服務能力。當然，分布式并不是萬能的，它解決了單體架構(gòu)性能瓶頸、可靠性低的問題，但復雜性問題、技術(shù)創(chuàng)新問題和發(fā)布頻率低依然存在，這時候可以考慮微服務。

微服務架構(gòu)

微服務架構(gòu)的關(guān)鍵字是拆，將原本糅合在一個應用中的多個功能拆成多個小應用，這些小應用串聯(lián)起來組成一個與之前單體架構(gòu)功能相同的完整應用。具體示意如下：

每個微服務可以獨立運行，它們之間通過網(wǎng)絡(luò)協(xié)議進行交互。每個微服務可以部署多個實例，這樣一來就具備了跟分布式架構(gòu)相同的性能。單個服務的發(fā)布/部署對其它服務的影響較小，在代碼上沒有關(guān)聯(lián)，因此可以頻繁的發(fā)布新版本。復雜性的問題迎刃而解，拆分之后架構(gòu)邏輯清晰、功能模塊職責單一，功能的增加和代碼的增加也不會影響到整體效率。服務獨立之后，項目就變得語言無關(guān)，評價服務可以用 Java 語言來實現(xiàn)也可以用 Golang 語言實現(xiàn)，不再受到語言或者框架的制約，技術(shù)創(chuàng)新問題得以緩解。

這是不是很像單一職責原則和接口隔離原則？

分布式和微服務并不是銀彈

從上面的對比來看，似乎分布式架構(gòu)比單體架構(gòu)好，微服務架構(gòu)比分布式架構(gòu)好，這么說來微服務架構(gòu)>分布式架構(gòu)>單體架構(gòu)？

這么理解是不對的，架構(gòu)需要根據(jù)場景和需求選擇，微服務架構(gòu)和分布式架構(gòu)看上去很美，但也衍生出了許多新問題。以微服務架構(gòu)為例：

•運維成本高，在單體架構(gòu)時，運維只需要保證 1 個應用正常運行即可，關(guān)注的可能只是硬件資源消耗問題。但如果換成微服務架構(gòu)，應用的數(shù)量成百上千，當應用出現(xiàn)問題或者多應用之間協(xié)調(diào)異常時，運維人員的頭就會變大；
•分布式系統(tǒng)固有的復雜性，網(wǎng)絡(luò)分區(qū)、分布式事務、流量均衡對開發(fā)者和運維進行了敲打；
•接口調(diào)整成本高，一個接口的調(diào)用方可能有很多個，如果設(shè)計時沒有遵循開放封閉原則和接口隔離原則，那么調(diào)整的工作量會是非常大的；
•接口性能受限，原本通過函數(shù)調(diào)用的方式交互，在內(nèi)存中很快就完成了，換成接口后通過網(wǎng)絡(luò)進行交互，性能明顯下降；
•重復勞動，雖然有公共模塊，但如果語言無關(guān)且又要考慮性能（不用接口交互）就需要自己實現(xiàn)一份相同功能的代碼；

到底用哪種架構(gòu)，需要根據(jù)具體的場景來選擇。如果你的系統(tǒng)復雜度并沒有那么高、性能追求也沒有那么高，例如一個日數(shù)據(jù)量只有幾萬的爬蟲應用，單體架構(gòu)就足以解決問題，不需要強行做成分布式或者微服務，因為這樣只會增加自己的工作量。

畫好圖

在需要表達關(guān)系和邏輯梳理的場景里，圖永遠比代碼好。業(yè)內(nèi)流行這么一句話“程序開發(fā)，設(shè)計先行”，說的是在開發(fā)前，需要對程序進行構(gòu)思和設(shè)計。試想，如果連對象關(guān)系和邏輯都說不清楚，寫出的代碼會是好代碼嗎？

在構(gòu)思項目時可以使用用例圖挖掘需求和功能模塊；在架構(gòu)設(shè)計時可以使用協(xié)作圖梳理模塊關(guān)系；在設(shè)計接口或者類對象時可以使用類圖做好交互計劃；在功能設(shè)計時可以使用狀態(tài)圖幫助我們挖掘功能屬性……

了解繪圖的重要性之后，具體的繪圖方法和技巧可翻閱本書（《Python 編程參考》）的工程師繪圖指南章節(jié)展開學習。

起一個好名字

你還記得自己曾經(jīng)起過的那些名字嗎：

•reversalList
•get_translation
•get_data
•do_trim
•CarAbstract

起一個好的、合適的名字能夠讓代碼風格更統(tǒng)一，看上去清晰了然。起一個好名字不單單是單詞語法的問題，還會涉及風格選擇和用途。具體的命名方法和技巧可翻閱本書（《Python 編程參考》）的命名選擇與風格指南章節(jié)展開學習。

優(yōu)化嵌套的 if else 代碼

寫代碼的時候用一些控制語句是很正常的事，但是如果 if else 嵌套太多，也是非常頭疼的，代碼看上去就像下面這樣。

這種結(jié)構(gòu)的產(chǎn)生是因為使用了 if 語句來進行先決條件的檢查，如果負責條件則進入下一行代碼，如果不符合則停止。既然這樣，那我們在先決條件的檢查上進行取反即可，代碼改動過后看起來像這樣：

if "http" not in url:
        return
if "www" not in url:
        return

這是我平時常用的優(yōu)化辦法，后來在張曄老師的付費專欄中看到這種手段的名稱——衛(wèi)語句。
當然，這種簡單的邏輯處理和 if else 控制流用衛(wèi)語句進行處理是很有效的，但如果邏輯再復雜一些，用衛(wèi)語句的效果就不見的那么好了。假設(shè)汽車 4S 店有折扣權(quán)限限制，普通銷售有權(quán)對 30 萬以內(nèi)金額的汽車授予一定折扣，超過 30 萬但在 80 萬以內(nèi)需要精英銷售進行授權(quán)，更高價格的車折扣需要店長授權(quán)。這個功能可以歸納為根據(jù)金額的大小來確定授權(quán)者，對應代碼如下：

def buying_car(price):
    if price  300000:
        print("普通銷售")
    elif price  800000:
        print("精英銷售")
    elif price  1500000:
        print("店長")

代碼思路清晰，但存在的問題也明顯。如果以后擴展價格和定級，會增加更多的 if else 語句，代碼將變得臃腫?？刂普Z句的順序是固定在代碼中的，如果想要調(diào)整順序，只能修改控制語句。

那么問題來了，有比 if else 更合適的辦法嗎？

這時候可以考慮一種叫做責任鏈的設(shè)計模式，責任鏈設(shè)計模式的定義為：為了避免請求發(fā)送者與多個請求處理者耦合在一起，于是將所有請求的處理者通過前一對象記住其下一個對象的引用而連成一條鏈；當有請求發(fā)生時，可將請求沿著這條鏈傳遞，直到有對象處理它為止。

看起來有點繞，我們通過代碼圖加深理解：

處理類執(zhí)行前根據(jù)先決條件判斷自身的 handler 是否能夠處理，如果不能則交給 next_handler，也就是責任鏈的下一個節(jié)點。上面的用責任鏈實現(xiàn)為：

class Manager:

    def __init__(self,):
        self.obj = None

    def next_handler(self, obj):
        self.obj = obj

    def handler(self, price):
        pass


class General(Manager):

    def handler(self, price):
        if price  300000:
            print("{} 普通銷售".format(price))
        else:
            self.obj.handler(price)


class Elite(Manager):

    def handler(self, price):
        if 300000 = price  800000:
            print("{} 精英銷售".format(price))
        else:
            self.obj.handler(price)


class BOSS(Manager):

    def handler(self, price):
        if price >= 800000:
            print("{} 店長".format(price))

創(chuàng)建好抽象類和具體的處理類之后，它們還沒有關(guān)聯(lián)關(guān)系。我們需要將它們掛載到一起，成為一個鏈條：

general = General()
elite = Elite()
boss = BOSS()
general.next_handler(elite)
elite.next_handler(boss)

這里建立的責任鏈順序為 General -> Elite -> BOSS，調(diào)用方只需要傳遞價格給 General，如果它沒有折扣的授予權(quán)它會交給 Elite 處理，如果 Elite 沒有折扣授予權(quán)則會交給 BOSS 處理。對應代碼如下:

    prices = [550000, 220000, 1500000, 200000, 330000]
    for price in prices:
        general.handler(price)  

這跟我們?nèi)?4S 店購車是一樣的，作為客戶，我們確定好要買的車即可，至于 4S 店如何申請折扣，誰來授權(quán)與我無關(guān)，我能拿到相應的折扣即可。

至此，if else 優(yōu)化知識學習完畢。

做到以上幾點，相信你的代碼質(zhì)量和程序設(shè)計水平會有一個不錯的提升，加油！

以上就是寫好Python代碼的幾條重要技巧的詳細內(nèi)容，更多關(guān)于python代碼技巧的資料請關(guān)注腳本之家其它相關(guān)文章！