程序员交接文档_程序员接受了前同事的代码要怎么做？

看前同事留下的代码&＃xff0c;无非有两种感觉&＃xff1a;

1、自己看不懂&＃xff0c;惊为天人。

2、写得太烂&＃xff0c;自己嗤之以鼻。

说实话&＃xff0c;你的这个问题&＃xff0c;让我想起来之前接手同事代码的惨痛经历。

接手代码太烂&＃xff0c;要不要辞职&＃xff1f;

事情是这样的&＃xff0c;前几天在朋友圈&＃xff0c;我看到一朋友发表了一条说说&＃xff1a;“入职新公司&＃xff0c;从重构代码到放弃

”&＃xff0c;我就问他怎么了&＃xff1f;他说&＃xff0c;刚进一家新公司&＃xff0c;接手代码太烂&＃xff0c;领导让我先熟悉业务逻辑&＃xff0c;然后去修复之前项目中遗留的bug&＃xff0c;实在不行就重构。

关键是&＃xff0c;离职的那位仁兄走之前&＃xff0c;还跟我在QQ上说&＃xff0c;老哥辛苦了&＃xff0c;我写的很乱真不好意思&＃xff0c;但我是故意的。

这几天&＃xff0c;我都在想&＃xff0c;要不要离职&＃xff1f;

听完你的遭遇&＃xff0c;我想先说一句&＃xff0c;离职那位仁兄太狠了&＃xff01;&＃xff01;&＃xff01;

其次&＃xff0c;我相信&＃xff0c;这个问题很多人都遇到过。

每个新人去一家新公司都会觉得公司代码很烂&＃xff0c;可能是因为他没被产品虐过。

其实&＃xff0c;这种新员工很不错了&＃xff0c;一看就是真萌新&＃xff0c;重构这种事&＃xff0c;老板看不到 KPI&＃xff0c;出了事还得自己兜底&＃xff0c;还会得罪人&＃xff0c;费力不讨好&＃xff0c;何必呢&＃xff01;

老前辈的警世良言一定要牢记&＃xff1a;重构一时爽&＃xff0c;头发不再长。

还有&＃xff0c;工作了10年的码农&＃xff0c;到了新公司&＃xff0c;绝不会说这种话。

不过话说回来&＃xff0c;能觉得模块代码烂&＃xff0c;还能撸起袖子去改的程序员&＃xff0c;真是很难得的一种精神。我身边 90%都是只是嘴上说&＃xff0c;绝对不动手干的。下一次下一次下一次&＃xff0c;无数的下一次造就了烂代码。

「 要不要重构 」

很多人口中的重构就是重写&＃xff0c;而不是去改善现有的代码。

现在的有些工程师太浮躁, 动不动就要重构, 就跟很多的团队动不动就要搞一个框架一样。

说实话&＃xff0c;以我个人的经验来说&＃xff0c;绝大多数开发人员到新公司后&＃xff0c;都会觉得代码很烂&＃xff0c;但通常他不了解业务逻辑是怎么变化的&＃xff0c;这种代码是在什么情况下写出来的&＃xff0c;有什么特殊的背景(除了真的是乱搞的&＃xff0c;绝大多数的“烂代码”一般都是有原因的&＃xff1a;业务需求改改改&＃xff0c;这个需求明天就要上线等等等等)&＃xff0c;有多少坑(很少有人能在极短时间内把所有的坑都找出来)。

如果贸然去重构&＃xff0c;风险非常大。而且再说难听点&＃xff0c;就算重构完了&＃xff0c;也有可能是一堆新的“烂代码”替换老的“烂代码”。

所以&＃xff0c;进了一家新公司&＃xff0c;别动不动就重构&＃xff0c;先了解项目的业务逻辑。

「 要不要离职 」

其实在我看来&＃xff0c;如果仅仅因为接手代码太烂&＃xff0c;就选择离职&＃xff0c;那么你跳槽到下一个公司依然会面对同样的现状&＃xff0c;因为几乎每个人&＃xff0c;都会觉得自己公司的项目代码很烂。

我们先说说造成这种现象的原因是什么&＃xff0c;首先&＃xff0c;我们得相信&＃xff0c;没有任何一个人故意把自己的代码写的很烂&＃xff0c;每个人都想把自己的代码写的很优雅&＃xff0c;扩展性很好&＃xff0c;但是可能当初水平不够&＃xff0c;在当时看似还不错的代码&＃xff0c;日后在别人看来就是所谓的垃圾代码。

我们每个人都在进步&＃xff0c;别说别人了&＃xff0c;你现在看你三个月之前的代码&＃xff0c;可能你都会觉得写的很垃圾&＃xff0c;如果你没有这种感觉&＃xff0c;只能说你在止步不前。

其次&＃xff0c;技术更新换代太快&＃xff0c;市场的变化也太快&＃xff0c;产品自然也一直在演变&＃xff0c;也许在当时看起来还不错的代码&＃xff0c;随着时间的推移&＃xff0c;功能的更新&＃xff0c;代码的堆彻&＃xff0c;慢慢就变成后来者眼中的烂代码了。

「 如何从烂代码中爬出来 」

假如你真的要接手别人的代码&＃xff0c;怎样才能不被玩儿死呢&＃xff1f;

虽然你可能会说&＃xff0c;听了很多道理&＃xff0c;依然交接不好代码&＃xff0c;可作为经常被别人的代码玩得欲仙欲死的老司机&＃xff0c;我有些话如鲠在喉&＃xff0c;不吐不快。

当你被要求接管要离职的程序员的代码时&＃xff0c;如果能注意以下几点&＃xff0c;就有可能活着从他的代码里爬出来。

1. 产品需求与业务流程文档

产品需求与业务流程文档&＃xff0c;这些是你先要找到的&＃xff0c;你接手的代码&＃xff0c;必然和某个产品需求相对应&＃xff0c;必然实现了某个业务流程&＃xff0c;先了解产品需求和业务流程&＃xff0c;才能更好的读代码。

假如你的团队就是没文档&＃xff0c;Ok&＃xff0c;也可以要求离职或转移战线的这位程序员把需求描述出来&＃xff0c;把业务流程画出来。

2. 测试环境

了解了产品需求和业务流程&＃xff0c;最好能体验一下软件&＃xff0c;从用户的角度来理解软件的使用。这个时候你要么需要生产环境&＃xff0c;要么需要测试环境。哪个环境不重要&＃xff0c;重要的是&＃xff0c;你需要一个能Run&＃xff0c;能体验的软件。

3. 业务流程在代码层面的体现

负责交接代码给你的那位同事&＃xff0c;要么在办离职&＃xff0c;要么已经介入了其他产品&＃xff0c;眼下很可能已无心恋战&＃xff0c;但你心里要清楚&＃xff0c;只有他才能提供代码层面的东西&＃xff0c;比如类图、模块划分说明、数据流图、时序图、状态图等等。

所以&＃xff0c;你需要他整理一些文档和图表出来。你可以告诉领导你需要上面的东西&＃xff0c;让领导和他沟通&＃xff0c;让他在离开之前准备好这些文档给你&＃xff0c;并留一些时间以便你熟悉。

4. 读代码&＃xff0c;不死不休

有了产品需求&＃xff0c;有了业务流程&＃xff0c;有了代码设计相关的文档和图表&＃xff0c;接下来你就该死磕代码了&＃xff1a;

while(不懂)

{

读

}

5. 开发环境与调试

有的产品需要比较复杂的开发环境配置&＃xff0c;一定要提前做好&＃xff0c;让即将离开的同事辅导你搭建好开发环境&＃xff0c;这样你就可以利用“调试”这个强大的武器来快速理解代码了。

调试是接手别人代码时的利器&＃xff0c;如果你看不明白一个业务在代码层面是怎么体现的&＃xff0c;也看不懂代码之间的调用关系&＃xff0c;那最好的办法就是调试。从一个业务的起点所对应的代码开始调试&＃xff0c;一步一步跟进去&＃xff0c;就能快速理清函数调用链。

6. 树立可实现可衡量的目标

程序员的工作交接&＃xff0c;尤其是代码交接&＃xff0c;怎样才算顺利完成呢&＃xff1f;

这简直就是一个谜&＃xff01;

没人说得清楚。

所以&＃xff0c;你最好给自己梳理一些可衡量的、可实现的目标。比如读懂A、B、C三个业务流程……

最好&＃xff0c;找一个Bug或者一个新增的功能&＃xff0c;带着目的去读代码、修改代码&＃xff0c;有目的&＃xff0c;有目标&＃xff0c;有时间盒&＃xff0c;就容易投入&＃xff0c;容易读进去&＃xff0c;容易掌握与Bug或新增功能相关的代码的逻辑与流程。

7. 输出、分享与重构

你在读代码时&＃xff0c;如果能撇开给你交接工作的程序员提供的文档&＃xff0c;按自己的理解&＃xff0c;自己绘制类图、数据流图、时序图、关键业务流程对应的函数调用关系链等&＃xff0c;就能更快的掌握别人的代码。

如果你还能将你理解到的东西&＃xff0c;讲给其他人听&＃xff0c;并且讲明白&＃xff0c;那Ok&＃xff0c;你真的理解了别人交接给你的代码。

再进一步&＃xff0c;如果你在理解现有代码的基础上&＃xff0c;可以识别出哪些部分实现得逻辑不清晰或有待改善&＃xff0c;然后可以结合业务与自己的理解将其重构&＃xff0c;那就真的是完全接手了别人的代码&＃xff0c;别人的代码与你的代码就没有差别了&＃xff0c;它们终将成为你的代码。

「 最重要的事儿 」

如果你总是看见代码多就发愁&＃xff0c;看见代码脏乱差就诅咒埋怨&＃xff0c;看见代码逻辑复杂就头疼&＃xff0c;搞不清调用关系就放弃&＃xff0c;那你可能永远也变不成代码的主人&＃xff0c;只能一次又一次被代码蹂躏。

所以&＃xff0c;其实交接代码最重要的事儿&＃xff0c;就是&＃xff1a;

不要被浩渺如烟并且陌生怪诞的代码吓得不敢动弹&＃xff0c;现在就开始读&＃xff0c;立刻&＃xff0c;马上&＃xff0c;坚持十分钟&＃xff0c;再坚持十分钟&＃xff0c;你就能妙悟真谛。

最后&＃xff0c;当你再碰到这种事儿的时候&＃xff0c;请记住老前辈的这句警世良言&＃xff1a;

那些不能将你击溃的代码&＃xff0c;都将成为你成长的垫脚石。

如果你身边有朋友&＃xff0c;正在接手别人代码&＃xff0c;被逼的想要重构&＃xff0c;请将这篇回答转发给他&＃xff0c;普度芸芸众码农&＃xff0c;是我义不容辞的责任。

“我自己是一名从事了10多年java的架构师了&＃xff0c;今年年初我和伙伴们花了三个月整理了一份最适合进阶架构师学习的Java 学习干货&＃xff0c;从最基础的底层原理 &＃xff0c;到项目实战&＃xff0c;

领取更多架构视频资料

转发文章后&＃xff0c;关注我后台私信回复【java架构】领取获取往期Java高级架构资料、源码、笔记、视频。Dubbo、Redis、设计模式、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术