[文档]   
 
    [M] 你对程序员进行文档的组织、编写、维护工作持什么样的态度呢？这是否会影响coding呢？尤其是在来自客户和市场的压力十分严峻的时候。这是一个很现实的问题。  
 
    [L] 其实我们大家都不止一次的提到，在做项目的过程中大部分时间都是用来组织编写文档，真正coding的时间在整个项目的生命周期中占的时间是很少的，一个真正的项目也绝对不是以coding作为结束标志的，因为项目结束后还有维护或者二期甚至三期，所以文档的积累对于项目来说就是至关重要的事情。作为项目结果之一的代码，我们不能只让写这段代码的人知道，这无异于赌博，而且经过一段时间之后谁也不可能保证自己对自己曾经写过的代码一清二楚。我们要让所有的人知道某段代码应该实现什么功能，包含什么逻辑，是一个什么样的思路，这样项目转接工作才能做得更好。客户和市场的压力十分严峻的原因是什么，不可能因为程序员写文档造成的。相反如果文档写的好反而在coding阶段会节省很多的时间，因为思路、算法在文档中已经得到很具体的体现。如果真的客户和市场的压力十分严峻至少在项目结束后应该把文档补齐。如果只是项目经理写文档，那么他的思路、设计，在程序员身上很难得到体现。因此我建议程序员要参与到概设、详设的文档编写中来。其实，摩托罗拉就是很好的例子，他们不会因为某个程序员或项目经理走了，来接替他的人需要花费大量的时间来熟悉这个系统，相反他们可以从文档着手，很好的理解整个项目。我们公司就有很失败的例子，在给HP做的电子商务系统中，到现在某个页面可能被5－6个人更改过，但是最基本的概要设计连第一版本的内容都没有，因此现在维护相当的费劲，几乎没有人愿意接触这个项目，一点小小的改动，都要研究半天的代码。血的教训啊。
 
    [M] 对于项目文档的准确，完整，应该如何去把握呢？
 
    [L] 项目文档的准确，完整的定义可能很模糊，而且判断起来也很困难，但是我想最基本的应该是：项目初期应该把项目涉及到的内容全部写入文档，项目进行中可能某个思路不能得到实现需要更改，代码更改了但是文档一定要跟着更改，否则就失去了文档本来的意义。所以我想项目经理在做计划时是否每周要留出半天甚至一天的时间来修改文档？
 
    [M] 项目文档化过程中，文档撰写者需要将思路精确无误的表达出来，并且阶段性地保持文档和代码的一致性。这对文档撰写者提出了一定要求。在你的公司里，当客户和市场的压力十分严峻时，又是如何保证这些的。对此你有什么看法或心得，你认为程序员需要具备什么额外素质吗？
 
    [L] 其实写文档就是一个整理思路的途径，所谓的完整或许不需要面面俱到，但是重点的流程，关键的思路等都需要描述出来啊。其实对于文档的撰写，不要觉得是个很复杂的事情，文档的意义就在于它记录了项目的完成过程，在于便于以后项目的维护。当客户和市场的压力十分严峻时，我们的精力可能集中于项目的真正coding，专注于项目的按期完工。但是在项目结束之后项目文档一定要补全。现在国内的情况是程序员大部分是本科出身，因此程序员本身的素质就决定了他不止可以承担coding的任务，因此项目经理要适当的给予他们一些其他的额外工作。
 
    [M] 文档具体包含哪些类型？每种文档针对何种阅读者？
 
    [L] 文档包括：需求分析说明书，概要设计说明书，详细设计说明书（许多数据流图都作为文档的附件的），等等吧，现在我手上也没有很全的文档列表。
 
    [M] 在你的公司，有没有类似程序设计说明这样的文档，若有，对于这类文档，撰写者若表述不清则会使阅读者难于理解。实际中是否存在这样的问题？
 
    [L] 其实我觉得象概要设计说明书，详细设计说明书不知是否属于程序设计的文档，不过我觉得应该是吧。其实象这种文档如果撰写者表述不清对于阅读者的理解程度会有很大的差别的。我们公司也一直在讨论如何制定一个切实可行的规范，以利于大家把文档写的详细、清楚，我们现在的模板有时对于某些项目来说真的不适合。但是很长时间以来仍然找不到一个可以避免的方式。在现实的工作中，我认为是存在表达不清的，只不过我暂时没有遇到过，或许我从需求阶段一直跟到验收，所以对系统很了解，所以可能没有遇到不好理解的地方吧。而且现在公司的形式是每个人负责写一块的概要设计和详细设计，因此这份文档对于这个人来说很明白，但是没有人对整体文档的把握，虽然我们要做概要设计和详细设计的评审，但是由于大多数情况下时间不允许，因此项目成员写完以后，项目经理组织到一起也就完事了。
 
    [M] 文档的意义或作用除了记录项目完成过程外，还有其他吗？
 
    [L] 或许文档的意义重要的在于项目的"repeatable"，"repeatable"前几天刚刚从项目管理部经理哪里听来的新词，具体的含义我想大家可以讨论。或许文档可以帮助我们总结经验教训，记录我们突然间的思想的火花，遇到同样的项目可以提供经验。
 
    [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的初衷有些背离。