說正事，回答你的帖子啊

來源: 美國老土於 2023-06-04 17:18:27 [檔案] [博客] [舊帖] [給我悄悄話] 本文已被閱讀：次 (4620 bytes)

回答: 工作筆記1-誤解及影響由石榴花開的季節於 2023-05-30 15:30:29

Backup/測試 code—我工作的單位是業務部門，做的產品要24 小時都運行。如果因為任何原因中斷就算事故。因此如果有新產品需要上業務，或是產品需要更新，都不能直接在業務運行的計算機上改，而是要先在測試的計算機上調試好了以後，才能搬到業務上去。但是在業務上運行的code和在測試機上運行的不是完全一樣的。code 從測試機搬到業務上後需要做一些小改動。比如測試時輸出的測試信息需要關掉。上了業務之後才要發出的數據和信息需要打開，等等。這樣就有一個版本的問題。我們這裏雖然有code 的configuration management (CM), 但是也非常混亂。很多人就給測試版的code名加_bk 以區別正式版的code。比如業務上的code, ingest.pl 在測試機上就是ingest_bk.pl. 這個code搬到業務機上後，要去掉_bk，改回原來的名字。但是時間長了，人員也變動頻繁，我就在業務機上看到一堆*_bk code，也不知道人們是不知道應該去掉_bk,還是忘了這樣做。唉，早知如此，何必加_bk?

-- 曆史上就是這樣加的；
-- 而就形成了曆史；
-- 隻要一切都工作的好好的，千萬不要去多事；
-- 怕就怕你把文件名字了以後，看著挺規範，但生產係統有可能就出問題了。

文檔—-有關軟件的文件是非常重要的，它對一個係統的安裝和維護是必不可少的。但是我很少看到寫得好的文檔。經常是文檔大的不得了，似乎包羅萬象，很全麵。但是我的感覺是想要找的重要信息找不到，不想要的一大堆。而且幾種文檔中的信息互相重複。總而言之，垃圾信息一大堆，重要信息找不到，或者很難找到。如何寫好文檔，應該包括那些內容，如何取舍內容，…，可能是一個很大的問題。我曾經參加過製定文檔標準的工作。但是我隻是更了解這個新的文檔標準，我的意見當時並沒有被接受。新標準規定每個數字產品都需要寫一個user manual 。user manual 分兩種，external user manual (eum)和 internal user manual (ium). 我們這裏大部分產品隻需要寫eum, 隻有一個產品需要寫ium. (我的看法是根本就不要搞一個ium). 結果是，雖然我們在文檔標準裏說明了什麽產品需要eum , 什麽產品需要ium。但是認真讀說明的人可能都不多，而誤讀的人卻總是那麽的多。於是我就看到很多產品都寫了eum and ium 兩個文件。 eum 和ium 裏的內容又是很多重複。人們又都搞不明白eum 和ium 的區別, 有的人幹脆隻寫了一個ium ，其實他應該隻寫一個eum. 總而言之文檔這裏也是一片混亂。唉！大概到處都是這樣亂糟糟？

-- 寫文檔是領導布置的任務；
-- 寫了就是表示尊重領導了，就算是交差了。