©2020-2024 ioDraw All rights reserved,
Privacy Policy
一、等级划分
1.初级水平（认知理解技术为主）
业务部分
1.正确的理解产品经理的需求和设计，并对相应的细节提出一定的质疑，有效的完成业务开发。
2.根据产品原型自己独立进行设计，包括项目流程设计，数据库设计，接口设计等。
3.能够定位线上问题，并提供合理的解决方案。
技术部分
1.Java基础扎实，并对其中的高级部分有一定了解如锁，反射等，能够熟练使用三大框架或者springboot进行基本的业务开发，熟悉MVC架构
2.sql能够熟练掌握，如子查询，mybatis的复杂查询。
3.熟悉常用的设计模式
2.中级水平
简介
1.利用技术解决复杂的业务场景并对技术的原理有较深的理解
2.独立负责项目的业务流程和存储设计
业务部分
1.能独立的完成项目整个流程设计开发，对项目中的难点能提出有效的解决方案，
并指导初级工程师进行开发和解决提出的难点。并对常用的设计方案利弊都有自己的见解。
2.能分析出产品需求的合理性，以及对产品或者测试提的解决思路能够分析利弊并采用最佳方案
3.较好的跨部门沟通能力，能够解决部门与部门之间的协助问题。
技术部分
1.对常用框架的原理有较清晰的理解，对缓存，并发，MQ，分布式等复杂技术有着深入理解
能够掌握其设计思想和所用到的设计模式。
2.能够进行性能优化，代码规范，代码中含有相应的设计模式，无不规范的代码
3.高级水平
简介
1.技术领导
技术和管理
1.能对需求进行架构设计，对产品需求的可实现性和规模难度进行评估，对技术进行选型以适应最合适的场景。
作为某个项目的领导，带领团队完成项目，并对项目产生的问题承担第一负责人，并且能提前预知可能出现的问题，并提出解决方案。
2.有自己的开源项目，可以写出自己的组件，对开源的框架能够进行二次编写，java核心技术有着非常深入的理解
3.指导和评审初级工程师的技术方案，存储设计，代码评审等
4.排查线上各种问题，并给出和决定实现方案
能力评估
1.专业能力
1.需求评审能力
不是理解产品经理的能力，而是理解产品和业务本质的能力
2.技术设计能力
3.代码能力
4.运维，优化，重构能力
2.通用能力
1.信息检索能力
2.问题沟通能力
4.架构师（部门领导）
1.能管理开发，测试，产品等核心人员，制定团队目标，为部门和公司产生盈利。
2.对开发及相关人员引导制定okr,使下属有技术提升。
3.建设团队文化，使团队内部互帮互助，外部和谐共处,并解决必要的内部和外部矛盾，引领团队健康有序发展。 其发展战略可以参考下图：
二、技术向管理转型
相关条件
1.技术能达到中型互联网公司高级和初级架构师水平，且通过个人努力长期技术也很难有所突破，认同团队管理的价值。
2.身体上受不了高压工作强度，希望通过语言交流和管理来解决实际问题。但作为技术经理，所承担的压力并不比开发者小。
3.对底层纯技术并没有非常痴迷的热爱，普遍会出现长期专研底层感到非常梏燥乏味。且基本功和学历并不十分出众。
4.没有在技术性公司或者业务型公司中担任中间件团队或者基础架构团队，且已无法填补里面的经验。此时建议向业务架构师和技术经理角色转变。
5.高并发，高可用，海量用户等高级业务可遇不可求，并不是大部分公司所具备的。那么作为程序员，他的终极目标是在哪里？那种百里挑一的机遇并不可求。应过度到技术经理去适配合适的角色。
个人的独有特点
1.对演讲感兴趣，喜欢历史与人文感情。
2.能和人进行基本的沟通交流。不说多么热爱与人打交道，但至少内心底层是有渴望与人交流的需求
转型准备
1.有意识的训练自己的沟通能力与为人处世能力。
2.有意识的训练自己的领导能力和与领导相处的能力。
3.持续保持对技术的热爱，但切莫过于钻牛角尖越陷越深。
三、实战感悟
1.Java本身其实是一种编程语言，你也可以把它当成一门数学学科。其核心是逻辑推理。如果在产品设计时，如果用中文都无法把逻辑整理清楚，编程时思路肯定也是不清晰的。
2.写代码前最好把思路先用一个文本写下来，这样思路就清晰了，写出的代码维护起来也容易。就相当于你做数学题时要先打草稿一样，代码写上去了改动肯定比你在草稿上改动的成本大多了。
同样要学会使用画图等方式清晰的表达自己的设计，而不是思路不清晰就开始写代码
3.重难点先入，人的精力前期是充沛的，到了项目后期时间短，用后期短时间做较为复杂的业务，出bug的概率是很大的。而且对应编程来说，简单的业务实质是不需要的编程的，对应开发者来说，它就是一个体力活而已。
4.产品需求在评审前好好梳理，这样评审时可以早一点发现问题，否则开发过程中发现问题解决的成本会越堆越大，越到后面越不好解决。当然如果能遇上逻辑思维强的产品协作中将会大大减少成本，但好的产品可遇不可求啊！
5.对于远程调用一定要打日志，因为你不知道别人是怎么玩的，而且出问题的概率是不可控的。所以一定要对异常进行捕获，并打印入参和回参。
6.接口设计好后一定要让客户端，即前后端联调时先检查，因为设计好后客户端肯定会检查的，早一点发现，早一点调整，否则到了后面，调整的难度会越堆越大。
7.对于互联网公司，性能要求非常非常高，所以对于数据库的操作越简单越好，因为优化一个复杂查询的成本还是很高的，甚至尽可能不要做内存计算相关的操作，慢SQL是很容易被检测出来的
8.对应if else，如果条件在两个以内，可以使用。如果三个以上建议使用状态设计模式，即最原始的switch case
9.好代码的一些思考：
1.结构清晰，是基于模型的设计，能清晰的联想到对应的流程图。 2.bug很少，且排查容易。
3.接口逻辑尽量不要太多，如果接口逻辑复杂，可以考虑拆分接口，即保证接口的原子型 4.利用到相关的设计模式 5.面向对象的编程思维，懂得类的单一职责，懂得拆分类
10.熟悉业务方法总结
1.页面流程 1）整体部分：熟悉业务的整体流程，模块拆分 2）枝节部分：重点熟悉业务的关键流程，如上下游流程，数据写入流程 2.表梳理
1）熟悉业务的核心模型 2）表与表之间的关联关系梳理，明白哪些是主表哪些是关联表 3.接口梳理 A:入参和反参模型梳理 B:代码结构梳理 C:设计模式总结
D：核心接口流程图 4.排查问题时总结流程
11.不要相信“任何人”，不要相信测试，她不一定能测出bug，到了线上环境，最后排查问题的还是开发自己，且还有可能会背锅。不要相信兄弟部门，谁知道他对接口会做哪些处理，按照的你要求去审核他的入参和反参吧，一定要对他的异常进行捕获。
12.程序员在设计时全局把控能力的思考
1.角度的转换，占在产品全局的角度，而不是某个需求的角度。即由被动形转为主动形，比如想一想如果是你来设计架构你会如何设计。
2.判断此产品的未来价值，考虑代码的可扩展性
13.代码自测bug多解决方案思考
1.写完整：
A:定义一个dubbo接口，就一定要把入参和反参对象进行序列化，provider和reference配置一定要进行配置，只要一套流程就要一次性写完在写其他部分，而不是东写一句西写一句，容易遗漏和出错
14.复杂接口和简单接口思考
1.复杂接口实质就是多个简单接口冗余到了一起。其本质还是是否遵循的类的单一职责，是否存在的一个类干了其他类要做的事情。
2.对于存储在不同的表或者微服务下的数据如果要做分页查询，如何做？针对这种场景就应该思考哪一个是主表或者主服务，方案一以主表作为分页查询，副表作为筛选条件进行分页查询。方案二内存分页。
四、技术储备
1.core java：
a:编程特点：封装，继承，多态。
b:并发：aqs,cas,锁
c:网络基础：socket
d:集合数据结构原理
e:jvm性能调优
2.spring
2.1.基础：
IOC，DI，AOP原理深入理解
2.2.spring-ORM
1)spring与mybatis的整合
2)spring与redis的结合：spring-data-redis
2.3.spring-context
1）spring的事务管理，日志管理。
2.4.spring-webService
1）spring MVC原理深入理解，架构图待续
2）rop
2.5.springBoot
可以简化spring的xml配置，通过注解的形式进行bean的注入和管理.
如何集成tomcat，创建starter
2.6.分布式服务
1）springCloud
2）dubbo
3.建模
3.1UML建模工具
3.ORM框架
3.1.mybatis
推荐学习途径：书籍《mybatis技术内幕》徐郡明
存储
1.数据库
关系数据库
1）mysql
2）oracle
非关系型数据库（nosql）
1）redis
2）monodb
其他核心中间件
1）elastic search
2）click hourse
6.版本控制工具
1）maven
2）git
3）svn
7.格式解析
xml解析的几种方法
1）dom4j
2)sax
3)dom
json解析
8.前端
如今企业大多已采用前后端分离的架构，故前端知识了解即可如html，js,css。
9.反向代理
nginx
Java难点分析
1.jvm调优
2.分布式治理
3.db调优
五、面试感悟
1.面试官主要考察的是你对核心技术原理的理解程度和理解能力，以达到如果项目上出现了对应的问题，你是否能利用你所掌握的技能解决对应的问题。
2.对于中间件，你的大部分精力应该是掌握它的设计思想和核心原理，而不是代码本身，如果你掌握它的设计思想，相信你也能写出一套轻量级的类似中间件。
3.对于中间件的源码，你核心要想的是为何它要这么写？它使用哪些设计模式和设计思想？对你后续写代码有何参考和学习
4.二面专题
1.到了二面，一般为部门leader或者架构师，此时他的核心更多的是你的上限，如架构能力，底层深入的程度
5.如果你想展示你的技术能力，最好要有与之匹配的项目，这样将更让人信服。所以多多珍惜遇到项目中的难点问题，和大胆的尝试去做有挑战力的项目吧。
6.面试造火箭，工作修拧螺丝。对应初中级的开发来说，确实是这样，但对于高级和架构角色的开发来说，出了问题最终还是的由他们解决。
如果不懂底层原理和抽象发散，出了问题如何办，如果你不懂其底层原理，你敢用这门技术吗？
六、学习思考
1.中间件的思考
1.任何中间件应该是先有架构图才会有源码，而不是先写代码然后画架构图。 所以无论是写中间件还是读中间件源码，流程顺序不要搞反了
2.新技术使用探索流程：
1.粗列的看一看有哪些功能 2.查看博客和官方使用文档，如果没有，就去找，就去问。 3.根据文档，进行本地演示
3.学习源码的思考
1.如果读了源码你没有收获到它的设计流程和设计思想，那么你就白读了，所以还是弄懂原理之后再去看源码吧
八、新公司适应感悟
1.心态调整
作为新员工，一定要记得多问多做少抱怨，的确新公司有很多毛病，但是和老员工起争执的代价是昂贵的。
2.新公司流程感悟
对于新员工，如果没有分配导师，那对新员工也许是致命的，他会感觉很无助。这种更多的是公司的责任，而且大多数正规的公司都会分配导师进行引导。当然导师的人品也是非常重要的，遇到人品不好的导师，那就需要新员工具备较强的情商水平了。
3.新公司走业务流程感悟
1.找到熟悉该业务的人，他将是你咨询得最多的人，多问少埋怨，既然上了船，除非触及底线，埋怨只会两败俱伤
2.如果该交接人比较忙，又不好意思问领导，可以咨询最亲密的同事（此时培养至交就相当重要了）
3.能要到文档最好，这样可以减少大量的沟通成本
4.将问题整理好，集中式的问，而不是来一个问一个，人家研发也很忙。
总结：沟通能力和与人相处能力将至关重要