程序設(shè)計(jì)的好與壞，早在我們青蔥歲月時(shí)就接觸過(guò)了，只是那是并不知道這竟如此重要。能夠立即改善程序設(shè)計(jì)、寫(xiě)出“好”代碼的知識(shí)有以下幾點(diǎn)：
?面向?qū)ο笪鍌€(gè)基本原則；
?常見(jiàn)的三種架構(gòu)；
?繪圖；
?起一個(gè)好名字；
?優(yōu)化嵌套的 if else 代碼；
當(dāng)然，其他技術(shù)知識(shí)的豐富程度也決定了程序設(shè)計(jì)的好壞。例如通過(guò)引入消息隊(duì)列解決雙端性能差異問(wèn)題、通過(guò)增加緩存層提高查詢(xún)效率等。下面我們一起來(lái)看看，上面列出的知識(shí)點(diǎn)包含哪些內(nèi)容，這些內(nèi)容對(duì)代碼和程序設(shè)計(jì)的改善有何幫助。
面向?qū)ο笪鍌€(gè)基本原則
本書(shū)作者是 2010 級(jí)學(xué)生，面向?qū)ο笫亲髡咔嗍[時(shí)期發(fā)展火熱的編程范式。它的五個(gè)基本原則是：
?單一職責(zé)原則；
?開(kāi)放封閉原則；
?依賴(lài)倒置原則；
?接口隔離原則；
?合成復(fù)用原則；
下面我們將通過(guò)對(duì)比和場(chǎng)景假設(shè)的方式了解五個(gè)基本原則對(duì)代碼質(zhì)量的影響。
立竿見(jiàn)影的單一職責(zé)原則
沒(méi)錯(cuò)，立竿見(jiàn)影、效果卓越。對(duì)于我們這些自學(xué)編程無(wú)師自通的人來(lái)說(shuō)，能把功能實(shí)現(xiàn)就可以了，根本沒(méi)有時(shí)間考慮代碼優(yōu)化和維護(hù)成本問(wèn)題。時(shí)光流逝，竟在接觸編程很長(zhǎng)一段時(shí)間后才發(fā)現(xiàn)它竟如此重要。
俗話(huà)說(shuō)只要代碼寫(xiě)的夠爛，提升就足夠明顯。以一個(gè)從文件內(nèi)容中匹配關(guān)鍵數(shù)據(jù)并根據(jù)匹配結(jié)果發(fā)出網(wǎng)絡(luò)請(qǐng)求的案例，看看大部分程序員的寫(xiě)法：
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)實(shí)現(xiàn)，這點(diǎn)毋庸置疑，但是問(wèn)題來(lái)了：
?如果讀取文件的時(shí)候發(fā)生異常了怎么辦？
?如果數(shù)據(jù)源發(fā)生變化該如何處理？
?如果網(wǎng)絡(luò)請(qǐng)求返回的數(shù)據(jù)不符合最終要求怎么辦？
如果你心里的第一個(gè)反應(yīng)是改代碼，那你就要注意了。完成一件事中間的某個(gè)環(huán)節(jié)發(fā)生變化，改代碼是在所難免的，但是如果按照上面這種寫(xiě)法，不僅代碼越改越亂，連邏輯也會(huì)越來(lái)越亂。單一職責(zé)原則表達(dá)的是讓一個(gè)函數(shù)盡量只做一件事，不要將多件事混雜在一個(gè)函數(shù)中。
上面的代碼如果重新設(shè)計(jì)，我認(rèn)為至少應(yīng)該是這樣的：
def get_source():
"""獲取數(shù)據(jù)源"""
return
def extract_(val):
"""匹配關(guān)鍵數(shù)據(jù)"""
return
def fetch(val):
"""發(fā)出網(wǎng)絡(luò)請(qǐng)求"""
return
def trim(val):
"""修剪數(shù)據(jù)"""
return
def extract(file):
"""提取目標(biāo)數(shù)據(jù)"""
source = get_source()
content = extract_(source)
text = trim(fetch(content))
return text
if __name__ == "__main__":
text = extract(FILE)
print(text)把原來(lái)放在一個(gè)函數(shù)中實(shí)現(xiàn)的多個(gè)步驟拆分成為多個(gè)更小的函數(shù)，每個(gè)函數(shù)只做一件事。當(dāng)數(shù)據(jù)源發(fā)生變化時(shí)，只需要改動(dòng) get_source 相關(guān)的代碼即可；如果網(wǎng)絡(luò)請(qǐng)求返回的數(shù)據(jù)不符合最終要求，我們可以在 trim 函數(shù)中對(duì)它進(jìn)行修剪。這樣一來(lái)，代碼應(yīng)對(duì)變化的能力提高了許多，整個(gè)流程也變得更清晰易懂。改動(dòng)前后的變化如下圖所示：
單一職責(zé)原則的核心是解耦和增強(qiáng)內(nèi)聚力，如果一個(gè)函數(shù)承擔(dān)的職責(zé)過(guò)多，等于把這些職責(zé)耦合在一起，這種耦合會(huì)導(dǎo)致脆弱的設(shè)計(jì)。當(dāng)發(fā)生變化時(shí)，原本的設(shè)計(jì)會(huì)遭受到意想不到的破壞。單一職責(zé)原則實(shí)際上是把一件事拆分成多個(gè)步驟，代碼修改造成的影響范圍很小。
讓代碼穩(wěn)定性飛升的開(kāi)放封閉原則和依賴(lài)倒置原則
開(kāi)放封閉原則中的開(kāi)放指的是對(duì)擴(kuò)展開(kāi)放，封閉指的是對(duì)修改封閉。需求總是變化的，業(yè)務(wù)方這個(gè)月讓你把數(shù)據(jù)存儲(chǔ)到 MySQL 數(shù)據(jù)庫(kù)中，下個(gè)月就有可能讓你導(dǎo)出到 Excel 表格里，這時(shí)候你就得改代碼了。這個(gè)場(chǎng)景和上面的單一職責(zé)原則很相似，同樣面臨代碼改動(dòng)，單一職責(zé)原則示例主要表達(dá)的是通過(guò)解耦降低改動(dòng)的影響，這里主要表達(dá)的是通過(guò)對(duì)擴(kuò)展開(kāi)放、對(duì)修改封閉提高程序應(yīng)對(duì)變化的能力和提高程序穩(wěn)定性。
穩(wěn)定這個(gè)詞如何理解呢？
較少的改動(dòng)或者不改動(dòng)即視為穩(wěn)定，穩(wěn)定意味著調(diào)用這個(gè)對(duì)象的其它代碼拿到的結(jié)果是可以確定的，整體是穩(wěn)定的。
按照一般程序員的寫(xiě)法，數(shù)據(jù)存儲(chǔ)的代碼大概是這樣的：
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)的，這點(diǎn)毋庸置疑。來(lái)看看它如何應(yīng)對(duì)變化，如果要更換存儲(chǔ)，那么就意味著需要改代碼。按照上面的代碼示例，有兩個(gè)選擇：
?重新寫(xiě)一個(gè)存儲(chǔ)到 ExcelSave 的類(lèi)；
?對(duì) MySQLSave 類(lèi)進(jìn)行改動(dòng)；
上面的兩種選擇，無(wú)論怎么選都會(huì)改動(dòng) 2 個(gè)類(lèi)。因?yàn)椴粌H存儲(chǔ)的類(lèi)需要改動(dòng)，調(diào)用處的代碼也需要更改。這樣一來(lái)，它們整體都是不穩(wěn)定的。如果換一種實(shí)現(xiàn)方式，根據(jù)依賴(lài)倒置的設(shè)計(jì)指導(dǎo)可以輕松應(yīng)對(duì)這個(gè)問(wèn)題。邊看代碼邊理解：
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)這里通過(guò)內(nèi)置的 abc 實(shí)現(xiàn)了一個(gè)抽象基類(lèi)，這個(gè)基類(lèi)的目的是強(qiáng)制子類(lèi)實(shí)現(xiàn)要求的方法，以達(dá)到子類(lèi)功能統(tǒng)一。子類(lèi)功能統(tǒng)一后，無(wú)論調(diào)用它的哪個(gè)子類(lèi)，都是穩(wěn)定的，不會(huì)出現(xiàn)調(diào)用方還需要修改方法名或者修改傳入?yún)?shù)的情況。
依賴(lài)倒置中的倒置，指的是依賴(lài)關(guān)系的倒置。之前的代碼是調(diào)用方 Business 依賴(lài)對(duì)象 MySQLSave，一旦對(duì)象 MySQLSave 需要被替換， Business 就需要改動(dòng)。依賴(lài)倒置中的依賴(lài)指的是對(duì)象的依賴(lài)關(guān)系，之前依賴(lài)的是實(shí)體，如果改為后面這種依賴(lài)抽象的方式，情況就會(huì)扭轉(zhuǎn)過(guò)來(lái)：
實(shí)體 Business 依賴(lài)抽象有一個(gè)好處：抽象穩(wěn)定。相對(duì)于多變的實(shí)體來(lái)說(shuō)，抽象更穩(wěn)定。代碼改動(dòng)前后的依賴(lài)關(guān)系發(fā)生了重大變化，之前調(diào)用方 Business 直接依賴(lài)于實(shí)體 MySQLSave，通過(guò)依賴(lài)倒置改造后 Busines 和 ExcelSave、 MySQLSave 全都依賴(lài)抽象。
這樣做的好處是如果需要更換存儲(chǔ)，只需要?jiǎng)?chuàng)建一個(gè)新的存儲(chǔ)實(shí)體，然后調(diào)用 Business 時(shí)傳遞進(jìn)去即可，這樣可以不用改動(dòng) Business 的代碼，符合面向修改封閉、面向擴(kuò)展開(kāi)放的開(kāi)放封閉原則；
依賴(lài)倒置的具體實(shí)現(xiàn)方式使用了一種叫做依賴(lài)注入的手段，實(shí)際上單純使用依賴(lài)注入、不使用依賴(lài)倒置也可以滿(mǎn)足開(kāi)閉原則要求，感興趣的讀者不妨試一試。
挑肥揀瘦的接口隔離原則
接口隔離原則中的接口指的是 Interface，而不是 Web 應(yīng)用里面的 Restful 接口，但是在實(shí)際應(yīng)用中可以將其抽象理解為相同的對(duì)象。接口隔離原則在設(shè)計(jì)層面看，跟單一職責(zé)原則的目的是一致的。接口隔離原則的指導(dǎo)思想是：
?調(diào)用方不應(yīng)該依賴(lài)它不需要的接口；
?依賴(lài)關(guān)系應(yīng)當(dāng)建立在最小接口上；
這實(shí)際上是告訴我們要給接口減肥，過(guò)多功能的接口可以選用拆分的方式優(yōu)化。舉個(gè)例子，現(xiàn)在為圖書(shū)館設(shè)計(jì)一個(gè)圖書(shū)的抽象類(lèi)：
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圖可以被購(gòu)買(mǎi)、可以被借閱、可以下架、可以上架，這看起來(lái)并沒(méi)有什么問(wèn)題。但這樣一來(lái)這個(gè)抽象只能提供給管理人員使用，用戶(hù)操作時(shí)需要再設(shè)定一個(gè)新的抽象類(lèi)，因?yàn)槟悴豢赡茏層脩?hù)可以操縱圖書(shū)上下架。接口隔離原則推薦的做法是把圖書(shū)的上下架和圖書(shū)購(gòu)買(mǎi)、借閱分成 2 個(gè)抽象類(lèi)，管理端的圖書(shū)類(lèi)繼承 2 個(gè)抽象類(lèi)，用戶(hù)端的圖書(shū)類(lèi)繼承 1 個(gè)抽象類(lèi)。這么看起來(lái)是有點(diǎn)繞，不要慌，我們看圖理解：
這樣是不是一下就看懂了。這個(gè)指導(dǎo)思想很重要，不僅能夠指導(dǎo)我們?cè)O(shè)計(jì)抽象接口，也能夠指導(dǎo)我們?cè)O(shè)計(jì) Restful 接口，還能夠幫助我們發(fā)現(xiàn)現(xiàn)有接口存在的問(wèn)題，從而設(shè)計(jì)出更合理的程序。
輕裝上陣的合成復(fù)用原則
合成復(fù)用原則的指導(dǎo)思想是：盡量使用對(duì)象組合，而不是繼承來(lái)達(dá)到復(fù)用的目的。合成復(fù)用的作用是降低對(duì)象之間的依賴(lài)，因?yàn)槔^承是強(qiáng)依賴(lài)關(guān)系，無(wú)論子類(lèi)使用到父類(lèi)的哪幾個(gè)屬性，子類(lèi)都需要完全擁有父類(lèi)。合成采用另一種方式實(shí)現(xiàn)對(duì)象之間的關(guān)聯(lián)，降低依賴(lài)關(guān)系。
為什么推薦優(yōu)先使用合成復(fù)用，而后考慮繼承呢？
因?yàn)槔^承的強(qiáng)依賴(lài)關(guān)系，一旦被依賴(lài)的對(duì)象（父類(lèi)）發(fā)生改變，那么依賴(lài)者（子類(lèi)）也需要改變，合成復(fù)用則可以避免這樣的情況出現(xiàn)。要注意的是，推薦優(yōu)先使用復(fù)用，但并不是拒絕使用繼承，該用的地方還得用。我們以一段代碼為例，說(shuō)明合成復(fù)用和繼承的差異：
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 作為父類(lèi)，擁有 move 和 engine 2 個(gè)重要屬性，這時(shí)候如果需要給汽車(chē)涂裝顏色，那么就要新增一個(gè) color 屬性，3 個(gè)類(lèi)都要增加。如果使用合成復(fù)用的方式，可以這么寫(xiě)：
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類(lèi)對(duì)象合成復(fù)用的具體操作是在類(lèi)中實(shí)例化一個(gè)類(lèi)對(duì)象，然后在需要的時(shí)候調(diào)用它。代碼可能沒(méi)有那么直觀，我們看圖：
這個(gè)例子主要用于說(shuō)明繼承和合成復(fù)用的具體實(shí)現(xiàn)方式和前后變化，對(duì)于 Car 的繼承無(wú)需深究，因?yàn)槿绻銏?zhí)著地討論為什么右圖中的 2 個(gè) Car 不用繼承，就會(huì)陷入牛角尖。
這里的合成復(fù)用選用的實(shí)現(xiàn)方式是在 2 個(gè) Car 里面實(shí)例化另一個(gè)類(lèi) Color，其實(shí)也可以用依賴(lài)注入的手段在外部實(shí)例化 Color，然后把實(shí)例對(duì)象傳遞給 2 個(gè) Car。
常見(jiàn)的三種架構(gòu)
了解多種不同的架構(gòu)可以使我們的知識(shí)面更寬廣，面對(duì)一類(lèi)問(wèn)題的時(shí)候可以提出其它解決辦法。同時(shí)，了解多種架構(gòu)可以讓我們?cè)谠O(shè)計(jì)階段做好規(guī)劃，避免后續(xù)頻繁的重構(gòu)。常見(jiàn)的三種架構(gòu)分別是：
?單體架構(gòu)；
?分布式架構(gòu)；
?微服務(wù)架構(gòu)；
單體架構(gòu)
單體架構(gòu)是我們平時(shí)接觸較多的架構(gòu)，也是相對(duì)容易理解的架構(gòu)。單體架構(gòu)把所有功能都聚合在一個(gè)應(yīng)用里，我們可以簡(jiǎn)單地將這種架構(gòu)視作：
這種架構(gòu)簡(jiǎn)單、容易部署和測(cè)試，大部分應(yīng)用的初期都采用單體架構(gòu)。單體架構(gòu)也有幾個(gè)明顯缺點(diǎn)：
?復(fù)雜性高，所有功能糅合在一個(gè)應(yīng)用里，模塊多、容易出現(xiàn)邊界模糊，而且隨著時(shí)間的推移和業(yè)務(wù)的發(fā)展，項(xiàng)目越來(lái)越大、代碼越來(lái)越多，整體服務(wù)效率逐漸下降；
?發(fā)布/部署頻率低，牽一發(fā)而動(dòng)全身，新功能或問(wèn)題修復(fù)的發(fā)布上線(xiàn)需要多方協(xié)調(diào)，發(fā)布時(shí)間一拖再拖。項(xiàng)目大則構(gòu)建時(shí)間長(zhǎng)、構(gòu)建失敗的幾率也會(huì)有所增加；
?性能瓶頸明顯，一頭牛再厲害也抵不過(guò)多頭牛合力的效果，隨著數(shù)據(jù)量、請(qǐng)求并發(fā)的增加，讀性能的不足最先暴露出來(lái)，接著你就會(huì)發(fā)現(xiàn)其它方面也跟不上了；
?影響技術(shù)創(chuàng)新：?jiǎn)误w架構(gòu)通常選用一類(lèi)語(yǔ)言或一類(lèi)框架統(tǒng)一開(kāi)發(fā)，想要引入新技術(shù)或者接入現(xiàn)代化的服務(wù)是很困難的；
?可靠性低，一旦服務(wù)出現(xiàn)問(wèn)題，影響是巨大的。
分布式架構(gòu)
分布式架構(gòu)相對(duì)于單體架構(gòu)而言，通過(guò)拆分解決了單體架構(gòu)面臨的大部分問(wèn)題，例如性能瓶頸。假如單體架構(gòu)是一頭牛，那么分布式架構(gòu)就是多頭牛：
當(dāng)單體架構(gòu)出現(xiàn)性能瓶頸時(shí)，團(tuán)隊(duì)可以考慮將單體架構(gòu)轉(zhuǎn)換為分布式架構(gòu)，以增強(qiáng)服務(wù)能力。當(dāng)然，分布式并不是萬(wàn)能的，它解決了單體架構(gòu)性能瓶頸、可靠性低的問(wèn)題，但復(fù)雜性問(wèn)題、技術(shù)創(chuàng)新問(wèn)題和發(fā)布頻率低依然存在，這時(shí)候可以考慮微服務(wù)。
微服務(wù)架構(gòu)
微服務(wù)架構(gòu)的關(guān)鍵字是拆，將原本糅合在一個(gè)應(yīng)用中的多個(gè)功能拆成多個(gè)小應(yīng)用，這些小應(yīng)用串聯(lián)起來(lái)組成一個(gè)與之前單體架構(gòu)功能相同的完整應(yīng)用。具體示意如下：
每個(gè)微服務(wù)可以獨(dú)立運(yùn)行，它們之間通過(guò)網(wǎng)絡(luò)協(xié)議進(jìn)行交互。每個(gè)微服務(wù)可以部署多個(gè)實(shí)例，這樣一來(lái)就具備了跟分布式架構(gòu)相同的性能。單個(gè)服務(wù)的發(fā)布/部署對(duì)其它服務(wù)的影響較小，在代碼上沒(méi)有關(guān)聯(lián)，因此可以頻繁的發(fā)布新版本。復(fù)雜性的問(wèn)題迎刃而解，拆分之后架構(gòu)邏輯清晰、功能模塊職責(zé)單一，功能的增加和代碼的增加也不會(huì)影響到整體效率。服務(wù)獨(dú)立之后，項(xiàng)目就變得語(yǔ)言無(wú)關(guān)，評(píng)價(jià)服務(wù)可以用 Java 語(yǔ)言來(lái)實(shí)現(xiàn)也可以用 Golang 語(yǔ)言實(shí)現(xiàn)，不再受到語(yǔ)言或者框架的制約，技術(shù)創(chuàng)新問(wèn)題得以緩解。
這是不是很像單一職責(zé)原則和接口隔離原則？
分布式和微服務(wù)并不是銀彈
從上面的對(duì)比來(lái)看，似乎分布式架構(gòu)比單體架構(gòu)好，微服務(wù)架構(gòu)比分布式架構(gòu)好，這么說(shuō)來(lái)微服務(wù)架構(gòu)>分布式架構(gòu)>單體架構(gòu)？
這么理解是不對(duì)的，架構(gòu)需要根據(jù)場(chǎng)景和需求選擇，微服務(wù)架構(gòu)和分布式架構(gòu)看上去很美，但也衍生出了許多新問(wèn)題。以微服務(wù)架構(gòu)為例：
?運(yùn)維成本高，在單體架構(gòu)時(shí)，運(yùn)維只需要保證 1 個(gè)應(yīng)用正常運(yùn)行即可，關(guān)注的可能只是硬件資源消耗問(wèn)題。但如果換成微服務(wù)架構(gòu)，應(yīng)用的數(shù)量成百上千，當(dāng)應(yīng)用出現(xiàn)問(wèn)題或者多應(yīng)用之間協(xié)調(diào)異常時(shí)，運(yùn)維人員的頭就會(huì)變大；
?分布式系統(tǒng)固有的復(fù)雜性，網(wǎng)絡(luò)分區(qū)、分布式事務(wù)、流量均衡對(duì)開(kāi)發(fā)者和運(yùn)維進(jìn)行了敲打；
?接口調(diào)整成本高，一個(gè)接口的調(diào)用方可能有很多個(gè)，如果設(shè)計(jì)時(shí)沒(méi)有遵循開(kāi)放封閉原則和接口隔離原則，那么調(diào)整的工作量會(huì)是非常大的；
?接口性能受限，原本通過(guò)函數(shù)調(diào)用的方式交互，在內(nèi)存中很快就完成了，換成接口后通過(guò)網(wǎng)絡(luò)進(jìn)行交互，性能明顯下降；
?重復(fù)勞動(dòng)，雖然有公共模塊，但如果語(yǔ)言無(wú)關(guān)且又要考慮性能（不用接口交互）就需要自己實(shí)現(xiàn)一份相同功能的代碼；
到底用哪種架構(gòu)，需要根據(jù)具體的場(chǎng)景來(lái)選擇。如果你的系統(tǒng)復(fù)雜度并沒(méi)有那么高、性能追求也沒(méi)有那么高，例如一個(gè)日數(shù)據(jù)量只有幾萬(wàn)的爬蟲(chóng)應(yīng)用，單體架構(gòu)就足以解決問(wèn)題，不需要強(qiáng)行做成分布式或者微服務(wù)，因?yàn)檫@樣只會(huì)增加自己的工作量。
畫(huà)好圖
在需要表達(dá)關(guān)系和邏輯梳理的場(chǎng)景里，圖永遠(yuǎn)比代碼好。業(yè)內(nèi)流行這么一句話(huà)“程序開(kāi)發(fā)，設(shè)計(jì)先行”，說(shuō)的是在開(kāi)發(fā)前，需要對(duì)程序進(jìn)行構(gòu)思和設(shè)計(jì)。試想，如果連對(duì)象關(guān)系和邏輯都說(shuō)不清楚，寫(xiě)出的代碼會(huì)是好代碼嗎？
在構(gòu)思項(xiàng)目時(shí)可以使用用例圖挖掘需求和功能模塊；在架構(gòu)設(shè)計(jì)時(shí)可以使用協(xié)作圖梳理模塊關(guān)系；在設(shè)計(jì)接口或者類(lèi)對(duì)象時(shí)可以使用類(lèi)圖做好交互計(jì)劃；在功能設(shè)計(jì)時(shí)可以使用狀態(tài)圖幫助我們挖掘功能屬性……
了解繪圖的重要性之后，具體的繪圖方法和技巧可翻閱本書(shū)（《Python 編程參考》）的工程師繪圖指南章節(jié)展開(kāi)學(xué)習(xí)。
起一個(gè)好名字
你還記得自己曾經(jīng)起過(guò)的那些名字嗎：
?reversalList
?get_translation
?get_data
?do_trim
?CarAbstract
起一個(gè)好的、合適的名字能夠讓代碼風(fēng)格更統(tǒng)一，看上去清晰了然。起一個(gè)好名字不單單是單詞語(yǔ)法的問(wèn)題，還會(huì)涉及風(fēng)格選擇和用途。具體的命名方法和技巧可翻閱本書(shū)（《Python 編程參考》）的命名選擇與風(fēng)格指南章節(jié)展開(kāi)學(xué)習(xí)。
優(yōu)化嵌套的 if else 代碼
寫(xiě)代碼的時(shí)候用一些控制語(yǔ)句是很正常的事，但是如果 if else 嵌套太多，也是非常頭疼的，代碼看上去就像下面這樣。
這種結(jié)構(gòu)的產(chǎn)生是因?yàn)槭褂昧?if 語(yǔ)句來(lái)進(jìn)行先決條件的檢查，如果負(fù)責(zé)條件則進(jìn)入下一行代碼，如果不符合則停止。既然這樣，那我們?cè)谙葲Q條件的檢查上進(jìn)行取反即可，代碼改動(dòng)過(guò)后看起來(lái)像這樣：
if "http" not in url:
return
if "www" not in url:
return這是我平時(shí)常用的優(yōu)化辦法，后來(lái)在張曄老師的付費(fèi)專(zhuān)欄中看到這種手段的名稱(chēng)——衛(wèi)語(yǔ)句。
當(dāng)然，這種簡(jiǎn)單的邏輯處理和 if else 控制流用衛(wèi)語(yǔ)句進(jìn)行處理是很有效的，但如果邏輯再?gòu)?fù)雜一些，用衛(wèi)語(yǔ)句的效果就不見(jiàn)的那么好了。假設(shè)汽車(chē) 4S 店有折扣權(quán)限限制，普通銷(xiāo)售有權(quán)對(duì) 30 萬(wàn)以?xún)?nèi)金額的汽車(chē)授予一定折扣，超過(guò) 30 萬(wàn)但在 80 萬(wàn)以?xún)?nèi)需要精英銷(xiāo)售進(jìn)行授權(quán)，更高價(jià)格的車(chē)折扣需要店長(zhǎng)授權(quán)。這個(gè)功能可以歸納為根據(jù)金額的大小來(lái)確定授權(quán)者，對(duì)應(yīng)代碼如下：
def buying_car(price):
if price < 300000:
print("普通銷(xiāo)售")
elif price < 800000:
print("精英銷(xiāo)售")
elif price < 1500000:
print("店長(zhǎng)")代碼思路清晰，但存在的問(wèn)題也明顯。如果以后擴(kuò)展價(jià)格和定級(jí)，會(huì)增加更多的 if else 語(yǔ)句，代碼將變得臃腫。控制語(yǔ)句的順序是固定在代碼中的，如果想要調(diào)整順序，只能修改控制語(yǔ)句。
那么問(wèn)題來(lái)了，有比 if else 更合適的辦法嗎？
這時(shí)候可以考慮一種叫做責(zé)任鏈的設(shè)計(jì)模式，責(zé)任鏈設(shè)計(jì)模式的定義為：為了避免請(qǐng)求發(fā)送者與多個(gè)請(qǐng)求處理者耦合在一起，于是將所有請(qǐng)求的處理者通過(guò)前一對(duì)象記住其下一個(gè)對(duì)象的引用而連成一條鏈；當(dāng)有請(qǐng)求發(fā)生時(shí)，可將請(qǐng)求沿著這條鏈傳遞，直到有對(duì)象處理它為止。
看起來(lái)有點(diǎn)繞，我們通過(guò)代碼圖加深理解：
處理類(lèi)執(zhí)行前根據(jù)先決條件判斷自身的 handler 是否能夠處理，如果不能則交給 next_handler，也就是責(zé)任鏈的下一個(gè)節(jié)點(diǎn)。上面的用責(zé)任鏈實(shí)現(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("{} 普通銷(xiāo)售".format(price))
else:
self.obj.handler(price)
class Elite(Manager):
def handler(self, price):
if 300000 <= price < 800000:
print("{} 精英銷(xiāo)售".format(price))
else:
self.obj.handler(price)
class BOSS(Manager):
def handler(self, price):
if price >= 800000:
print("{} 店長(zhǎng)".format(price))創(chuàng)建好抽象類(lèi)和具體的處理類(lèi)之后，它們還沒(méi)有關(guān)聯(lián)關(guān)系。我們需要將它們掛載到一起，成為一個(gè)鏈條：
general = General()
elite = Elite()
boss = BOSS()
general.next_handler(elite)
elite.next_handler(boss)這里建立的責(zé)任鏈順序?yàn)?General -> Elite -> BOSS，調(diào)用方只需要傳遞價(jià)格給 General，如果它沒(méi)有折扣的授予權(quán)它會(huì)交給 Elite 處理，如果 Elite 沒(méi)有折扣授予權(quán)則會(huì)交給 BOSS 處理。對(duì)應(yīng)代碼如下:
prices = [550000, 220000, 1500000, 200000, 330000]
for price in prices:
general.handler(price) 這跟我們?nèi)?4S 店購(gòu)車(chē)是一樣的，作為客戶(hù)，我們確定好要買(mǎi)的車(chē)即可，至于 4S 店如何申請(qǐng)折扣，誰(shuí)來(lái)授權(quán)與我無(wú)關(guān)，我能拿到相應(yīng)的折扣即可。
至此，if else 優(yōu)化知識(shí)學(xué)習(xí)完畢。
做到以上幾點(diǎn)，相信你的代碼質(zhì)量和程序設(shè)計(jì)水平會(huì)有一個(gè)不錯(cuò)的提升，加油！
結(jié)尾
以上就是怎么寫(xiě)好python代碼的詳細(xì)內(nèi)容，更多python編程技巧請(qǐng)關(guān)注W3Cschool其它相關(guān)文章！
