- 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. 總而言之文檔這裏也是一片混亂。唉！大概到處都是這樣亂糟糟？
- 很多時候我都不敢提出我的建議，怕被誤解/曲解反而把事情弄得更糟。
更多我的博客文章>>>
