本文轉載自公眾號“讀芯術”(ID：AI_Discovery)

如果你對數據科學感興趣，那么可能對這個工作流程很熟悉：通過運行Jupyter notebook開啟一個項目，然后開始編寫python代碼、運行復雜的分析甚至訓練模型。隨著notebook文件的函數、類、圖和日志的大小不斷增長，你會發現自己面前堆積了巨大的一團代碼塊。運氣好的話，一切都能順利進行。那你真的很厲害!

[[344175]]

但是，Jupyter notebook隱藏了一些嚴重的陷阱，可能會讓代碼變成噩夢。讓我們看看這是如何發生的，然后討論一下防止這種情況出現的優秀編碼方法。

Jupyter Notebook的問題

通常，如果你想使Jupyter原型開發更上一層樓，事情結果可能會不符合你的預期。這是筆者在使用此工具時遇到的一些情況，你應該也很熟悉：

• 將所有對象(函數或類)定義并實例化后，可維護性就變得非常困難：即使想對函數做些小改動，也必須將其放在筆記本中的某個位置進行修復，然后重新運行重新編碼。你一定不希望這種事情發生。將邏輯和處理功能分離在外部腳本中不是更簡單嗎?
• 由于其交互性和即時反饋，jupyternotebook促使數據科學家在全局名稱空間中聲明變量，而不是使用函數。這在python開發中是不好的做法，它限制了有效的代碼重用。
• 由于筆記本電腦變成容納所有變量的大型狀態機，因此也會損害其可重復性。在這種配置下，必須記住要哪個結果被緩存，哪個結果沒有被緩存，還必須期望其他用戶遵循你的單元執行順序。
• 筆記本在后臺格式化的方式(JSON對象)使代碼版本控制變得困難。這就是為什么筆者很少看到數據科學家使用GIT提交不同版本的筆記本，或合并分支以實現特定功能。

因此，團隊協作變得低效笨拙：團隊成員開始通過電子郵件或Slack交換代碼段和筆記本，回滾到以前的代碼版本成為一場噩夢，文件組織開始變得混亂。這是在沒有正確版本控制的情況下, 使用Jupyter notebook兩到三周后，我在項目中通常看到的內容：

analysis.ipynb 
analysis_COPY(1).ipynb 
analysis_COPY(2).ipynb 
analysis_FINAL.ipynb 
analysis_FINAL_2.ipynb 

Jupyter notebook非常適合探索和快速制作原型。它們肯定不是為可重用性或生產用途而設計的。如果你使用Jupyter notebook開發了數據處理管道，那么最好的情況是代碼僅按照單元執行順序以線性同步方式在筆記本電腦或VM上運行。

但這并沒有說明你的代碼在更復雜的環境中的行為方式，例如，較大的輸入數據集，其他異步并行任務或分配較少的資源。實際上我們很難測試筆記本，因為它們的行為有時是不可預測的。

• 作為一個將大部分時間花在VSCode上的人，我常常利用功能強大的擴展來進行代碼添加、樣式格式化、代碼結構、自動完成和代碼庫搜索，因此當切換回Jupyter時，筆者不禁感到有些無能為力。與VSCode相比，Jupyter notebook缺少強制執行最佳編程實踐的擴展。

好了，抱怨到此為止。筆者真的很喜歡Jupyter，認為它對設計工作非常有用。你肯定可以用它來引導小項目或快速創建想法原型,但你必須遵循軟件工程的原則。當數據科學家使用notebook時，有時會忽略這些原則，讓我們一起回顧下其中一些吧。

讓代碼再次出色的小技巧

這些技巧是從不同的項目、筆者參加的聚會以及過去合作過的軟件工程師和架構師的討論中匯編而來的。注意，以下內容皆假設我們正在編寫python腳本，而不是notebook。

1.清理代碼

代碼質量最重要的維度是清晰，清晰易讀的代碼對于協作和可維護性至關重要。這樣做可以幫你獲得更簡潔的代碼：

• 使用有意義的描述性和暗示型變量名。例如，如果要聲明一個關于屬性(例如年齡)的布爾變量來檢查一個人是否老了，那么可以使用is_old使其既具有描述性又具有類型信息性。聲明數據的方式也是一樣的：讓它具有解釋性。

# not good ... 
import pandas as pd 
df = pd.read_csv(path)# better!transactions = pd.read_csv(path) 

• 避免使用只有你能理解的縮寫和沒有人能忍受的長變量名。
• 不要直接在代碼中編碼“魔術數字”。在變量中定義它們，以便每個人都能理解它們所指的內容。

# not good ... 
optimizer = SGD(0.0045, momentum=True)# better ! 
learning_rate = 0.0045 
optimizer = SGD(learning_rate, momentum=True) 

• 遵循PEP8約定給對象命名：例如，函數和方法名用小寫字母表示，單詞用下劃線分隔，類名遵循UpperCaseCamelCase約定，常量用大寫字母表示，等等。
• 使用縮進和空格使代碼更加美觀。有一些標準約定，例如“每個縮進使用4個空格”，“單獨的節應該有額外的空行”等等。

 [[344176]]

2.使代碼模塊化

當你開始構建可以在相同或其他項目中重復使用的東西時，你必須將代碼組織為邏輯功能和模塊，這有助于構建更好的組織和可維護性。

例如，你正在研究NLP項目，并且你可能具有不同的處理功能來處理文本數據(標記，剝離URL，修飾詞等)。你可以將所有這些單元放入名為text_processing.py的python模塊中，然后從中導入它們，主程序將更輕巧。

這是有關編寫模塊化代碼的一些技巧：

• 不要自我重復。盡可能泛化或合并你的代碼。
• 函數應該用來做一件事。如果一個函數執行多項操作，則很難被概括。
• 在函數中抽象邏輯，但又不要過度設計，否則最終可能會有太多的模塊。運用你的判斷力，如果你沒有經驗，請查看scikit-learn等流行的GitHub存儲庫，并學習其編碼風格。

3.重構代碼

重構旨在重新組織代碼的內部結構，而不改變其功能，通常是在有效(但仍未完全組織)的代碼版本上完成的。它有助于消除重復功能，重組文件結構，并添加更多抽象。

4.提高代碼效率

編寫高效的代碼以快速執行并消耗更少的內存和存儲空間，是軟件開發中的另一項重要技能。編寫高效的代碼需要多年的經驗，但是以下一些小技巧可以幫助你確定代碼是否運行緩慢以及如何提高代碼運行速度：

• 在執行任何操作之前，請檢查算法的復雜性以評估其執行時間。
• 通過檢查每個操作的運行時間來檢查腳本可能遇到的瓶頸。
• 盡可能避免for循環并使操作向量化，尤其是在使用NumPy或pandas等庫的情況下。
• 通過使用多處理來利用計算機的CPU內核。

5.使用GIT或任何其他版本控制系統

使用GIT + Github幫助我提高了編碼技能，更好地組織了項目。由于我是在與朋友和同事合作時使用它的，所以我遵守了過去不遵守的標準。

[[344177]]

無論是在數據科學還是軟件開發中，使用版本控制系統都有很多好處。

• 跟蹤你的更改
• 回滾到任何以前的代碼版本
• 團隊成員之間通過合并和請求進行有效的協作
• 提高代碼質量
• 代碼審查
• 為團隊成員分配任務，并提供“持續集成”和“持續交付”掛鉤，以自動構建和部署項目。

6.測試代碼

如果你要構建一個執行一系列操作的數據管道，且要確保它能夠按照設計的目的執行，其中一種方法是編寫可檢查預期行為的測試。測試可以像檢查函數的輸出形狀或期望值一樣簡單。

為功能和模塊編寫測試有很多好處：

• 它提高了代碼的穩定性，并使錯誤更容易發現。
• 防止意外輸出
• 有助于檢測邊緣情況
• 防止將破損的代碼推向生產環境

7.使用日志記錄

一旦代碼的第一個版本運行了，你需要監察每個步驟，以了解發生了什么、跟蹤進度或發現錯誤，你可以使用日志記錄。以下是有效使用日志記錄的一些技巧：

• 根據要記錄的消息的性質，使用不同的級別(調試，信息，警告)。
• 在日志中提供有用的信息，以幫助解決相關問題。

import logging 
logging.basicConfig(filename='example.log',level=logging.DEBUG) 
logging.debug('This message should go to the log file') 
logging.info('So should this') 
logging.warning('And this, too') 

告別代碼噩夢，這些小技巧要學起來。