積累木材的好處 | 原創，AI翻譯
當我之前在銀行擔任合約工時，我們使用多雲應用程式平台來服務微服務。當時，我在公司工作時開始累積日誌。
幾年過去了，我仍然認為這是幫助我工作或進行軟體工程的最佳方法之一。隨著時間推移，在我的日誌目錄中，有數百個日誌文件。
我沒有為那些日誌文件設置特定的子目錄或正式的日誌文件名稱。有時候，我只是將JIRA任務名稱作為日誌文件名稱的前綴，或者是該功能。然後我會在後綴中添加一個數字。例如，mutual-fund-1.log、mutual-fund-2.log等。這表示在共同基金微服務中，我有該日誌當運行該微服務時。
有時候，當我工作的項目服務多個地區時，我會將該國家作為後綴添加，例如mutual-fund-cn-1.log、mutual-fund-sg-1.log。日誌的文件名稱有些隨意。因為當時我需要專注於錯誤堆疊或周圍的函數調用。
程序的日誌很重要。人人皆知。然而，我要強調累積日誌的重要性，而不僅僅是觀看它們在控制台上然後讓它們消失。當專案進行時，你會發現更多便利。你有更多時間來查找之前的日誌。你可能需要了解是否有類似的數據庫存儲過程調用發生過。你可能需要了解是否有相同的錯誤發生過。你可能需要回憶上次如何修復這個問題。
在大型專案或數十個微服務中，有大量的細節。而錯誤、異常或問題不斷發生。日誌就像程序的運行文件。它們是由程序自動生成的，而非人工輸入。對於開發者來說，這些日誌是可讀的。因此，當開始新任務或修復新錯誤時，你有數百個日誌可供修復這個新錯誤。你不會孤單無援。
為什麼我們要累積它們？因為事情或知識容易被遺忘。
當紙張被發明時，人類文明進步了。當電腦被發明時，人類文明又進入了另一個層次。在紙上做筆記就像在電腦上累積日誌。
不僅僅是對人類，對AI聊天機器人、LLM工具等，這些日誌變得越來越重要。2022年成立的GreptimeDB，一個用於統一收集和分析可觀測性數據（指標、日誌和跡跡）的數據庫，並非偶然。
為什麼我之前沒有這樣做？在為大銀行擔任合約工之後，我需要進行更多的協作和參與更大的專案。在此之前，大多數時間在初創公司或我的初創期，我都是獨自工作。當我在LeanCloud工作時，我有半數時間在開發即時通訊應用LeanChat。
當我進入更正式的企業世界時，專案的開發與我的個人專案或初創專案不同。它們有SIT、UAT測試環境。而生產環境通常只對某些小團隊成員開放。從他們那裡獲取日誌並修復問題變得漫長且有些繁瑣。而運行一個專案需要時間，Jenkins管道通常需要半小時才能運行。
因此，我無法像蒼蠅一樣運行或測試程序。我無法通過在個人電腦上輸入命令並將代碼上傳到服務器來進行部署。
因此，這讓我累積日誌以便有更多的上下文來處理任務。我們最好在第一次就解決問題。我們最好在幾次內驗證我們的修復。我們不容易獲取在雲端或公司服務器上運行的程序日誌，因此我們最好複製並將它們保存在本地筆記本電腦上進行分析。
而現在，對於我的個人專案，我也會累積日誌。這已經成為習慣。在大公司工作了幾年後，我似乎有了更多的耐心或策略來使我的專案更大、更長久。因此，我知道隨著時間的推移，我需要這些日誌。
有人可能會說，你只需要有優雅的代碼和可運行的專案。你不需要累積日誌或錯誤堆疊。沒問題。當我們有錯誤或新功能時，我們可以運行程序來獲取當前的日誌。我們不需要開發過程中的日誌。它們就像科學實驗的詳細記錄。一開始看起來沒問題。但在長期來看，如果有一天你想再次工作，或者想分享它，或者讓別人接手它，可能就不太好了。
我認為這裡可能有很好的機會。在公司中，為什麼不鼓勵每個開發者分享他們累積的日誌？在開源專案中，我們也應該有這個。我們之所以不覺得別人的日誌有吸引力，是因為我們不認識它們。我們在保存這些日誌時失去了上下文。而裡面似乎有大量無關或瑣碎的消息。
但累積日誌的努力是微不足道的。每次看到一些日誌，特別是錯誤日誌時，我們只需要複製和粘貼。而如果我們以自動化的方式來做呢？這是一個好主意，每次運行專案時，例如那些Spring Boot專案，都記錄日誌到一個目錄中。
世界變得越來越數位化，因此累積數位程序的日誌就像在物理世界中累積書籍。