正文
- 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. 总而言之文档这里也是一片混乱。唉！大概到处都是这样乱糟糟？
- 很多时候我都不敢提出我的建议，怕被误解/曲解反而把事情弄得更糟。
评论
目前还没有任何评论
登录后才可评论.
