通過(guò)應(yīng)用軟件工程最佳實(shí)踐,可以交付質(zhì)量更好數(shù)據(jù)科學(xué)的項(xiàng)目。更好的質(zhì)量可能是更少的錯(cuò)誤、可靠的結(jié)果和更高的編碼效率。
最佳實(shí)踐都是從錯(cuò)誤中總結(jié)出來(lái)的,所以這里我們總結(jié)了一些遇到的最常見(jiàn)的錯(cuò)誤,并提供了如何最好地解決這些錯(cuò)誤的方法、想法和資源。
1、不使用虛擬環(huán)境
這本身不是編碼問(wèn)題,但我仍然認(rèn)為每種類型的項(xiàng)目進(jìn)行環(huán)境的隔離是一個(gè)非常好的實(shí)踐。
為什么要為每個(gè)項(xiàng)目使用專用環(huán)境呢?
第一個(gè)原因是Python本身包管理的問(wèn)題,我們想盡量減少包和版本之間的沖突。
另外一個(gè)原因是我們代碼和依賴可以方便的部署到任意的位置
使用虛擬環(huán)境可以從Anaconda 或 Pipenv 開(kāi)始。如果想更深入那么 Docker 是首選。
2、過(guò)度使用Jupyter Notebooks
Notebooks 非常適合用于教育目的和做一些快速而復(fù)雜的分析工作,但它不能作為一個(gè)好的 IDE。
一個(gè)好的 IDE 是應(yīng)對(duì)數(shù)據(jù)科學(xué)任務(wù)時(shí)的真正武器,可以極大地提高您的工作效率。
Notebooks 很適合做實(shí)驗(yàn),而且可以輕松地將結(jié)果展示給其他人。但是它很容易出錯(cuò),當(dāng)涉及到執(zhí)行長(zhǎng)期、協(xié)作和可部署的項(xiàng)目時(shí),最好還是使用IDE,例如 VScode、Pycharm、Spyder 等。
3、使用絕對(duì)而不是相對(duì)路徑
絕對(duì)路徑的最大問(wèn)題是無(wú)法進(jìn)行方便部署,解決這個(gè)問(wèn)題的主要方法是將工作目錄設(shè)置為項(xiàng)目根目錄,并且不要再項(xiàng)目中包含項(xiàng)目目錄外的文件,并且在代碼中的所有路徑均使用相對(duì)路徑。
4、不處理警告
當(dāng)我們的代碼能夠運(yùn)行但產(chǎn)生奇怪的警告消息,我們很高興終于讓代碼運(yùn)行并收到了有意義的輸出。但是我們需要處理這些警告嗎?
首先,警告本身并不是錯(cuò)誤,但它們是會(huì)引起我們對(duì)潛在錯(cuò)誤或問(wèn)題的提示。當(dāng)你的代碼中能夠運(yùn)行成功但可能不是它的預(yù)期方式時(shí),警告就會(huì)出現(xiàn)。
我遇到的最常見(jiàn)的警告是 Pandas 的“SettingwithCopyWarning”和“DeprecationWarning”。
SettingwithCopyWarning最大的原因是 Pandas 檢測(cè)到鏈?zhǔn)劫x值(Chained Assignment)時(shí)發(fā)生的警告,我們應(yīng)該避免對(duì)鏈?zhǔn)剿饕慕Y(jié)果賦值,因?yàn)檫@個(gè)操作有可能會(huì)報(bào)warning也有可能不會(huì)報(bào)。
DeprecationWarning 通常指出 Pandas 棄用了某些功能,并且您的代碼在使用更高版本時(shí)會(huì)中斷。
這里的建議并不是要處理所有的警告,但是一定要對(duì)所有警告產(chǎn)生的原因有所了解,要知道在特定項(xiàng)目中那些警告式可以忽略的,那些警告的出現(xiàn)對(duì)結(jié)果會(huì)有影響,應(yīng)當(dāng)避免。
5、沒(méi)有使用(很少使用)列表推導(dǎo)式
列表推導(dǎo)式是 python 的一個(gè)非常強(qiáng)大的特性。許多 for 循環(huán)可以用更易讀、更 Python 且速度更快的列表推導(dǎo)來(lái)代替。
可以在下面看到一個(gè)示例代碼,該代碼旨在讀取目錄中的 CSV 文件。可以看到,在使用列表推導(dǎo)時(shí)添很容易維護(hù)。
6、不使用類型注釋
類型注釋(或類型提示)是為變量分配類型的方法。在IDE進(jìn)行智能感知的提示時(shí)可以為我們提供指示變量/參數(shù)的類型。這不僅可以提高我們開(kāi)發(fā)的速度,也可以對(duì)我們閱讀代碼有很大的幫助。
如果這么寫(xiě),我們根本不知道a,b和times的類型
但是加上了類型注釋,我們就知道a和b是字符串times是整數(shù)
需要說(shuō)明的是:python在3.5版本的時(shí)候引入了類型注釋,python并不會(huì)在執(zhí)行時(shí)檢查類型注釋,他只是為IDE提供了一個(gè)方便靜態(tài)類型檢查工具,對(duì)動(dòng)態(tài)語(yǔ)言做靜態(tài)類型檢查,來(lái)避免一些潛在的錯(cuò)誤。
7、pandas代碼不規(guī)范
方法鏈?zhǔn)?pandas 的一個(gè)很棒的特性,但是如果在一行中包含了很多的操作,代碼可能會(huì)變得不可讀。
有一個(gè)技巧可以讓這種方式邊的簡(jiǎn)單,將表達(dá)式放入括號(hào)中,則可以對(duì)表達(dá)式的每個(gè)組件使用一行。
8、不遵守 PEP 約定
剛開(kāi)始使用 Python 進(jìn)行編程時(shí),代碼可能是簡(jiǎn)陋并且不可讀的,這是因?yàn)槲覀儾](méi)有自己的設(shè)計(jì)規(guī)則來(lái)讓我的代碼看起來(lái)更好。如果我們自己來(lái)設(shè)計(jì)這種規(guī)則是費(fèi)事費(fèi)力的并且這種規(guī)則需要很多的實(shí)踐,好在Python官方有已經(jīng)指定好的規(guī)則:PEP,它是 Python 的官方樣式指南。
雖然PEP的規(guī)則很多并且很繁瑣,我們可以忽略了一些 PEP 規(guī)則,但可以在 90% 的代碼中使用了它們。
9、你不使用編碼輔助工具
您想在編碼方面大幅提高生產(chǎn)力嗎?請(qǐng)開(kāi)始使用編碼輔助工具,它通過(guò)巧妙的自動(dòng)完成、打開(kāi)文檔和提供改進(jìn)代碼的建議來(lái)提供幫助。
pylance, Kite ,tabnine,copilot都是非常好的選擇。