<script type='text/javascript'>	google_ad_client = 'pub-1249130820803772';google_ad_slot ='5203108717';	google_ad_width = 728;google_ad_height = 90;</script><script type='text/javascript'src='http://pagead2.googlesyndication.com/pagead/show_ads.js'></script>
<title>[交流贴]关于程序员的工作交接</title><h1>[交流贴]关于程序员的工作交接</h1><br><br/>------<br/>做为一个程序员，难免会碰上因同事离职接手新系统，如果碰巧你又是这家公司的新人，在业务不熟悉的情况下，需要考虑哪些事项呢。<br /><br />1. 文档资料。<br /><br />虽然大多数系统文档资料匮乏，但以下资料是必须的。<br /><br />应用程序部署图：应用程序（或服务）部署在那台服务器上，和其相关的服务器有哪些？比如缓存通知服务，数据库服务器等等分别部署在那台服务器上，互相之间可能有什么影响？<br /><br />数据字典：总得知道数据库表和字段的意义。<br /><br />系统说明文档：系统上线时间、功能介绍、运营风险、部署环境和形式、文档位置、源代码位置。<br /><br />其他文档：越多越好，未必会看，但留着备用总是好的。<br /><br />2. 源代码相关<br /><br />源代码与线上版本是否一致？如果不一致，原因？引用的dll来源？是否有相关说明或源代码？<br /><br />离职同事在讲解代码时，直接注释到源代码中。<br /><br />一般来说此时讲解业务流程未必能清楚，先记录下来。<br /><br />3. 应用程序是否有日志记录（主要是异常处理）。<br /><br />没有日志记录的系统维护起来就是一场噩梦。曾经见过一个投诉率极高的系统，日志少且只记录成功的信息，catch块从来就是ruturn null或者ruturn false...&nbsp; <br /><br />最好能有离职同事提供系统常见问题的可能原因及解决方案（一般而言如果能知道问题的根本原因，就可以避免此问题，所以此时往往只能知道可能发生的问题，但具体原因未必能知道，但有个临时解决方案比如重启某个服务好歹能让自己有喘气检查问题的时间）<br /><br />4. 是否有测试环境，测试数据库服务器地址？<br /><br />尽可能让离职同事协助自己成功编译部署一次系统。<br /><br />了解系统引用的资源位置（比如可能会发现系统引用的一些配置文件的路径只能在D:\XXX目录下）。<br /><br />注意测试环境和正式环境是否一致（如测试环境是.NET Framework 3.5的，正式环境是.NET Framework 2.0的，上线会带来不必要的麻烦）。<br /><br />5. 如果是Web应用程序，需要注意web服务器上其他服务和应用程序的情况。<br /><br />经常出现的一种情况，一台服务器的某个服务把Socket端口耗尽，导致其他的服务或应用程序全都不能正常运行。<br /><br />至于其他的离职交接单往往是走个形式，这里就略过了。<br /><br /><span style="color:#FF0000">个人抛砖引玉，也希望跟帖的朋友能说说自己的看法，积分将送给有价值的回复，谢谢！</span><br /><br /><br /><br/>------<br/>sf...<br/>------<br/>文档的移交是必需的 &nbsp; <br /><br />代码的移交 就要慎重<br /><br />最好能让移交者将代码核心逻辑画成UML图 交给被移交者<br /><br />最后来个移交确认单<br /><br />接收者保证搞清楚了才能签字<br />移交者拿不到确认单 不能离职<br /><br /><br/>------<br/>好多公司不正规，只是交接下手头的工作<br/>------<br/>如果有专门的文档管理员的话，交接工作比较容易开展<br/>------<br/>移交确认单 个人觉得还是很有必要的<br /><br />它提高了移交者和接收者的责任心<br /><br />保证了项目在经历几次人员更换后 仍有较高的战斗力<br /><br />否则几次人员变动后 会出现移交者没什么可移交的<br /><br />接收者没什么可接收的情况<br/>------<br/><div><fieldset><legend>引用 2 楼 q107770540 的回复:</legend><br />接收者保证搞清楚了才能签字<br />移交者拿不到确认单 不能离职<br /></fieldset><br/>------<br/><div><fieldset><legend>引用 5 楼 q107770540 的回复:</legend><br /><br />移交确认单 个人觉得还是很有必要的<br /><br />它提高了移交者和接收者的责任心<br /><br />保证了项目在经历几次人员更换后 仍有较高的战斗力<br /><br />否则几次人员变动后 会出现移交者没什么可移交的<br /><br />接收者没什么可接收的情况<br /></fieldset><br/>------<br/>这就要看 出这个 确认单 的人了<br /><br />确认单的详细与否决定交接的时间及进度<br /><br />一般确认单还有个核准人 核准交接结果<br/>------<br/><div><fieldset><legend>引用 8 楼 q107770540 的回复:</legend><br /><br />这就要看 出这个 确认单 的人了<br /><br />确认单的详细与否决定交接的时间及进度<br /><br />一般确认单还有个核准人 核准交接结果<br /></fieldset><br/>------<br/>通常情况 大概指导下<br /><br />之后再找到相关的 开发人员 进行了解<br /><br />而不是某个人走了，这个项目就垮了<br/>------<br/><img src="http://forum.csdn.net/PointForum/ui/scripts/csdn/Plugin/003/monkey/1.gif"  alt="" /><br/>------<br/>我交接的时候就用了5分钟,哎..经理让我稍微给她说了下项目文档和源代码存在电脑哪个位置,其他的都没让我说.<img src="http://forum.csdn.net/PointForum/ui/scripts/csdn/Plugin/003/monkey/2.gif"  alt="" /><br/>------<br/><div><fieldset><legend>引用 10 楼 jaylongli 的回复:</legend><br /><br />通常情况 大概指导下<br /><br />之后再找到相关的 开发人员 进行了解<br /><br />而不是某个人走了，这个项目就垮了<br /></fieldset><br/>------<br/>文档交接不全是个大问题，等用时再找就挂了<br /><br />正规的公司还行，基本上不会出现文档不存在，顶多不是最新版本。但一般的小公司就麻烦了，甚至可能本身文档就不全。<br />再加上没有一个统一的管理，只某个人手里有某份文档，如果恰好忘了，或者不知道文档那个是最后版本了，就很无奈了。移交工作时，不会再想着重新给整理补充。<br/>------<br/>这个东西真不好说，有些小公司就基本没什么文档的。<br />最重要的还是代码。<br/>------<br/>不可能给接手的员工讲每行或每个方法的意思，<br />公司管理、制度...很重要。<br/>------<br/><div><fieldset><legend>引用 13 楼 amandag 的回复:</legend><br />有些公司的系统基本就是1个人管1块，所以有时候主力程序员的离职会有比较大的影响<br /></fieldset><br/>------<br/>小公司 。 不存在这些<img src="http://forum.csdn.net/PointForum/ui/scripts/csdn/Plugin/003/onion/10.gif"  alt="" /><br/>------<br/><div><fieldset><legend>引用 2 楼 q107770540 的回复:</legend><br />文档的移交是必需的  <br />代码的移交 就要慎重<br />最好能让移交者将代码核心逻辑画成UML图 交给被移交者<br />最后来个移交确认单<br />接收者保证搞清楚了才能签字<br />移交者拿不到确认单 不能离职<br /></fieldset><br/>------<br/>源代码本身就是文档。源代码本身是否整理得清楚明白是第一位的。<br /><br />其它重要文档主要是设计思路，最好附带有多种设计方案的利弊分析和取舍缘由。<br/>------<br/>路过，kanyiia~!<br/>------<br/>一台服务器的某个服务把Socket端口耗尽，导致其他的服务或应用程序全都不能正常运行<br/>------<br/>小公司一般只注重于手上的活。。。<br /><br />别带走源码。。。做个交接文档就行了<br/>------<br/>我去公司的时候，只给我三张纸的文档，其他的都木有，程序自己改动过哪些的都没有，搞得我一头雾水。况且之前的程序员离我上任时已经2月有余了，真杯具啊我。<br/>------<br/>mark<br /><br/>------<br/>ding~!<br/>------<br/>到公司的时候 什么都没有 就一句话&nbsp; <br />结果还给错版本了<br />现在想来都生气&#183;&#183;&#183;&#183;&#183;&#183;&#183;&#183;&#183;<br/>------<br/>如果是维护的话除了LZ说的环境之外还要有测试文档、用例之类~<br />最好能把需求式样之类也交付~<br/>------<br/>一个项目应该有个具体的负责人，找他了解 相关的信息<br />然后自己在熟悉一下<br /> &nbsp;只要不是很大的项目，熟悉业务，代码应该不是很困难<br/>------<br/>LZ讲的很有道理，不过几乎不能实现<br />如果别人这些工作都很得很好，他也用不着离职<br /><br />可以这样说，花1小时写的代码，可能要花8小时去写你所谓的文档<br /><br />如果在写代码之前就有文档的，SOP、SA、SD都有，那也用不着交接<br /><br />所以，LZ讲的是伪命题<br /><br /><br/>------<br/>我的打酱油的 <br/>------<br/>如果平时写代码注意注释就不会出现交接难的问题。<br/>------<br/>#$#$#$#$#$#$#$#$#$#$#$#$#$<br/>------<br/><img src="http://forum.csdn.net/PointForum/ui/scripts/csdn/Plugin/003/monkey/5.gif"  alt="" /><br/>------<br/>离职=扔代码跑路=等下个人帮你擦屁股=解脱~~~~~<br/>------<br/>飘过~~~~<br/>------<br/>学习了...<br/>------<br/>那有交接，上一任直接走了，什么文档都没留，看天书<br/>------<br/>我现在接受的项目很纠结啊，只有源代码， 我勒个去！真TM恶心！<br />不过现在都习惯了，我们公司的产品一贯没有文档之类的，吐血～～～<br/>------<br/><div><fieldset><legend>引用 17 楼 q107770540 的回复:</legend><br />引用 13 楼 amandag 的回复:<br />有些公司的系统基本就是1个人管1块，所以有时候主力程序员的离职会有比较大的影响<br /><br />这我觉得就是公司的问题了<br />同样的开发 为何不采取轮岗制 <br />一人开发此模块 但是他不一定就要负责此模块的BUG修改<br />一块代码 改的人多了<br />有两种结果:1.所有人都不认识它了<br />  2.所有人都认识它了<br /></fieldset><br/>------<br/><img src="http://forum.csdn.net/PointForum/ui/scripts/csdn/Plugin/003/monkey/2.gif"  alt="" /><br/>------<br/>回贴，送积分吗？<br/>------<br/>不错。，。。<br/>------<br/>4. 是否有测试环境，测试数据库服务器地址？<br /><br />尽可能让离职同事协助自己成功编译部署一次系统。<br />这个一定得做。不然自己编译的话可能会出现很多莫名的问题。、<br/>------<br/>主要还是要有原来人员的联系方式，有问题随时问，起码要求几个月的支持<br/>------<br/>主要还是要有原来人员的联系方式，有问题随时问，起码要求几个月的支持<br/>------<br/><div><fieldset><legend>引用 35 楼 herott632482577 的回复:</legend><br /><br />离职=扔代码跑路=等下个人帮你擦屁股=解脱~~~~~<br /></fieldset><br/>------<br/>代码的移交 就要慎重<br /><br/>------<br/><img src="http://forum.csdn.net/PointForum/ui/scripts/csdn/Plugin/003/onion/52.gif"  alt="" />这么麻烦<br/>------<br/>刚进IT圈，学习ing。thanks<br/>------<br/><div><fieldset><legend>引用 24 楼 lxm88168 的回复:</legend><br />我去公司的时候，只给我三张纸的文档，其他的都木有，程序自己改动过哪些的都没有，搞得我一头雾水。况且之前的程序员离我上任时已经2月有余了，真杯具啊我。<br /></fieldset><br/>------<br/>mark，多问<br/>------<br/><div><fieldset><legend>引用 41 楼 hwbox 的回复:</legend><br />引用 17 楼 q107770540 的回复:<br />引用 13 楼 amandag 的回复:<br />有些公司的系统基本就是1个人管1块，所以有时候主力程序员的离职会有比较大的影响<br /><br />这我觉得就是公司的问题了<br />同样的开发 为何不采取轮岗制<br />一人开发此模块 但是他不一定就要负责此模块的BUG修改<br />一块代码 改的人多了<br />有两种结果:1.所有人都不认识它了<br />2.所有人都认识它了<br /><br /><br />做为一个……<br /></fieldset><br/>------<br/><img src="http://forum.csdn.net/PointForum/ui/scripts/csdn/Plugin/003/monkey/2.gif"  alt="" /><br />是个好主意！<br/>------<br/>所以要做好准备哦<br/>------<br/>值得借鉴<br/>------<br/>虽然路还很远，不过这些东西还是值得学习<br/>------<br/>文档，列表清单，未完成代办事宜，各项目联系接头人；&nbsp; <br />项目维护常见问题，接口汇总，部署常见问题<br/>------<br/>接分来了<br/>------<br/>  不太喜欢交接~<br/>------<br/><div><fieldset><legend>引用 30 楼 youngsheep 的回复:</legend><br /><br />LZ讲的很有道理，不过几乎不能实现<br />如果别人这些工作都很得很好，他也用不着离职<br /><br />可以这样说，花1小时写的代码，可能要花8小时去写你所谓的文档<br /><br />如果在写代码之前就有文档的，SOP、SA、SD都有，那也用不着交接<br /><br />所以，LZ讲的是伪命题<br /></fieldset><br/>------<br/><div><fieldset><legend>引用 55 楼 xiaoyilong19 的回复:</legend><br /><br />对啊，一个功能一个人实现，自己包测试，这么干，符合小公司的实情，<br />……<br /></fieldset><br/>------<br/>  接分。<br/>------<br/>补充一下，可能更加可实施，这一点可能做外包的流程可能比较好吧。<br /><br />1.交接的事前准备<br /> &nbsp; 参加者：PL(SL)/交接者<br />(1) 说明负责工作内容，项目整体介绍，干系人介绍，体制说明<br /> &nbsp;    说明：让新人尽快融入团队，了解项目，了解各个接口，了解自己要做什么<br /> &nbsp;    成果物：工作一览表(职责一览表)<br />(2) 做交接计划，同时检查任务是否有残留<br /> &nbsp;    说明：让新人检查要走的人是否还有暂留的问题，心里有个数，同时合理安排交接时间<br /> &nbsp;          也便于上面跟踪检查<br /> &nbsp;    成果物：交接Schedule<br /><br />2.交接的具体实施<br /> &nbsp; 高歌上面所提内容已经很具体了。。。<br /><br />3.交接的实施检查<br /> &nbsp; 检查Schedule实施情况，了解新人的困难(不是谁都能在1周或者几天内100%消化几个月甚至好几年的项目的)。可能需要别人支援，同时要根据交接结果重新调整计划。避免风险。<br /><br />PL/SL绝对是一线的管理人员，想要好的结果，PL/SL一定严格控制。<br />另外，一方面要在项目管理过程中要尽早的发现风险。比如：发现有人要离职，那么新人选和交接时间就要提前想好了。不要幻想离职的人会尽心尽力交接，这应该是PL的责任。(后面有点跑题了）<br /><br />其他还有些关联的：比如项目过程中收集新人培训资料，以便交接前先为交接者培训等。<br/>------<br/>呵呵，这个是PL角度出发的交接流程 ：）<br/>------<br/>前人的代码往往很烂，否则给个框架设计及详细设计即可。<br/>------<br/>他会留一手的吧<br/>------<br/>学习学习<br/>------<br/>深有感触。本人刚来这个公司时，就是一个什么文档都没有的系统。但是系统日志还是比较全的。出了错可以很好很快的解决。<br />但是没有文档，系统更新，维护，二次开发真TMD难啊。连一个数据库各个表什么用都没有。别说表的字段什么意思了。<br />刚来公司时还让原开发者给我讲，靠，没文档，老大一个系统，又不是他一个人全做的。讲起来他自己都迷糊了。哎。。。<br />文档太TMD重要了。可以国内的软件公司太浮躁，重视文档的不多！<br/>------<br/>可以==可惜<br />刚才打错字了<br/>------<br/>其实交接的好坏和负责这件事的管理者有很大的关系，有些管理者自身事情比较多，重视度不够，交接的时候马虎过关，记得有个网站接手只有前台页面aspx的代码，后台就是一个dll，维护的时候那一个痛苦<br/>------<br/>学习中……<br/>------<br/>很好很受益..<br/>------<br/>文档很重要    代码也是   别藏藏躲躲的  &nbsp; <br /><br />这样的人在哪里走不被别人喜欢 <br/>------<br/>养成日常写文档的习惯，不要吝啬给自己的代码多加注释，这样移交起来，就很方便了。<br/>------<br/>注释+文档记录很重要<br/>------<br/>最好能把需求式样之类也交付<br/>------<br/>交接的只是有形的东东,无形的都被带走了<br/>------<br/>谢谢了，领会精神<br/>------<br/>3Q。。。<br/>------<br/>写的太好了<br/>------<br/>路过看看<br/>------<br/>好贴，收藏<br/>------<br/>文档或者注释的事情，也就这个时候可以夸张一下。但是夸张于交接时的难度，难道对整个开发就能起促进作用吗？我看未必。<br /><br />其实，为什么你的公司总是让一个什么都不懂的新人负责接手老人的代码，这个想过吗？！<br/>------<br/>这里边一定有一个全面、务实、平衡的要求，而不是站在什么都不太懂的新人的角度来看项目管理。<br/>------<br/>MARK<br/>------<br/>在一个比较正常的XP（极限编程）开发团队中，看看平常是怎么开发的就知道，所有人都懂代码（所有人都有责任和义务修改代码，而不是私有），PM有意地几乎每天都给人员变换任务（例如经常让精通数据库的人去做通讯，而让精通美工的人去做数据库），有机制保证紧张而高效率地交流，保证有高层次的自动化测试并且人人都会（实际上如果你参与一些流行的开源软件，产品中都会同时也提供几千个自动化测试），所有人的水平越来越接近于较高水平（而不是故意弄一个特别高水平的人带一帮特别廉价特别水平低的人），每一两天就可以发布一个产品版本给用户，设计上追求简单和善于重构等等。<br /><br />我不强调交接时的问题，这没有什么解。唯一的解，就在于平常团队的素质，这时候才真正做到“铁打的营盘流水的兵”丝毫纹丝不动。<br/>------<br/>ARK<br/>------<br/>急需积分，就来评价评价……<br/>------<br/>我手上有5-6个ERP项目要交接，还要开发新的代码，真TM不爽。LZ这贴真是及时啊。可惜老板没有看到，不然我又要多很多工作了。<br/>------<br/>好东西 。<br />下周接别人工作 。<br/>------<br/>每天冒泡，挣点分！！<br/>------<br/>需求文档<br />设计文档<br />源码<br />软件流程图<br />更改文档<br/>------<br/>嗯 ，收益匪浅！<br/>------<br/>学习了<br/>------<br/>需求文档<br />设计文档<br />源码<br />软件流程图<br />更改文档<br/>------<br/>哈哈 学习了<br/>------<br/>学习拉<br/>
<script src='http://s39.cnzz.com/stat.php?id=533357&web_id=533357&show=pic2' language='JavaScript' charset='gb2312'></script>

桂ICP备07017180号