[M] 在你的经历中，有否切实体会到撰写文档会便于以后项目的维护？

[L] 体会太深刻了，我们给HP做的惠普商桥系统，从开始到现在经手人估计将近10个了，但是文档仍然是第一版的，因此需要增加新的功能，如果是一个从来没有接触这个项目的人来做，假设代码的改动量是200行，但是他首先需要大概的时间来读以前的代码。这是没有文档的结果啊。象摩托罗拉，他们的项目组中的任何一个人走掉以后都不会对项目组产生影响，因为他们的文档做的非常好。

[版本控制]

[M] 在你的开发过程中，有否使用过版本控制措施？

[L] 我们公司的项目，无论大小都使用版本控制。特别是执行CMM标准后，项目一启动，在版本控制数据库中建立很多的目录、资源文件等等。其实使用版本控制，是避免两个人同时操作一份文件，当遇到改正的不对的地方时可以回滚，返回到上一个正确的版本。而且万一程序被几个人更改后可以记录更改人的姓名、时间，以利于寻找责任。其实团队开发时，版本控制是必须的措施。而且即使一个人开发，也建议使用版本控制，比如你更改了某些东西，但是发现更改的不对，想用Ctrl+Z但又不能恢复，这时可以使用版本控制的“撤销签出”来获得上一个版本的代码。

[M] 你在实施版本控制的时候，有没有发生过因为人员版本控制意识不强，以及对版本控制工具使用不当，而造成的损失或效率降低呢？

[L] 应该说在实施版本控制时问题还是很多的，而且有些人对版本控制的认识还不是很清楚，认为版本控制没有太大的必要。在dot net开发环境下，我们曾经出现过一些问题，同事刚刚更改的文件，check in 然后check out发现仍然是原来的样子，也是说他新更改的代码丢失了。但是换到另一个的机器上发现代码是更改以后的，这样大概折腾了一上午的时间，后来也不知道什么原因好了，不过倒是后来没有发现类似情况。

[M] 你个人对版本控制的实施有何心得？

[L] 其实对于版本控制的心得也谈不上，只是有一点source safe的小小技巧或者说小小经验而已。个人理解还处在比较低的水平，个人技巧也只是限于普通的应用。在小组协同开发过程中，我认为版本控制是必要的，毕竟小组开发人多，对于某个文件的操作可能同时几个人都会涉及到，如果没有版本的控制措施，两个以上的人可能同时操作同一个文件，这样会相互冲突，造成代码的混乱。如果有了版本控制的措施，可以保证一个文件在一个时间只能被一个人使用。当遇到修改错误的时候可以恢复到上一次修改的版本，避免发生不知道修改何处，无法恢复的问题。还有一个问题是如果某个文件出现错误，可以找到后一次修改的人员，到时他想否认都不可能啊。

[M] 如果在版本控制的过程中，由于操作不当，或人为疏忽，造成损失，对此有什么补救措施吗？

[L] 应该说在版本控制过程中，不同的人员对于项目文件的操作权力是不同的。项目经理可以add/delete/modify/destory，而项目成员则只能add/delete/modify。因为我没有遇到过操作不当的问题，因此我只能凭借个人的一点理解，给你大概的介绍一下。版本控制的工具对你所作的每一次操作都会记录下来，保存为历史记录，由于项目成员只有delete的权力，因此如果把某个文件不小心删除后，应该可以通过历史记录查找出来，但是如果项目经理把文件destory后，在版本控制的历史记录中可能找不到了。不过如果项目成员想要修改某个文件，他必须在本地建立一个项目副本，然后本地修改，因此即使在版本控制中把文件删除，通过其他项目成员的本地副本仍然可以得到某个版本的代码，但是这个版本是否是新的值得怀疑，因为近该项目成员可能没有get last version。所以如果操作不当，或认为疏忽造成损失之后，应该可以弥补一部分，但是是否是全部弥补，要试具体情况而定。因此项目经理的另一个任务是每天备份代码，数据库等重要的项目信息。这样可以把意外情况的损失降低到小。

[其他]

[M] 对于代码的规范以及注释的书写，你有何心得呢？

[L] 在我刚刚完成的项目中，有个程序员以前是写Notes的，对于sql server不是很熟，因此在写代码时定义了一堆的tmpstr1，tmpstr2等类似的变量，变量具体对应窗体上哪个控件的内容，你必须找到变量赋值的地方才能看到变量对应的具体内容。而且从来不加注释，整个页面包含不同的函数，确使用一个connection链接，出现了错误，调试都找不出原因，非常的困难。所以我要求他们必须加注释，可以说是强迫他们吧。由于工期比较紧倒是没有要求他改正页面的代码。我们公司在制定CMM标准时，整理了一套编程规范，项目开始时给程序员人手一份。我原来设想在项目过程中隔一段时间抽出2－3个小时把某个程序员的代码讲一下，人为的让大家养成比较好的编程习惯，可惜项目太紧，我没有执行。其实代码的规范和注释可以说是文档的一部分，规范好注释好，对于维护人员来说相对的轻松很多。

[M] 你在回答有关代码规范注释书写的问题和版本控制的问题时都提到了CMM，CMM和这些有什么必然联系吗？这些是在CMM中有所提及，还是对CMM实施的一种延伸。

[L] 我觉得CMM可能和这些东西没有必然的联系，因为CMM的培训我们公司近一直没有做，我只是根据同事的聊天以及自己的一些个人想当然的理解说的，但是我觉得这些应该是CMM的一种延伸。在CMM的定义中有一种名为"SQA"的角色，是质量保证员，他的工作可能是保证提交给客户的代码的质量，或许有些版本控制的味道吧。其实代码注释的规范编写，我觉得我们可以理解为代码质量的一种表现形式。我觉得代码质量的衡量不应该仅仅是软件在客户处运行正确，没有bug，还应该包括代码是否利于维护。一个项目维护人员他首先看的可能是项目文档和代码，但是由于项目文档可能不是很全，很正确，因此维护人员的直接的工作可能是看代码，如果代码写的很晦涩，而且又没有必要的注释，那么对应维护人员来说是很头疼的事情。这样可那与CMM的初衷有些背离。

原文出处：http://morningspace.51.net/