08，年末特輯下：2022 工作與程式學習總結

相關文章：07，年末特輯上：2022 寫作反省與明年目標

「今天是公司尾牙，也是我進公司剛滿一年半。」——本來要用這兩句作為開頭的🤣。結果年假放起來，一轉眼兩星期過去，驀然回首，2023 年 1 月都快結束了！

不得不說，2022 才是我身為軟體工程師，覺得自己比較有進步的第一年。儘管不特別勤奮，但對細節還是相當講究的，尤其是「團隊文件文化」的建立，與程式碼可讀性的落實。

個人部分，寫程式的能力，要說提升多少，可能也沒有——code review 功力倒是明顯提升了，主還是在於一些重要工具的熟悉、應用上。

這些工具是在 Python 開發工作上佔據一定重要性，有著「應用廣、可延續」的特性，並擔當「讓團隊開發更加高效且健全」的角色。

可以說，作為一個稱職的 Python 開發者，就應該要使用這些東東！

其中的一部分，去年已經寫成教學文章。剩下的還沒動筆的，今年也要寫出來。接下來就來盤點一下，它們具體是哪些。

一、使用 Poetry 管理專案的 Python 虛擬環境

在〈Python 套件管理器——Poetry 完全入門指南〉中，我並沒有具體提及團隊改採用 Poetry 的理由，但在臉書社團的宣傳文中則有這段發言：

前陣子工作專案在新增一個簡單的 feature 後，我赫然發現明明專案規模還不算大，Python 虛擬環境所安裝的套件數量竟然堂堂突破了 200 大關（拜 Azure SDK 所賜），產生的 Docker image 也超過 2 GB，真是太誇張了！

這是不能接受的！

不過即便用了一段時間，還是難免覺得，Poetry 真的「不算」是個容易上手的工具。有時候我還是會回頭看自己的文章，才能想起來某件事要怎麼下指令。

但整體而言，絕對值得啦！而且它的套件管理機制，也不像 npm 那樣，容易過度肥大，甚至會形成黑洞（一個迷因）。

可能是去年「第二重要」的事！

我想，單元測試，或者說寫測試，是「最有效」改善一個工程師平時寫程式的「不良習慣」的一種手段——因為它要求你對自己寫下的程式碼的品質，負起責任。

而且光單元測試本身就很多學問——還真的非常多，比如這篇〈How To Write High Quality Unit Tests〉。不過對剛接觸測試的我們，用一個好工具如 pytest，把基本的測試寫出來，就已經有 60 分了！

用過 pytest 就能感受到它是如此的強大而優雅，優雅的點在於，它能讓測試程式碼本身就盡可能「有秩序、好讀好維護」（當然這需要一定深思熟慮的設計與落實），尤其在專案與測試規模愈來愈大的時候，pytest 的優勢將會更加突顯。

難怪 pytest 能在軟體 QA 等各種測試領域都佔據一定地位，更別說對一般的開發者了——不用說，我們要善用它。

ORM 這東西到底是否必要，向來都有爭論。在存取需求不複雜的情況下，我還是偏好 ORM，這裡就是很好的例子。

我們只是想把 gateway 的 config（多層且不固定的資料結構）透過 MongoDB 儲存，有了 MongoEngine 這樣的 ORM 工具，就不需要知曉太多 MongoDB 細節，可以減輕一開始的實作負擔。

不過不可否認，工具本身也需要學習🐸，而學習就是成本！這部分可參考〈Django 專案 ORM 存取 MongoDB：MongoEngine 設定教學〉。後續預計會再寫一、兩篇操作教學文。

如果測試是第二重要，那什麼才是最重要的事？——確保程式碼的規範與一致性。

「一致性」在團隊協作的重要程度，容易被輕忽。

對於相同功能與目標，卻有著（截然）不同的寫法，其中造成的思考停頓、理解混淆、bug 滋生等，這些額外的隱性成本，並不容易計算，但確確實實存在。

你我都知道，這就是一種「程式碼的不衛生」。

本段標題的工具們就是為了落實規範與一致性，降低「程式碼不衛生」的可能，我視它們為程式開發基石，所以自然是第一重要的事。

我在今年上半年（除日常開發外）的自訂工作績效，列了下面幾個小目標，供參：

儘管每個目標都不算大，但透過一步步累積與向外擴展，我們應該都能過上踏實的開發人生。🐧