共计 2207 个字符，预计需要花费 6 分钟才能阅读完成。
在咱们的职业生涯中，很少有机会能够从零开发一个我的项目，大部分都是接手他人的代码持续开发，或者做些维护性开发。而且，对于大部分业务零碎来说，因为业务导向，需要倒逼，开发工期紧，团队往往都不是很器重代码品质，疾速上线是第一要务。所以，很多团队的代码品质个别都不怎么高。埋坑有数、没有文档、也没有正文，代码读不懂、也不敢改，这对于新人来说，会十分苦恼。明天，咱们就聊一聊，如何接手一坨烂业务代码，以及如在烂业务代码中的成长？
话不多说，让咱们正式开始明天的内容吧！
如何接手一坨烂业务代码？
在我过来 10 年的工作经验中，我接手过很多个代码品质比拟烂的我的项目。这些我的项目都有很多共性的特点，大部分都曾经保护了两三年，甚至五六年之久，代码量很大，有十几万行以上，并且大部分代码都没有任何正文，业务性能十分庞杂，也没有对应的业务文档。
除此之外，代码中还充斥着各种长期解决方案（Workaround）、硬编码（Hard Code）、遗留代码（Legacy Code），还有很多匪夷所思的设计。对于有些设计来说，咱们称之为“反人类”设计或者“成心挖坑”，一点都不为过。如果没有老员工给你解释上下文，你万万都想不到它为什么这么设计和实现。
实际上， 要想接手一个业务零碎，前提是要读懂代码，而读懂代码的要害，是要熟悉业务。 只有业务搞清楚了，代码只不过是对业务的翻译，对照着业务看代码实现，看懂并不是件难事。不过，我所接手的这几个我的项目，基本上都是零文档，所有的业务知识都是靠口口相传。所以，搞清楚业务，就成了接手我的项目最难的事件了。
面对如此宏大的我的项目代码，没有文档，简直就是两眼一抹黑。原来参加这个我的项目开发的老同事，有的到职，有的去做其余新我的项目，始终问他们也不好意思，所以，大部分状况下，我都只能硬着头皮，通过浏览代码反推业务性能。
如果代码品质比拟高，模块划分清晰，命名标准，那通过读代码反推业务，也并非不可能的事件。但实在的状况往往大失所望，就像咱们后面提到的，代码中充斥着长期解决方案、硬编码、遗留代码等各种坑，这就使反推业务变得十分艰难。对于代码中的这些坑，只管我不想始终麻烦共事，但也只有多问能力最疾速地解决。
在读代码的过程中，我非常重视常识的文档化，我会把读懂的每个业务都写到文档中。当然，这其中也包含后面提到的各种坑。对于简单的业务流程，我还会画一些流程图。读代码的过程十分苦楚，花了好几个月，我才有信念说，本人简直把所有代码都搞清楚了。同时，我也做了一件过来几年都没有人做的事件，那就是补充残缺了技术文档和业务文档，之后再有新共事退出，看了我的文档，就能够很快理解代码、理解业务，很快就能上手开发代码。
总结一下，即使代码再烂，只有有欠缺的业务文档，先了解业务，再去看代码，简直就没啥难度了。对于零文档的我的项目，大部分状况下，咱们只能通过代码来反推业务。当然，对于有些坑来说，必要的状况下，咱们也要询问前辈来搞定。在读代码的过程中，咱们要将失去的常识文档化，这也是对公司和团队来说最有价值的局部。
如何在烂业务代码中成长？
有人一遇到这种烂业务代码，就感觉很心烦，我反倒不一样。恰恰相反，相比接手好代码，我感觉接手烂代码，尽管过程更加苦楚，但同时也会给我更多施展才华的空间、锤炼技术的机会，我的成长也会更多。
除此之外，很多人感觉做偏底层的开发（基础架构、框架、中间件等开发）才锤炼技术，做业务零碎没有挑战，技术上没有成长，对此十分苦恼。实际上，我感觉这种认识是比拟全面的。做业务开发的难度不亚于底层开发，做好也不是件容易的事件，同样能够积攒技术、锤炼能力。
偏底层的开发更加考验程序员在某一细分畛域的技术深度，偏业务的开发更加考验程序员的能力，比方沟通能力、剖析问题解决问题能力、衡量取舍能力、架构能力等，毕竟业务多种多样，问题千奇百怪，繁多细分畛域的教训很难应答所有问题。
实际上，业务零碎的开发难度个别来自两个方面：高性能要求和业务简单。
解决性能问题，你须要具备肯定的架构能力，有肯定的技术广度，须要对各种基础架构、框架、中间件都有所理解。光理解还不够，还要有肯定的技术深度，最好能对原理甚至是源码有所钻研。除此之外，还要有肯定的应用教训。广度、深度、教训三者配合，这样能力做到恰到好处组合这些技术搭建架构，解决性能问题，并且在呈现问题之后能力疾速地解决。
应答大型项目的业务复杂性，要想让我的项目代码始终在你的掌控范畴内，你须要有很强的业务建模能力、简单逻辑的形象能力、代码翻译能力等。对于一个人的基本素质、根底能力的要求要更高。实际上，对于简单业务零碎来说，对业务的相熟也能成为你的竞争壁垒，成为升职加薪的砝码。我后面也讲到，低级别的降职靠技术，比方升阿里的 P7，高级别的降职靠业务，比方升阿里的 P8、P9，或者换个说法，高级别的降职，靠业务比单纯靠技术，更容易一些。
如果你参加的我的项目，性能要求高、业务也简单，那祝贺你，好好干就成了。如果你参加的我的项目，在性能和复杂度上，只兼具其中一点，那也不错，值得一做。如果你参加的我的项目，既没有性能压力、业务也不简单，那也别太焦急，走着瞧，切实不行再跳槽。
课堂探讨
在过往的我的项目经验中，你有没有像我一样，接手过代码品质比拟差的代码？你又是如何顺利接手的呢？
欢送留言和我分享你的想法。如果有播种，也欢送你把这篇文章分享给你的敌人。
文章起源：极客工夫《设计模式之美》