（转载）入职一家公司，应该选择新业务还是老业务？

 通过阅读本篇文章，对于自己的工作有了更深刻的了解，当你觉得在一家公司发展到瓶颈的时候，你是否有考虑到是不是有很多的地方，其实是我们没有深入去挖掘的。

同时本篇文章给出的思路，在你作为架构师或者团队小Leader去一家新公司的时候，问非常的有用。

1、历史的代码随着人员的更替，业务的不断迭代，肯定有很多的问题，单纯的抱怨并不解决问题，我们要做的是在尽量不影响业务需求的同时，对架构和代码进行优化。这是我们的价值所在。

2、对于历史的代码，不能直接推翻重构，对于人力和时间的消耗是很大的，会影响到业务的发展。需要和我们的合作方进行沟通，摆明说好重构的一些好处，在需求中不断加入。就像一个大需求，我们也会拆分成小需求进行不断迭代。

3、进入一家新公司以后，千万不要说原来的架构很烂，原来的人水平不行。要给予肯定，兄弟们好牛X，原来这么点人就支撑了这么大的业务量，有助于于你快速的融入团队。然后我们对整体的架构和业务进行梳理，整体出需要改进的点和优先级，和团队一起过方案，主动推进和解决。

4、对于一个架构师而言，认知是非常重要的，技术认知和业务认知，以及这三项能力宏观视野，中观套路，微观体感。

前   提 

在一家BAT这样的大公司，从技术角度来想会有什么新业务吗？大概率是很难遇到的。新人刚入公司基本也是从老员工手里接手一些老的业务，旧的代码，这些代码有着这样那样的问题，技术栈陈旧，架构不灵活，无法满足新业务，历史遗留问题多，新需求还不断。该怎么办呢？

 新业务好吗 

• 自己去独立负责一块没有的业务，从头开始，对于一个高级工程师来说，这样的业务往往比较小，或者并不受重视，从头做起是简单的，简单的由你来做，有什么挑战呢？

• 大公司普遍有着创新者的窘境，所以从技术角度来说并没有什么新业务或者新技术，比如从0搭建一个react全家桶难吗？想必并没有什么挑战。

• 去做新业务也许只是你的杏仁核在作怪，这是一种寻求确定感的自我意识驱动。改别人的代码往往并不能带来一种掌控力和确定感，缺失这种感觉往往会让你陷入自我焦虑，尤其是持续性的超负荷填坑，会让你产生生理抗拒。

• 从零开始的业务往往是不成熟的，需求不明确的，是摸着石头过河，很难有全局甚至宏观的把握。初始设计的架构很难说能保持多久。

• 新业务会出成绩吗？对于一个开发来说，业务做的好坏从来都是基本盘，那是产品经理的kpi，开发应该关注的是通过业务沉淀出的能力。新是很难做到深的，而深才是能力。

• 一个前景巨大的新业务，你的上级会把他交给你吗？其他老员工早就看到了，还能轮得到你？

 老业务不好吗 

• 一个需求爆炸的老业务，说明他依然具有很大的增长性。

• 在大公司里一个需求旺盛的老业务，是被时间证明具有很高价值的。他牵扯的人也会更多，他们都是利益共同体，而这些人会让他变大，变茂盛。

• 技术栈陈旧，架构不合理，说明他是一个可以从架构和顶层思维解决的问题，而这种思维才是具有挑战性的。也是从一个工程师想让架构师转变的好场景。

• 历史遗留问题多，让参与其中的每个人都感受过他的痛处，如果你能解决，将获得更多的正反馈。

• 代码陈旧与不合理往往带来系统稳定的问题，而解决系统稳定性在大公司是非常关键的指标。

 如何让老业务代码焕发新生机 

你可能首先想到的是重构。但重构是推翻了重来吗？

你应该重点关注以下几点：

• 稳定性

• 开发效率提升

• 代码学习成本降低，便于扩大开发团队规模

• 工程化工具

• 顶层设计思维

该怎么做？

• 完整的理清系统现有的业务逻辑，画一张大图，清晰的说明白。预期未来一段时间的需求，添加其中。

• 发现并罗列其中的问题，尤其是对你的合作方带来的问题。

• 设计解决方案，向相关各方持续输出 迭代自己的方案。出一张新的架构图。

• 突出体现新方案带来的业务价值，比如稳定性提升，人效提升，销量提升，投诉率降低，体验提升等。

• 渐进式的重构代码，老需求不动新需求采用新架构，并逐渐替换老业务逻辑，千万不要一上来就重做，重在设计不在代码整理和重写。

• 沉淀技术能力。

具体操作：

• 尽量快的梳理现有业务逻辑，边做新需求边熟悉。反复与产品经理以及后端同学同步和完善这张大图。

• 对于新需求的接入排期，给自己留足时间。对于一些改动较大的需求选择性说服合作方暂且搁置。

• 一点一点的输出新方案，向合作方表现出相当强的重构意愿，赢得他们的支持。得到支持的目的是让你获得足够的时间来重构代码。

• 提高自己思考的维度，回到需求的原点，了解真正的需求是什么，要解决什么问题，防止遇到老代码业务逻辑与需求脱离变形问题。

• 回到需求原点来设计业务架构。

• 软件设计是一个非常专业的知识领域，多有很总结好的套路和方法，需要花时间学习。

• 用引擎这个概念来思考和拆分业务，而不是传统的页面，组件。一个软件可以包含多个引擎，而每个引擎之间相对独立，通过数据做流转和连接。

• 数据，模型，逻辑分离。

• 清晰的编码规范和思路，让别人在你的框架约束下写代码，让代码整洁又可控。

• 能力沉淀，通过这次重构，有哪些技术能力沉淀下来，能批量解决什么样的一类问题。

 核心关注点 

能力型组织不拘泥于任何业务，他是一个批量解决问题的引擎。

• 业务提效

• 能力沉淀

 总   结 

作为一个技术人员完成业务需求永远都是基本盘，能力的提升才是最重要的。而能力中最重要的是软件设计能力（架构和视野）和深入研究能力（技术深度和专业性）。

作为工程师，你需要把握三项能力：

• 宏观视野（扩大知识面，比如了解编程范式，设计模式，不同语言特性，行业前沿状态等）

• 中观套路（大公司能给你的思考方式方法，规章制度，文化，管理经验等）

• 微观体感（自己在实践中摸索的原则和感觉）