入职新公司，从重构代码到放弃，这个劫怎么破？
日期：2018-11-25
来源：程序思维浏览：3665次
每当程序员接管其他程序员编写的代码时，通常会吐槽：代码编写的烂，可读性差，不美观，使用的语言有问题......无论如何，其他人编写的代码是在他的眼里。它们都是“烂代码”，并认为它们总能比它们写得更好。
情况就是这样。几天前在朋友圈里，我看到一位朋友说了一句话：“进入一家新公司，从重构代码到放弃”，我问他发生了什么事？
他说刚刚进入一家新公司，接管代码太糟糕了，领导让我先熟悉业务逻辑，然后修复前一个项目留下的bug，实在不行就重构。
关键是，离职的那哥们在走之前，还跟我在QQ上说，老哥辛苦了，我写的很乱真不好意思，但我是故意的。这些天，我在想，要不要离职？
听完他的经历后，我想说一句，离职的那哥们太狠了！ ！ ！
其次，我相信很多人都遇到过这样的问题。每个新公司的新人都会觉得公司代码很糟糕，可能是因为他没有被产品虐过。
事实上，这位新员工非常好。一看就是真萌新，重构这种事，老板看不到关键绩效指标。出了事还得自己兜底，出了事还得自己兜底，还会得罪人。费力不讨好，何必呢！
必须牢记老前辈的警世良言：重构一时爽，头发不再长。
此外，已经工作了10年的码农，当他们到达新公司时，他们永远不会说这些话。
但话又说回来，程序员觉得模块代码不好，但也可以拿起袖子来改变，这真是一种难得的精神。
我身边 90% 都只是嘴上说，绝对不动手干的。下次，下次，下次，无数的下次造就了烂代码。
你想重构吗？
许多人口中的重构是重写而不是改进现有代码。
今天的一些工程师对于重构过于浮躁，就像在很多团队中编写框架一样。
说实话，根据我的个人经验，大多数开发人员在到达新公司后会发现代码不好。
但通常他不了解业务逻辑是怎么变化的。在什么情况下编写这样的代码，有什么特殊的背景（除了真正的乱写，大多数“烂代码”通常都存在原因的：业务需求不断在改，这个需求明天要上线等），有多少坑（很少有人能在很短的时间内找到所有的坑）。
如果你急于重构，风险非常大。说句难听的，即使重构完成，也可能会有一堆新的“烂代码”来取代旧的“烂代码”。
因此，当您进入一家新公司时，您可以在不重构的情况下修改它，首先了解项目的业务逻辑。
你想离职吗？
在我看来，如果你因为接管代码而选择离开，那么当你到下一家公司时，你仍将面临同样的情况，因为几乎每个人都会觉得他们公司的项目代码很糟糕。
我们先来谈谈造成这种现象的原因。首先，我们必须相信没有人故意写烂代码。每个人都希望非常优雅地编写代码并具有良好的可扩展性 。
但这可能是因为原始级别还不够，当时看起来很好的代码，在别人看来就是所谓的垃圾代码。
我们每个人都在进步，更不用说其他人了。你现在看三个月前的代码。你可能觉得它很垃圾。如果你没有这种感觉，你只能说你在止步不前止。
其次，技术更新太快，市场变化太快，产品自然发展。也许当时看起来不错的代码，随着时间的推移，功能更新，代码堆积起来，慢慢地在后来者的眼中变成了一个糟糕的代码。
如何从烂代码中爬出来 ？
如果你真的想接管别人的代码，怎么能不被玩死？
虽然你可能会说，听了很多道理，依然交接不好代码，可作为经常被别人的代码玩得崩溃的老司机。我有些话如鲠在喉，不吐不快。
当你被要求接管正在离开的程序员的代码时，如果你能注意以下几点，你可以活着爬出他的代码。
产品需求和业务流程文档
离职程序员之项目交接
首先找到产品要求和业务流程文档。您接管的代码必须符合产品要求。有必要实施某个业务流程。首先要了解产品需求和业务流程，以便更好地阅读代码。
程序员离开工作后，没有人敢接管代码。
如果您的团队缺乏文档，那么您也可以要求离职或让转移前线的程序员描述需求并绘制业务流程。
测试环境
虽然我看起来很糟糕，但我可以正常运行，但我不敢修改它。
了解产品要求和业务流程，最好从用户的角度体验软件并了解软件的使用。
此时您需要生产环境或测试环境。哪个环境不重要，重要的是您需要一个可以运行和体验的软件。
代码级别的业务流程
负责交接代码给你的那位同事，要么在办离职，要么已经介入了其他产品，眼下很可能已无心恋战。
但是你必须在心里清楚，只有他能提供代码级别的东西，如类图、模块分区描述、数据流图、时序图、状态图等。
所以，你需要他整理一些文件和图表。您可以告诉领导您需要上述内容，让领导与他沟通，让他在离开前为您准备文件，并留出一些时间让您熟悉。
阅读代码，永不消亡
阅读别人的代码有什么样的体验？通过产品需求，业务流程以及与代码设计相关的文档和图表，接下来你就该死磕代码了：
while（不懂）
{
读
}
开发环境和调试
我接管了一个代码库，并最初调整了bug的外观。
有些产品需要更复杂的开发环境配置，请务必提前做好，让离开的同事指导您构建开发环境，这样就可以使用“调试”的强大武器快速理解代码。
调试是一种接管其他人代码的工具。如果您不了解业务在代码层面是怎么体现的，并且您不理解代码之间的调用关系，那么最好的方法是调试。
从对应于业务起点的代码开始调试，并逐步跟进以快速整理函数调用链。
建立可衡量的目标
当我认为这是最后一个bug时，改完就可以去吃饭时……
程序员的工作切换，特别是代码切换，如何成功完成？
这是一个谜！没有人说清楚。所以，你最好理清一些、可以达到的可测量目标。例如，读取A、B、C三个业务流程......
最好找一个bug或一个新功能，目的是读取代码、来修改代码，目的，目标，时间框，易于投资，易于阅读，易于掌握错误或新功能的逻辑和代码流。
输出、共享和重构
在新接手的代码库上 Debug
当你正在阅读代码时，如果能撇开给你交接工作的程序员提供的文档，根据你自己的理解，你可以绘制类图、数据流程图、时序图、关键业务流程对应的函数调用关系连锁等，你可以快速掌握别人的代码。
如果你仍然可以告诉别人你理解的东西，那么好吧，你真的理解别人交给你的代码。
更进一步，如果您了解现有代码，您可以确定哪些部分在逻辑上不清晰或需要改进。
然后你可以结合业务和你自己的理解来重构它，然后它真的接管别人的代码，别人的代码与你的代码没有什么不同，它们最终会成为你的代码。
最重要的是
如果你总是看见代码多就发愁，看见代码脏乱差就诅咒埋怨。看见代码逻辑复杂就头疼，搞不清调用关系就放弃，那你可能永远也变不成代码的主人，只能一次又一次被代码蹂躏。
因此，关于移交代码最重要的事情是：不要被庞大而奇怪的代码吓到，立即开始阅读，立即，马上，坚持十分钟，然后再坚持十分钟，你就能妙悟真谛。
最后，当你遇到这种事情时，请记住一句老话：那些不能将你击溃的代码，都将成为你成长的垫脚石。
如果你身边有朋友，正在接手别人代码，被虐的想要重构，让他看这篇，普度芸芸众码农，是我义不容辞的责任。
情况就是这样。几天前在朋友圈里，我看到一位朋友说了一句话：“进入一家新公司，从重构代码到放弃”，我问他发生了什么事？
他说刚刚进入一家新公司，接管代码太糟糕了，领导让我先熟悉业务逻辑，然后修复前一个项目留下的bug，实在不行就重构。
关键是，离职的那哥们在走之前，还跟我在QQ上说，老哥辛苦了，我写的很乱真不好意思，但我是故意的。这些天，我在想，要不要离职？
听完他的经历后，我想说一句，离职的那哥们太狠了！ ！ ！
其次，我相信很多人都遇到过这样的问题。每个新公司的新人都会觉得公司代码很糟糕，可能是因为他没有被产品虐过。
事实上，这位新员工非常好。一看就是真萌新，重构这种事，老板看不到关键绩效指标。出了事还得自己兜底，出了事还得自己兜底，还会得罪人。费力不讨好，何必呢！
必须牢记老前辈的警世良言：重构一时爽，头发不再长。
此外，已经工作了10年的码农，当他们到达新公司时，他们永远不会说这些话。
但话又说回来，程序员觉得模块代码不好，但也可以拿起袖子来改变，这真是一种难得的精神。
我身边 90% 都只是嘴上说，绝对不动手干的。下次，下次，下次，无数的下次造就了烂代码。
你想重构吗？
许多人口中的重构是重写而不是改进现有代码。
今天的一些工程师对于重构过于浮躁，就像在很多团队中编写框架一样。
说实话，根据我的个人经验，大多数开发人员在到达新公司后会发现代码不好。
但通常他不了解业务逻辑是怎么变化的。在什么情况下编写这样的代码，有什么特殊的背景（除了真正的乱写，大多数“烂代码”通常都存在原因的：业务需求不断在改，这个需求明天要上线等），有多少坑（很少有人能在很短的时间内找到所有的坑）。
如果你急于重构，风险非常大。说句难听的，即使重构完成，也可能会有一堆新的“烂代码”来取代旧的“烂代码”。
因此，当您进入一家新公司时，您可以在不重构的情况下修改它，首先了解项目的业务逻辑。
你想离职吗？
在我看来，如果你因为接管代码而选择离开，那么当你到下一家公司时，你仍将面临同样的情况，因为几乎每个人都会觉得他们公司的项目代码很糟糕。
我们先来谈谈造成这种现象的原因。首先，我们必须相信没有人故意写烂代码。每个人都希望非常优雅地编写代码并具有良好的可扩展性 。
但这可能是因为原始级别还不够，当时看起来很好的代码，在别人看来就是所谓的垃圾代码。
我们每个人都在进步，更不用说其他人了。你现在看三个月前的代码。你可能觉得它很垃圾。如果你没有这种感觉，你只能说你在止步不前止。
其次，技术更新太快，市场变化太快，产品自然发展。也许当时看起来不错的代码，随着时间的推移，功能更新，代码堆积起来，慢慢地在后来者的眼中变成了一个糟糕的代码。
如何从烂代码中爬出来 ？
如果你真的想接管别人的代码，怎么能不被玩死？
虽然你可能会说，听了很多道理，依然交接不好代码，可作为经常被别人的代码玩得崩溃的老司机。我有些话如鲠在喉，不吐不快。
当你被要求接管正在离开的程序员的代码时，如果你能注意以下几点，你可以活着爬出他的代码。
产品需求和业务流程文档
离职程序员之项目交接
首先找到产品要求和业务流程文档。您接管的代码必须符合产品要求。有必要实施某个业务流程。首先要了解产品需求和业务流程，以便更好地阅读代码。
程序员离开工作后，没有人敢接管代码。
如果您的团队缺乏文档，那么您也可以要求离职或让转移前线的程序员描述需求并绘制业务流程。
测试环境
虽然我看起来很糟糕，但我可以正常运行，但我不敢修改它。
了解产品要求和业务流程，最好从用户的角度体验软件并了解软件的使用。
此时您需要生产环境或测试环境。哪个环境不重要，重要的是您需要一个可以运行和体验的软件。
代码级别的业务流程
负责交接代码给你的那位同事，要么在办离职，要么已经介入了其他产品，眼下很可能已无心恋战。
但是你必须在心里清楚，只有他能提供代码级别的东西，如类图、模块分区描述、数据流图、时序图、状态图等。
所以，你需要他整理一些文件和图表。您可以告诉领导您需要上述内容，让领导与他沟通，让他在离开前为您准备文件，并留出一些时间让您熟悉。
阅读代码，永不消亡
阅读别人的代码有什么样的体验？通过产品需求，业务流程以及与代码设计相关的文档和图表，接下来你就该死磕代码了：
while（不懂）
{
读
}
开发环境和调试
我接管了一个代码库，并最初调整了bug的外观。
有些产品需要更复杂的开发环境配置，请务必提前做好，让离开的同事指导您构建开发环境，这样就可以使用“调试”的强大武器快速理解代码。
调试是一种接管其他人代码的工具。如果您不了解业务在代码层面是怎么体现的，并且您不理解代码之间的调用关系，那么最好的方法是调试。
从对应于业务起点的代码开始调试，并逐步跟进以快速整理函数调用链。
建立可衡量的目标
当我认为这是最后一个bug时，改完就可以去吃饭时……
程序员的工作切换，特别是代码切换，如何成功完成？
这是一个谜！没有人说清楚。所以，你最好理清一些、可以达到的可测量目标。例如，读取A、B、C三个业务流程......
最好找一个bug或一个新功能，目的是读取代码、来修改代码，目的，目标，时间框，易于投资，易于阅读，易于掌握错误或新功能的逻辑和代码流。
输出、共享和重构
在新接手的代码库上 Debug
当你正在阅读代码时，如果能撇开给你交接工作的程序员提供的文档，根据你自己的理解，你可以绘制类图、数据流程图、时序图、关键业务流程对应的函数调用关系连锁等，你可以快速掌握别人的代码。
如果你仍然可以告诉别人你理解的东西，那么好吧，你真的理解别人交给你的代码。
更进一步，如果您了解现有代码，您可以确定哪些部分在逻辑上不清晰或需要改进。
然后你可以结合业务和你自己的理解来重构它，然后它真的接管别人的代码，别人的代码与你的代码没有什么不同，它们最终会成为你的代码。
最重要的是
如果你总是看见代码多就发愁，看见代码脏乱差就诅咒埋怨。看见代码逻辑复杂就头疼，搞不清调用关系就放弃，那你可能永远也变不成代码的主人，只能一次又一次被代码蹂躏。
因此，关于移交代码最重要的事情是：不要被庞大而奇怪的代码吓到，立即开始阅读，立即，马上，坚持十分钟，然后再坚持十分钟，你就能妙悟真谛。
最后，当你遇到这种事情时，请记住一句老话：那些不能将你击溃的代码，都将成为你成长的垫脚石。
如果你身边有朋友，正在接手别人代码，被虐的想要重构，让他看这篇，普度芸芸众码农，是我义不容辞的责任。