中小技术公司的人才培养(微服务使用--降本心法)

 为什么我写java技术博文的大逻辑和其他博主相反呢.

这种思维其实是java本身给我带来的一种思维方式(当然也有可能就是我本身思维习惯也有这样的趋势,只是接触java之后负负得负,给我放大了)

在java培训的过程中,java基础讲完之后,直接上手就是spring.这已经跨过了javaSE,utils,中间件.直接接触的就是框架.很快一个可运行的项目就可以通过IDEA创建出来.

这就是java面向对象的优势,技术细节想封装起来,小白直接通过框架就能搞出一个项目来,项目搞出来了,你去工作了,要写需求了,你自己就要想法去研究细节了...

(就像现在的我,发现自己太菜了,开始写博文积累....)

这篇文章是结构篇的最后一篇,浅浅解释了一下为啥我的思维来源.

上图的七篇文章就是分类专栏  "结构篇" 的所有内容了.

而接下来会开一个新的专栏,专栏里的文章就肯定是对以上7篇文章提到的所有知识节点单独的解析.当然过程会很慢的,因为好多节点我也还停留在能用的过程.

甚至有些还停留在听过的程度...你敢信...

所以关于中下公司的人才培养,我有一些独特的看法: 

框架定了,中间件定了,也就是整体技术难度定了,甚至于可以进一步连utils都定了(当然,这个是要一步一步慢慢定下来),但只要定了,高技术难度的地方就已经定了,所以,中小技术公司,除了需要一到两名技术骨干(这根据公司规模具体看).

如果您公司上述情况作了,会有两个结论: 

1,不再需要高难度面试题去筛选高技术人才(当然如果您公司不缺钱,当俺没说),因为那些高难度面试题您仔细一看,就是在筛选框架,中间件整体配合的问题.(公司那一到两个或n个技术骨干肯定需要仔细筛选的,面试题难度有多难上多难)

2,选择框架,选择中间件,甚至于选择utils,甚至于整体代码风格,只要是有意设计过的,本身就是技术存在,每一个新的程序员进来是需要服从于公司技术风格,而不是带来新的风格(除非是公司还没选好整体风格,或者是当下风格已经不足以满足需求了),不然的话就会发生一个软件体系致命的风险,就是代码系统越来越庞大,各种相同的业务用不同的中间件,不同的utils来实现(不同的框架还是不太可能发生,但不是绝对不发生,只要你不管,现实会很模范的)