新入职一家公司，你是想接手一个新的业务还是交接一个老业务呢？我来说说我的思考！
新业务还是老业务？
前提
在一家BAT这样的大公司，从技术角度来想会有什么新业务吗？大概率是很难遇到的。新人刚入公司基本也是从老员工手里接手一些老的业务，旧的代码，这些代码有着这样那样的问题，技术栈陈旧，架构不灵活，无法满足新业务，历史遗留问题多，新需求还不断。该怎么办呢？
新业务好吗？
- 自己去独立负责一块没有的业务，从头开始，对于一个高级工程师来说，这样的业务往往比较小，或者并不受重视，从头做起是简单的，简单的由你来做，有什么挑战呢？
- 大公司普遍有着创新者的窘境，所以从技术角度来说并没有什么新业务或者新技术，比如从0搭建一个react全家桶难吗？想必并没有什么挑战。
- 去做新业务也许只是你的杏仁核在作怪，这是一种寻求确定感的自我意识驱动。改别人的代码往往并不能带来一种掌控力和确定感，缺失这种感觉往往会让你陷入自我焦虑，尤其是持续性的超负荷填坑，会让你产生生理抗拒。
- 从零开始的业务往往是不成熟的，需求不明确的，是摸着石头过河，很难有全局甚至宏观的把握。初始设计的架构很难说能保持多久。
- 新业务会出成绩吗？对于一个开发来说，业务做的好坏从来都是基本盘，那是产品经理的kpi，开发应该关注的是通过业务沉淀出的能力。新是很难做到深的，而深才是能力。
- 一个前景巨大的新业务，你的上级会把他交给你吗？其他老员工早就看到了，还能轮得到你？
老业务不好吗？
- 一个需求爆炸的老业务，说明他依然具有很大的增长性。
- 在大公司里一个需求旺盛的老业务，是被时间证明具有很高价值的。他牵扯的人也会更多，他们都是利益共同体，而这些人会让他变大，变茂盛。
- 技术栈陈旧，架构不合理，说明他是一个可以从架构和顶层思维解决的问题，而这种思维才是具有挑战性的。也是从一个工程师想让架构师转变的好场景。
- 历史遗留问题多，让参与其中的每个人都感受过他的痛处，如果你能解决，将获得更多的正反馈。
- 代码陈旧与不合理往往带来系统稳定的问题，而解决系统稳定性在大公司是非常关键的指标。
如何让老业务代码焕发新生机？
你可能首先想到的是重构。但重构是推翻了重来吗？
你应该重点关注以下几点
- 稳定性
- 开发效率提升
- 代码学习成本降低，便于扩大开发团队规模
- 工程化工具
- 顶层设计思维
该怎么做？
- 完整的理清系统现有的业务逻辑，画一张大图，清晰的说明白。预期未来一段时间的需求，添加其中。
- 发现并罗列其中的问题，尤其是对你的合作方带来的问题。
- 设计解决方案，向相关各方持续输出
迭代自己的方案。出一张新的架构图。 - 突出体现新方案带来的业务价值，比如稳定性提升，人效提升，销量提升，投诉率降低，体验提升等。
- 渐进式的重构代码，老需求不动新需求采用新架构，并逐渐替换老业务逻辑，千万不要一上来就重做，重在设计不在代码整理和重写。
- 沉淀技术能力。
具体操作
- 尽量快的梳理现有业务逻辑，边做新需求边熟悉。反复与产品经理以及后端同学同步和完善这张大图。
- 对于新需求的接入排期，给自己留足时间。对于一些改动较大的需求选择性说服合作方暂且搁置。
- 一点一点的输出新方案，向合作方表现出相当强的重构意愿，赢得他们的支持。得到支持的目的是让你获得足够的时间来重构代码。
- 提高自己思考的维度，回到需求的原点，了解真正的需求是什么，要解决什么问题，防止遇到老代码业务逻辑与需求脱离变形问题。
- 回到需求原点来设计业务架构。
- 软件设计是一个非常专业的知识领域，有很多总结好的套路和方法，需要花时间学习。
- 用引擎这个概念来思考和拆分业务，而不是传统的页面，组件。一个软件可以包含多个引擎，而每个引擎之间相对独立，通过数据做流转和连接。
- 数据，模型，逻辑分离。
- 清晰的编码规范和思路，让别人在你的框架约束下写代码，让代码整洁又可控。
- 能力沉淀，通过这次重构，有哪些技术能力沉淀下来，能批量解决什么样的一类问题。
核心关注点
能力型组织不拘泥于任何业务，他是一个批量解决问题的引擎。
- 业务提效
- 能力沉淀
总结
作为一个技术人员完成业务需求永远都是基本盘，能力的提升才是最重要的。而能力中最重要的是软件设计能力（架构和视野）和深入研究能力（技术深度和专业性）。
作为工程师，你需要把握三项能力。
- 宏观视野（扩大知识面，比如了解编程范式，设计模式，不同语言特性，行业前沿状态等）
- 中观套路（大公司能给你的思考方式方法，规章制度，文化，管理经验等）
- 微观体感（自己在实践中摸索的原则和感觉）