前言
我們在用Python進行機器學習建模項目的時候，每個人都會有自己的一套項目文件管理的習慣，我自己也有一套方法，是自己曾經踩過的坑踩過的雷總結出來的，現在在這裏分享一下給大家，因爲很多夥伴是接觸Python編程入門不久，也希望大家少走彎路，多少有些地方可以給大家借鑑。
文章目錄
1. 項目文件事先做好歸檔
每次開始一個新工作的時候，以前的我總是貪圖方便，Code、Data、文檔都集中放在一個文件夾內，看起來很亂，一度讓回溯過程十分痛苦，或者是換了部電腦，文件全都運行不行了，需要自行修改路徑，十分痛苦。
經過自己一番探索，大家可以大致將項目分成幾個子文件夾，code放在主文件夾裏：
2. 永遠不要手動修改源數據並且做好備份
我們需要對源數據進行好備份，方便我們下一次進行回溯，可以進行下一步的操作或者是對中間步驟的修改，而且，對代碼等其他文件也是需要做好備份的，以免出現意外丟失。
這裏來自良許Linux 的一篇文章，推薦了4個工具：
Git版本控制系統
Rsync文件備份
Dropbox雲存儲
Time Machine時光機器
更多的工具介紹和使用我這邊就不展開，大家可以去自行了解唄。
3. 做好路徑的正確配置
很多同學在寫路徑的時候都很喜歡直接用絕對路徑，雖然一般情況下不會有什麼問題，但如果代碼共享給其他人學習或者運行的時候，問題就來了，很多情況下都不能直接跑通，
這裏建議：
使用相對路徑：腳本位於主目錄下，其他資源（如數據、第三方包等）在其同級或低級目錄下，如 ./data/processed/test1.csv
全局路徑配置變量：
# 設置主目錄
HOME_PATH = r'E:ML90615- PROJECT1'
# 讀取數據
data = open(HOME_PATH+'/data/processed/test1.csv')
data = pd.read_csv(data)
data.head()
4. 代碼必要的地方做好備註與說明
這個我相信大多數人都感同身受了，不信？拿回一個月前自己寫的代碼看看吧，看一下能看懂多少（如果沒有做好備註說明的話）
5. 加速你的Python循環代碼
推薦我們的Python學習扣qun：913066266 ，看看前輩們是如何學習的！從基礎的python腳本到web開發、爬蟲、django、數據挖掘等【PDF，實戰源碼】，零基礎到項目實戰的資料都有整理。送給每一位python的小夥伴！每天都有大牛定時講解Python技術，分享一些學習的方法和需要注意的小細節，點擊加入我們的python學習者聚集
6. 可視化你的循環代碼進度
這裏介紹一個Python庫，tqdm，先安裝一下：pip install tqdm
這個是一個可以顯示循環進度的庫，有了它就可以更加運籌帷幄了。
大家可以看下面的例子：
*
7. 使用高效的異常捕獲工具
異常bug定位，以前的我經常也是一條print()函數走到底，雖然說也沒什麼問題，但效率上還是會比較慢，後來發現了一個叫PySnooper的裝飾器，彷彿發現了新大陸。
我們一般debug，都是在我們可能覺得會有問題的地方，去打印輸出，看下實際輸出了什麼，然後思考問題所在，這需要我們去改code，非常細緻地改，相比較直接加個裝飾器，是十分麻煩的。
大家可以看看Example：
import pysnooper
@pysnooper.snoop('./file.log')
def number_to_bits(number):
if number:
bits = []
while number:
number, remainder = divmod(number, 2)
bits.insert(0, remainder)
return bits
else:
return [0]
number_to_bits(6)
我們把函數每一步的輸出都保存爲file.log，我們可以直接去看到底哪裏出了問題。
8. 要多考慮代碼健壯性
何爲代碼的健壯性,顧名思義，就是可以抵擋得住各種異常場景的測試，異常處理工作由“捕獲”和“拋出”兩部分組成。“捕獲”指的是使用 try … except 包裹特定語句，妥當的完成錯誤流程處理。而恰當的使用 raise 主動“拋出”異常，更是優雅代碼裏必不可少的組成部分，下面總結幾點供大家參考：
1）知道要傳入的參數是什麼,類型,個數 （異常處理,邏輯判斷）
def add(a, b):
if isinstance(a, int) and isinstance(b, int):
return a+b
else:
return '參數類型錯誤'
print(add(1, 2))
print(add(1, 'a'))
2）只做最精準的異常捕獲
我們有的時候想着讓腳本work纔是王道，所以不管三七二十一就搞一個大大的try…except把整塊代碼包裹起來，但這樣很容易把原本該被拋出的 AttibuteError 吞噬了。從而給我們的 debug 過程增加了不必要的麻煩。
所以，我們永遠只捕獲那些可能會拋出異常的語句塊，而且儘量只捕獲精確的異常類型，而不是模糊的 Exception。
from requests.exceptions import RequestException
def save_website_title(url, filename):
try:
resp = requests.get(url)
except RequestException as e:
print(f'save failed: unable to get page content: {e}')
return False
# 這段正則操作本身就是不應該拋出異常的，所以我們沒必要使用 try 語句塊
# 假如 group 被誤打成了 grop 也沒關係，程序馬上就會通過 AttributeError 來
# 告訴我們。
obj = re.search(r'<title>(.*)</title>', resp.text)
if not obj:
print('save failed: title tag not found in page content')
return False
title = obj.group(1)
try: with open(filename, 'w') as fp:
fp.write(title)
except IOError as e:
print(f'save failed: unable to write to file {filename}: {e}')
return False
else:
return True
3）異常處理不應該喧賓奪主
像上一條說到的異常捕獲要精準，但如果每一個都很精準的話，其實我們的代碼裏就會有很多try…except語句塊，以至於擾亂核心代碼，代碼整體閱讀性。
這裏，我們可以利用上下文管理器來改善我們的異常處理流程，簡化重複的異常處理邏輯。
class raise_api_error:
"""captures specified exception and raise ApiErrorCode instead
:raises: AttributeError if code_name is not valid
"""
def __init__(self, captures, code_name):
self.captures = captures
self.code = getattr(error_codes, code_name)
def __enter__(self):
# 該方法將在進入上下文時調用
return self
def __exit__(self, exc_type, exc_val, exc_tb):
# 該方法將在退出上下文時調用
# exc_type, exc_val, exc_tb 分別表示該上下文內拋出的
# 異常類型、異常值、錯誤棧
if exc_type is None:
return False
if exc_type == self.captures:
raise self.code from exc_val
return False
在上面的代碼裏，我們定義了一個名爲 raise_api_error 的上下文管理器，它在進入上下文時什麼也不做。但是在退出上下文時，會判斷當前上下文中是否拋出了類型爲 self.captures 的異常，如果有，就用 APIErrorCode 異常類替代它。
使用上下文管理器後，簡潔的代碼如下
def upload_avatar(request):
"""用戶上傳新頭像"""
with raise_api_error(KeyError, 'AVATAR_FILE_NOT_PROVIDED'):
avatar_file = request.FILES['avatar']
with raise_api_error(ResizeAvatarError, 'AVATAR_FILE_INVALID'),
raise_api_error(FileTooLargeError, 'AVATAR_FILE_TOO_LARGE'):
resized_avatar_file = resize_avatar(avatar_file)
with raise_api_error(Exception, 'INTERNAL_SERVER_ERROR'):
request.user.avatar = resized_avatar_file
request.user.save()
return HttpResponse({})
以上就是本文的全部內容，希望對大家的學習有所幫助