进阶|编程进阶之路,虽无捷径但有长短( 二 )


【注意】如果把技术当成解决业务的工具 , 即使对技术深度的追求不多 , 也要对技术的使用做到细致与熟练 , 对于专业范畴内的能力是不能打折的 , 遇见过少数的技术面试这样解释自己的综合能力:因为追求于项目管理或者业务解决能力 , 所以欠缺技术细节方面的沉淀 。 这种思路当真是清奇 。
二、技术栈整理上面聊编程中关于选择的热点话题 , 这里来说具体的技术积累 , 作为一名Java编程选手 , 下面主要围绕相关主流的技术栈与进阶过程做梳理 , 大致分为基础、进阶、高级三个阶段 , 受到工作经历与经验的影响 , 所以在划分的时候存在诸多主观因素 。
1、基础篇
在衡量一个开发人员的能力时 , 通常会提到一句话:技术深度与业务高度 , 这里说的技术深度 , 至少有6-7成的因素是指基础能力的深度 。 经常阅读框架的实现源码会发现 , 都是对于JDK源码、设计模式、结构算法的排列组合 , 从而形成解决某类场景业务的组件 。

【建议】在有大量模块化空闲时间的阶段 , 把主要精力持续放在以上基础模块 , 是收益最大的选择 , 这里更多指大学阶段 。 编程中越是基础原理就越复杂 , 这是普遍认可的共识 , 所以这个模块在学习的时候对于时间成本要求较高 , 一旦进入工作阶段 , 很难在抽出整体的时间细致的回顾基础模块 。
假设Java的集合容器模块 , 用1-2周的时间 , 从API使用到源码逻辑 , 分析内在的扩容机制 , 涉及的算法与数据结构 , 进而再上升到设计模式的实践 , 流程这样走下来对于基础的理解就具备一定的深度了 , 也自然达到触类旁通的效果 , 那么对于IO流与并发也就是相同的原理 。
2、进阶篇
这里罗列的是当前技术选型中常用的框架与组件 , 当进入工作阶段之后 , 会接触到各种不同的开发组件 , 学会熟练使用不同的组件去解决不同类型的需求是不可缺少的能力 , 这时候对于框架原理的理解 , 完全依赖于基础能力的积累程度 。

【说明】一下 , 最近几年随着对互联网数据的重视 , 很多公司都在做数据的采集沉淀与分析 , 同时大数据领域的开源组件推出 , 已经弱化了Java工程师与大数据工程师的边界 , 所以对于大数据技术栈的了解 , 对于管理海量的业务数据是至关重要的 , 熟悉3-2个数据存储查询的组件 , 会提供更开阔的技术选型思路 。
3、高级篇
当能力到达这个阶段 , 基本上就是架构师级别的水准了 , 同样的道理这个阶段依赖于基础和进阶能力的沉淀 , 鉴于作者本人没有历经过架构师的职位 , 所以无法给到主观的建议 , 只是对于团队中架构师的职责做的分析 , 主要在于提供技术栈的选型和复杂业务的解决方案 , 流程自动化是分布式系统的必要支撑 。

【注意】这里只是单纯的技术进阶的角度 , 关于衡量开发人员的另外一个核心因素:业务高度 。 站在客观的角度去看的话技术与业务能力需要一比一提升 , 业务管理也是走出开发角色的基本要求 。
三、业务管理从入职场开始 , 因为没有待过纯技术型的公司 , 所以都是在围绕业务场景做编程开发 , 感觉技术能力有较大提升的阶段 , 都是在解决复杂业务之后的反思 。 业务的底层逻辑是流程管理与模型建立 , 如何认知复杂的业务并进行抽象设计是技术水平的直接体现 。
【然而】在公司的日常面试工作中 , 时常会遇到少量求职者表达自己单方面的诉求:一种是希望公司可以提供技术发展路线 , 而不是常年累月的业务版本;另一种则希望公司能提供业务发展路线 , 入职之后可以慢慢脱离技术方向 。 如果站在招聘需求的角度去考虑 , 建议在求职面试时不要表达这种个人发展路线的追求 , 因为多数公司的招聘目的都是:需要技术人员来实现业务需求 。
【误区】职场上的新人选手 , 很容易产生这样一种心里:每天都是理不清的业务需求 , 改不完的坑坑洼洼 , 然而换个公司和环境之后 , 会发现依旧是这种工作节奏 。 所以在新手阶段就用乐观的心态去面对各种业务模式 , 并且持续学习和总结各种业务解决方案 , 这是开发同学技术转型的核心竞争力 。

【通常】来说 , 业务是关联公司各个角色的连接点 , 对于业务解决方案都会以各种文档的形式记录并沉淀下来 , 这也是团队常用的一种管理手段 , 也方便以后在类似的业务中提供借鉴参考 , 不断提升业务落地的能力和效率 。 实际上大部分开发选手都会选择技术与业务同时积累的方式 , 尽量放大自己职场的可能性 。


推荐阅读