寫好 Python 代碼的重要技巧

来源:https://www.cnblogs.com/123456feng/archive/2022/03/31/16081681.html
-Advertisement-
Play Games

如何才能寫好Python代碼？很多小伙伴都會問這樣的問題，今天這篇就來告訴大家怎樣寫好Python代碼。 程式設計的好與壞，早在我們青蔥歲月時就接觸過了，只是那是並不知道這竟如此重要。能夠立即改善程式設計、寫出“好”代碼的知識有以下幾點： •面向對象五個基本原則； •常見的三種架構； •繪圖； •起 ...


如何才能寫好Python代碼？很多小伙伴都會問這樣的問題，今天這篇就來告訴大家怎樣寫好Python代碼。
在這裡插入圖片描述

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

•面向對象五個基本原則；

•常見的三種架構；

•繪圖；

•起一個好名字；

•優化嵌套的 if else 代碼；

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

在這裡插入圖片描述

面向對象五個基本原則

本書作者是 2010 級學生，面向對象是作者青蔥時期發展火熱的編程範式。它的五個基本原則是：

•單一職責原則；

•開放封閉原則；

•依賴倒置原則；

•介面隔離原則；

•合成復用原則；

下麵我們將通過對比和場景假設的方式瞭解五個基本原則對代碼質量的影響。

立竿見影的單一職責原則

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

俗話說只要代碼寫的夠爛，提升就足夠明顯。以一個從文件內容中匹配關鍵數據並根據匹配結果發出網路請求的案例，看看大部分程式員的寫法：

####Python學習交流Q群：906715085####
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)

 

需求已經實現，這點毋庸置疑，但是問題來了：

•如果讀取文件的時候發生異常了怎麼辦？

•如果數據源發生變化該如何處理？

•如果網路請求返回的數據不符合最終要求怎麼辦？

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

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

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

def extract_(val):  
  """匹配關鍵數據"""  
    return

def fetch(val):  
  """發出網路請求""" 
     return

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

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

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

 

把原來放在一個函數中實現的多個步驟拆分成為多個更小的函數，每個函數只做一件事。當數據源發生變化時，只需要改動 get_source 相關的代碼即可；如果網路請求返回的數據不符合最終要求，我們可以在 trim 函數中對它進行修剪。這樣一來，代碼應對變化的能力提高了許多，整個流程也變得更清晰易懂。

改動前後的變化如下圖所示：
在這裡插入圖片描述

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

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

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

穩定這個詞如何理解呢？

較少的改動或者不改動即視為穩定，穩定意味著調用這個對象的其它代碼拿到的結果是可以確定的，整體是穩定的。

按照一般程式員的寫法，數據存儲的代碼大概是這樣的：

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()

 

功能是能夠實現的，這點毋庸置疑。來看看它如何應對變化，如果要更換存儲，那麼就意味著需要改代碼。按照上面的代碼示例，有兩個選擇：

•重新寫一個存儲到 ExcelSave 的類；

•對 MySQLSave 類進行改動；

上面的兩種選擇，無論怎麼選都會改動 2 個類。因為不僅存儲的類需要改動，調用處的代碼也需要更改。這樣一來，它們整體都是不穩定的。如果換一種實現方式，根據依賴倒置的設計指導可以輕鬆應對這個問題。

邊看代碼邊理解：

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)

 

這裡通過內置的 abc 實現了一個抽象基類，這個基類的目的是強制子類實現要求的方法，以達到子類功能統一。子類功能統一後，無論調用它的哪個子類，都是穩定的，不會出現調用方還需要修改方法名或者修改傳入參數的情況。

依賴倒置中的倒置，指的是依賴關係的倒置。之前的代碼是調用方 Business 依賴對象 MySQLSave，一旦對象 MySQLSave 需要被替換， Business 就需要改動。依賴倒置中的依賴指的是對象的依賴關係，之前依賴的是實體，如果改為後面這種依賴抽象的方式，情況就會扭轉過來：
在這裡插入圖片描述

實體 Business 依賴抽象有一個好處：抽象穩定。相對於多變的實體來說，抽象更穩定。代碼改動前後的依賴關係發生了重大變化，之前調用方 Business 直接依賴於實體 MySQLSave，通過依賴倒置改造後 Busines 和 ExcelSave、 MySQLSave 全都依賴抽象。

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

依賴倒置的具體實現方式使用了一種叫做依賴註入的手段，實際上單純使用依賴註入、不使用依賴倒置也可以滿足開閉原則要求，感興趣的讀者不妨試一試。
在這裡插入圖片描述

挑肥揀瘦的介面隔離原則

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

•調用方不應該依賴它不需要的介面；

•依賴關係應當建立在最小介面上；

這實際上是告訴我們要給介面減肥，過多功能的介面可以選用拆分的方式優化。舉個例子，現在為圖書館設計一個圖書的抽象類：

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

 

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

在這裡插入圖片描述

這樣是不是一下就看懂了。這個指導思想很重要，不僅能夠指導我們設計抽象介面，也能夠指導我們設計 Restful 介面，還能夠幫助我們發現現有介面存在的問題，從而設計出更合理的程式。

輕裝上陣的合成復用原則

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

為什麼推薦優先使用合成復用，而後考慮繼承呢？

因為繼承的強依賴關係，一旦被依賴的對象（父類）發生改變，那麼依賴者（子類）也需要改變，合成復用則可以避免這樣的情況出現。要註意的是，推薦優先使用復用，但並不是拒絕使用繼承，該用的地方還得用。我們以一段代碼為例，說明合成復用和繼承的差異：

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

 

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

在這裡插入圖片描述

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

這裡的合成復用選用的實現方式是在 2 個 Car 裡面實例化另一個類 Color，其實也可以用依賴註入的手段在外部實例化 Color，然後把實例對象傳遞給 2 個 Car。

在這裡插入圖片描述

常見的三種架構

瞭解多種不同的架構可以使我們的知識面更寬廣，面對一類問題的時候可以提出其它解決辦法。同時，瞭解多種架構可以讓我們在設計階段做好規劃，避免後續頻繁的重構。常見的三種架構分別是：

•單體架構；

•分散式架構；

•微服務架構；

單體架構

單體架構是我們平時接觸較多的架構，也是相對容易理解的架構。單體架構把所有功能都聚合在一個應用里，我們可以簡單地將這種架構視作：
在這裡插入圖片描述

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

•複雜性高，所有功能糅合在一個應用里，模塊多、容易出現邊界模糊，而且隨著時間的推移和業務的發展，項目越來越大、代碼越來越多，整體服務效率逐漸下降；

•發佈/部署頻率低，牽一發而動全身，新功能或問題修複的發佈上線需要多方協調，發佈時間一拖再拖。項目大則構建時間長、構建失敗的幾率也會有所增加；

•性能瓶頸明顯，一頭牛再厲害也抵不過多頭牛合力的效果，隨著數據量、請求併發的增加，讀性能的不足最先暴露出來，接著你就會發現其它方面也跟不上了；

•影響技術創新：單體架構通常選用一類語言或一類框架統一開發，想要引入新技術或者接入現代化的服務是很困難的；

•可靠性低，一旦服務出現問題，影響是巨大的。

分散式架構

分散式架構相對於單體架構而言，通過拆分解決了單體架構面臨的大部分問題，例如性能瓶頸。假如單體架構是一頭牛，那麼分散式架構就是多頭牛：
在這裡插入圖片描述

當單體架構出現性能瓶頸時，團隊可以考慮將單體架構轉換為分散式架構，以增強服務能力。當然，分散式並不是萬能的，它解決了單體架構性能瓶頸、可靠性低的問題，但複雜性問題、技術創新問題和發佈頻率低依然存在，這時候可以考慮微服務。

微服務架構

微服務架構的關鍵字是拆，將原本糅合在一個應用中的多個功能拆成多個小應用，這些小應用串聯起來組成一個與之前單體架構功能相同的完整應用。具體示意如下：
在這裡插入圖片描述

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

這是不是很像單一職責原則和介面隔離原則？

分散式和微服務並不是銀彈

從上面的對比來看，似乎分散式架構比單體架構好，微服務架構比分散式架構好，這麼說來微服務架構>分散式架構>單體架構？

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

•運維成本高，在單體架構時，運維只需要保證 1 個應用正常運行即可，關註的可能只是硬體資源消耗問題。但如果換成微服務架構，應用的數量成百上千，當應用出現問題或者多應用之間協調異常時，運維人員的頭就會變大；

•分散式系統固有的複雜性，網路分區、分散式事務、流量均衡對開發者和運維進行了敲打；

•介面調整成本高，一個介面的調用方可能有很多個，如果設計時沒有遵循開放封閉原則和介面隔離原則，那麼調整的工作量會是非常大的；

•介面性能受限，原本通過函數調用的方式交互，在記憶體中很快就完成了，換成介面後通過網路進行交互，性能明顯下降；

•重覆勞動，雖然有公共模塊，但如果語言無關且又要考慮性能（不用介面交互）就需要自己實現一份相同功能的代碼；

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

畫好圖

在需要表達關係和邏輯梳理的場景里，圖永遠比代碼好。業內流行這麼一句話“程式開發，設計先行”，說的是在開發前，需要對程式進行構思和設計。試想，如果連對象關係和邏輯都說不清楚，寫出的代碼會是好代碼嗎？

在這裡插入圖片描述

在構思項目時可以使用用例圖挖掘需求和功能模塊；在架構設計時可以使用協作圖梳理模塊關係；在設計介面或者類對象時可以使用類圖做好交互計劃；在功能設計時可以使用狀態圖幫助我們挖掘功能屬性……

在這裡插入圖片描述

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

起一個好名字

你還記得自己曾經起過的那些名字嗎：

reversalList
get_translation
get_data
do_trim
CarAbstract

 

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

優化嵌套的 if else 代碼

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

在這裡插入圖片描述

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

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

 

這是我平時常用的優化辦法，後來在張曄老師的付費專欄中看到這種手段的名稱——衛語句。\

當然，這種簡單的邏輯處理和 if else 控制流用衛語句進行處理是很有效的，但如果邏輯再複雜一些，用衛語句的效果就不見的那麼好了。假設汽車 4S 店有折扣許可權限制，普通銷售有權對 30 萬以內金額的汽車授予一定折扣，超過 30 萬但在 80 萬以內需要精英銷售進行授權，更高價格的車折扣需要店長授權。這個功能可以歸納為根據金額的大小來確定授權者，對應代碼如下：

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

 

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

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

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

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

在這裡插入圖片描述

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

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))

 

創建好抽象類和具體的處理類之後，它們還沒有關聯關係。我們需要將它們掛載到一起，成為一個鏈條：

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

 

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

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

 

這跟我們去 4S 店購車是一樣的，作為客戶，我們確定好要買的車即可，至於 4S 店如何申請折扣，誰來授權與我無關，我能拿到相應的折扣即可。

至此，if else 優化知識學習完畢。這一篇文章比較長，喜歡的點贊噢，不懂的留言評論。然後就是，下一篇見啦。

在這裡插入圖片描述


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • python函數的兩種嵌套方法
    函數的嵌套有兩種方式： 交叉嵌套 迴環嵌套 交叉嵌套 交叉嵌套的方式是在本函數中調用同一級或上一級函數的嵌套方法： def func(foo): print(1) foo() print(3) def a(): print(1) b = func(a) print(b) 輸出的結果為： 1 1 3 ...
  • redis的基本命令學習
    redis的基本命令學習 1.簡單理解redis 基於記憶體的key-value資料庫基於c語言編寫的，可以支持多種語言的api //set每秒11萬次，取get 81000次支持數據持久化value可以是string，hash， list， set, sorted set 使用場景: 去最新n個數據 ...
  • 【Python】非同步任務如何實現提前返回
    前言 首先描述下業務場景，有一個介面，其中存在耗時操作，耗時操作的執行結果將寫入數據表中，不需要通過該介面直接返回。 因此理論上該介面可以在耗時操作執行結束前返回。本文中使用多線程後臺運行耗時操作，主線程提前返回，實現介面的提前返回。 此外，還嘗試使用協程實現，經驗證，協程適用於多任務併發處理，遇到 ...
  • Linux 搭建Apollo
    簡介 Apollo（阿波羅）是攜程框架部門研發的分散式配置中心，能夠集中化管理應用不同環境、不同集群的配置，配置修改後能夠實時推送到應用端，並且具備規範的許可權、流程治理等特性，適用於微服務配置管理場景。 服務端基於Spring Boot和Spring Cloud開發，打包後可以直接運行，不需要額外安 ...
  • Spring系列28：@Transactional事務源碼分析
    一、前言 眾所周知，Python 不是一種執行效率較高的語言。此外在任何語言中，迴圈都是一種非常消耗時間的操作。假如任意一種簡單的單步操作耗費的時間為 1 個單位，將此操作重覆執行上萬次，最終耗費的時間也將增長上萬倍。 while 和 for 是 Python 中常用的兩種實現迴圈的關鍵字，它們的運 ...
  • 2022DASCTF X SU 三月春季挑戰賽 Calc
    前言 本片博客記錄快速創建springboot工程的兩種方式。一種是使用maven創建，一種是使用spring initializr創建。開發環境JDK1.8、IDEA、maven。 SpringBoot 優點 可快速構建spring應用 直接嵌入tomcat、jetty、undenrtow伺服器（ ...
  • 突發！Spring Cloud 也淪陷了。。。
    大家好，我是棧長。 相信大家看到了昨天的 Spring 漏洞，嚴重級別僅為中等，不必慌張， 棧長沒想到的是，自這個月初 Spring Cloud Gateway 突發高危漏洞，現在 Spring Cloud 另外一個 Spring Cloud Function 模塊也淪陷了。。。 來看最新昨天 Sp ...
  • gateway聚合swagger3統一管理api文檔
    springboot微服務整合swagger3方法很簡單，下文會演示。但是在分散式項目中如果每個微服務都需要單獨的分開訪問獲取介面文檔就不方便了，本文將詳細講解springcloud gateway網關如何聚合統一管理swagger介面文檔。 先貼張整合後的效果圖(通過切換左上角的下拉視窗獲取每個微 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類