java程序员在交接别人的工作时如何保证顺利交接？
序言各位好啊，我是会编程的蜗牛，作为java开发者，尤其是在职场混迹了多年的老手，肯定会遇到同事离职的情况，或者自己跳槽的情况，这些都免不了需要做好交接工作，不管是别人交接给我们，还是我们交接给别人~刚转型进入java软件开发行业的前几年，我也是基本上一年跳槽一家公司，从来只有我把我的工作交接给别人的份，还没遇到别人要离职要交接给我的情况。但是最近几年，自己也不那么热衷于跳槽了，想想还是需要在一家公司多做些时间，一来频繁跳槽，写简历的时候，不太好写。二来，也确实很麻烦，交接给别人需要耗费很大的时间精力，要是遇到离职、入职流程贼复杂的公司，就非常蛋疼。刚好，最近有一个同事要离职了，可能是到了秋招季节，找到了更好的下家。领导让我去接他的项目，这个我之前就有预感他要离职了，没想到还成真了。话说，现在秋招现在还处于交接的过程中，我就简单说一下我认为交接别人的工作时，需要如何做，才能保证以后自己尽量不掉进坑里，只能说尽量了。代码毫无疑问，代码的交接肯定是最重要的，这也是我花的时间最多的一个地方。这代码不看不知道，一看吓一跳，基本上很少有注释。也就是属于只有他自己能看懂的情况。这让我想起了一个笑话，说程序员最讨厌的两件事，一件是让自己写注释，一件是别人不写注释。所谓己所不欲勿施于人，所以我们平常自己写代码的时候，也需要注意，该加的注释还是要加上。除非真的不需要或者代码可以自注释。 https://img2022.cnblogs.com/blog/1679109/202210/1679109-20221024215652742-214414724.png 像平常的普通逻辑其实还好，主要是他的系统涉及到很多业务相关的字段，光一个数字放在那边，根本就不知道代表什么。所以这块，我也是自己先大致看了一遍他的代码，从头到尾梳理了一遍，大致的逻辑了解后，就开始自己整理不明白的地方，然后我找他一个个跟我讲一下，我就把对应的注释加上。至此，注释这个问题，总算得到解决，但这还只是万里长征第一步。本地运行 接下来就是在我本地运行下他的代码了。正常来说，这里肯定也会问题。果不其然，由于他用的是IDEA的最终版，而我用的是社区版，如果大家都是运行springboot项目的话，应该也不会有问题，就是把jdk版本配一下，maven配一下，最多仓库啥的也搞成一样就可以了。https://img2022.cnblogs.com/blog/1679109/202210/1679109-20221024215652633-2095991797.png但问题就在于这个项目是那个需要用tomcat来运行的项目，他终极版的话，可以支持直接配置tomcat，并且直接设置项目为Web项目。但是我这个就得需要装个smartTomcat的插件，然后再自己配置下。但就算是这样，最终我启动项目的时候，程序还是报错了。看程序的报错，好像是找不到某个xml文件，但这只是表面现象。经过我的仔细对比，他项目编译启动后和我编译启动后的目录结构，我发现还是不一样的。且我最后发现他最终版还在【Artifact】的设置这边，也有进行一些output的设置，但我的这个无法找到合适的Web类型进行设置。那么到底该怎么办呢？一个当然是装一个最终版的IDEA，不过由于一些众所周知的原因，先不打算装了。那还有一个办法，就是搬出已经多年不用的eclipse老古董。因为听他说这个项目，之前别人都是用eclipse开发的，听到这句话，我就放心了。 https://img2022.cnblogs.com/blog/1679109/202210/1679109-20221024215652933-748725616.png虽然我已多年不用eclipse了，但好歹以前用过好几年，虽然有些忘记了，但稍微弄一下，就又知道了。这里就不多赘述了，反正用eclipse就是可以运行这个项目，适应性很好，只需简单的基本配置即可，这一点倒是比IDEA要方便多了，看来以后还是要两个IDE工具都要啊。那到这里，交接工作里的重头戏算是结束了。账号密码这里说的账号密码，包括各种各样的，像数据库连接的链接，账号，密码、业务系统界面访问的账号密码，其他业务支持系统如消息队列，redis，kafka，外部接口等密码，服务器访问的链接，账号，密码等。这些一定需要了解清楚，最好是记录在一个文件里面。虽然代码的配置文件里面可能也可以找到，但还是建议单独写到一个文件里面。另外，也可以使用浏览器的自带记住密码的功能，帮助我们简化输入密码操作，也很安全。反正他这个项目，各个各样的账号密码实在太多了，我都是见一个记录一个，有时候我甚至怀疑他自己也忘记了。小伙伴们可能要问了，这么多要记住的，我一开始根本不知道要记住哪些啊，所以，接下来就引出下一个问题，当项目启动了，我们就需要进行实际页面操作了，只有进行实际的操作了，才能知道自己还不了解什么，就会反过来让我们去更加深入的了解。 业务操作如果说之前的代码，本地运行，知道基本的账号密码等是完成基本的交接，那么业务操作，像在界面上实际处理业务等，就是让我们从客户的视角，去了解这个项目，这样也能帮助我们更好的熟悉业务系统。可能之前对于代码里面一些不了解的处理逻辑，到了界面上稍微点一点就能知道其中的逻辑了。在系统上操作的时候，还需要问一下到底有多少账号，分别有什么角色，不然如果只用一个账号的话，可能界面上看到的元素，功能是残缺的，这不利于我们了解系统。我就是仔细问了下他，这个系统有哪些角色，有哪些不同，分别用不同的账号登录进去进行了解。然后，我在使用的过程中，居然还发现了几个BUG，只能说非常惊喜，大哥，这个几个BUG改完再走啊。还好发现了，不然就是我改了。 除了使用系统之外，还有一个很重要的操作，那就是部署上线。 部署上线 我们最终的目的肯定是为了能够实现自己部署系统到生产环境，不然代码了解的再熟悉，也没用。所以，我每次逮到他要上线的时候，都会让他共享下屏幕，看他实际操作一遍。有时候一遍记不住，那就把视频录一下，回去自己再多看一遍。其实，这种部署的话，一般也是会有部署文档的，这个参照部署文档一般也不会有什么问题，但我还是相信，能看别人实际操作的，就不要看文档了，文档可以放在一边，作为一个参考。况且，实际生产环境的部署也是比较复杂的，部署文档上写的只是我们进入服务器之后的操作，但是如何进入服务器，并没有说清楚，也没有文档说明。我们这个服务器是需要通过堡垒机登录的，比一般的SSH直连的要复杂，又是密码，又是验证码的，还需要自己电脑上安装特定的SSH工具才行，所以，这些都是跟着他看一遍，才能知道的。有时候，我想他也不是故意不说，只是他自己也忘了。 https://img2022.cnblogs.com/blog/1679109/202210/1679109-20221024215652842-2057665803.png 资料文档资料文档既是对于上面说的一些内容的补充，又包含其他的一些资料，比如用户手册，各类开发文档，什么需求文档，设计文档，测试文档之类的，如果他有的话，就让他全部都给你，毕竟有总比没有强。可以先稍微看一下，后面如果有用到，再来仔细翻阅看看。我其实也太喜欢看文档，但是，我认为它还是非常重要的，他会帮我兜底。除非是那种别人写得一塌糊涂的文档，不然还是值得一看的。 总结说了这么多，就是希望大家在接别人的项目的时候，能够从多个角度去思考，怎么样把它做的更好。希望能给你一些启发。 推荐阅读 点击标题可跳转Tabby，一款老外都在用的 SSH工具，竟然还支持网页操作如何用Virtualbox搭建一个虚拟机JetBrains Fleet初体验，如何运行一个java项目IDEA 调试起来太费劲？你需要了解这几招！免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]