入职一家大公司，应该选择新业务仍是老业务？

新入职一家公司，你是想接手一个新的业务仍是交接一个老业务呢？我来讲说个人思考！

新业务仍是老业务？

前提

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

新业务好吗？

• 本身去独立负责一块没有的业务，从头开始，对于一个高级工程师来讲，这样的业务每每比较小，或者并不受重视，从头作起是简单的，简单的由你来作，有什么挑战呢？
• 大公司广泛有着创新者的窘境，因此从技术角度来讲并无什么新业务或者新技术，好比从0搭建一个react全家桶难吗？想必并无什么挑战。
• 去作新业务也许只是你的杏仁核在做怪，这是一种寻求肯定感的自我意识驱动。改别人的代码每每并不能带来一种掌控力和肯定感，缺失这种感受每每会让你陷入自我焦虑，尤为是持续性的超负荷填坑，会让你产生生理抗拒。
• 从零开始的业务每每是不成熟的，需求不明确的，是摸着石头过河，很难有全局甚至宏观的把握。初始设计的架构很难说能保持多久。
• 新业务会出成绩吗？对于一个开发来讲，业务作的好坏历来都是基本盘，那是产品经理的kpi，开发应该关注的是经过业务沉淀出的能力。新是很难作到深的，而深才是能力。
• 一个前景巨大的新业务，你的上级会把他交给你吗？其余老员工早就看到了，还能轮获得你？

老业务很差吗？

• 一个需求爆炸的老业务，说明他依然具备很大的增加性。
• 在大公司里一个需求旺盛的老业务，是被时间证实具备很高价值的。他牵扯的人也会更多，他们都是利益共同体，而这些人会让他变大，变茂盛。
• 技术栈陈旧，架构不合理，说明他是一个能够从架构和顶层思惟解决的问题，而这种思惟才是具备挑战性的。也是从一个工程师想让架构师转变的好场景。
• 历史遗留问题多，让参与其中的每一个人都感觉过他的痛处，若是你能解决，将得到更多的正反馈。
• 代码陈旧与不合理每每带来系统稳定的问题，而解决系统稳定性在大公司是很是关键的指标。

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

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

你应该重点关注如下几点

• 稳定性
• 开发效率提高
• 代码学习成本下降，便于扩大开发团队规模
• 工程化工具
• 顶层设计思惟

该怎么作？

• 完整的理清系统现有的业务逻辑，画一张大图，清晰的说明白。预期将来一段时间的需求，添加其中。
• 发现并罗列其中的问题，尤为是对你的合做方带来的问题。
• 设计解决方案，向相关各方持续输出

迭代本身的方案。出一张新的架构图。

• 突出体现新方案带来的业务价值，好比稳定性提高，人效提高，销量提高，投诉率下降，体验提高等。
• 渐进式的重构代码，老需求不动新需求采用新架构，并逐渐替换老业务逻辑，千万不要一上来就重作，重在设计不在代码整理和重写。
• 沉淀技术能力。

具体操做

• 尽可能快的梳理现有业务逻辑，边作新需求边熟悉。反复与产品经理以及后端同窗同步和完善这张大图。
• 对于新需求的接入排期，给本身留足时间。对于一些改动较大的需求选择性说服合做方暂且搁置。
• 一点一点的输出新方案，向合做方表现出至关强的重构意愿，赢得他们的支持。获得支持的目的是让你得到足够的时间来重构代码。
• 提升本身思考的维度，回到需求的原点，了解真正的需求是什么，要解决什么问题，防止遇到老代码业务逻辑与需求脱离变形问题。
• 回到需求原点来设计业务架构。
• 软件设计是一个很是专业的知识领域，有不少总结好的套路和方法，须要花时间学习。
• 用引擎这个概念来思考和拆分业务，而不是传统的页面，组件。一个软件能够包含多个引擎，而每一个引擎之间相对独立，经过数据作流转和链接。
• 数据，模型，逻辑分离。
• 清晰的编码规范和思路，让别人在你的框架约束下写代码，让代码整洁又可控。
• 能力沉淀，经过此次重构，有哪些技术能力沉淀下来，能批量解决什么样的一类问题。

核心关注点

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

• 业务提效
• 能力沉淀

总结

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

---

做为工程师，你须要把握三项能力。

• 宏观视野（扩大知识面，好比了解编程范式，设计模式，不一样语言特性，行业前沿状态等）
• 中观套路（大公司能给你的思考方式方法，规章制度，文化，管理经验等）
• 微观体感（本身在实践中摸索的原则和感受）

---

欢迎访问个人blog: http://yondu.vip