今天在公司里面,听到很多的吐槽,最近以前的团队有很多开发工程师离职,结合自己在公司多年的工作经验,也发现这个问题越来越严重,这里也吐槽一下。
在一般传统的小的IT公司,准确说的是小的技术团队,由于涉及到的业务比较少,人员相对也比较小,一半小于10个人,一般情况下,这种10个人的团队里面一般会有一个技术方面的team leader,大多数情况下,这个leader一般也就是技术开发的高手,应该算是小团队技术最好的,会从事一线的编码工作,这样的leader和其他成员相比,级别会高一些,一半情况下,团队的所有技术决策,都由他来决定,基础框架也或者核心部分编码都会由他来负责,所以相对来说,是比较合理的,因为他技术好,开发能力强。这里面一般就两个层级。由于团队小,技术leader对下面技术人员的基本上都会有了解,而且基本上考核的维度都比较简单如编码能力,编码质量等等。而且这个时候业务和系统架构都不是非常复杂,对业务架构和技术架构的要求都不会非常高。
随着公司业务的发展,公司的业务越来越多,开发人员也越来越多,基础技术平台和业务开发平台 一般都会分离。技术人员的层次也越来越多,一般的大公司对技术人员的都有评级标准,不能的标准做的事情不一样。像腾讯公司会有T1,T2,T3,T4,阿里会有P1——P14 等序列。这个等级是一个倒金字塔的形状,越往上越少,下面一幅图详细演示了一个技术人员典型的概况。
可以看出,架构师是干活的和忽悠的标准(这里的忽悠没有贬义,只是说架构师的工作主要是做业务规划和技术规划,这一块的推广需要好的表达能力)。
当一个开发人员从底层开发做起,然后做一个系统的负责人,到一个业务域的负责人,到平台的负责人,就是不短晋升的结果。当业务域的负责人的时候,主要的工作职责就是做规划,因为他已经对系统的业务非常了解,知道业务的发展。慢慢他已经不在写代码,大多数的工作基本上都是评估风险,review代码,规划系统的技术架构或者业务架构,而具体实现则由开发工程师来进行负责。
我们主要来看看在这种情况下,底层工程师的状态。
首先工程师是真正的coder,他会把上一级别已经规划好的东东做一个真正的实现。他没有决策权。他只能在上级工程师设计好的框架去实现功能,基本上没有自主权。工程师想用新的技术(就是超出目前基础框架的技术,比如脚本语言等等),这个必须由上一级进行审核或者批准,不能私自使用。如果自己的项目的工程结构不符合标准的结构,也是不可以的,必须按照标准的来。甚至使用了第三方jar包都需要进行评估。
工程师是业务的实现具体的实现者,很了解业务的细节。但是在业务规划上基本上是没有发言权的,因为你的级别不够,架构层面的级别会议你是根本参加不了的,更别说去规划自己所在的业务。有时候架构反而不如开发对业务了解,但是有一些流程上对业务的改动必须由架构来评估,可惜有时候架构并不了解细节,根本评估不了风险点,导致架构有问开发,相当于开发在评估,由架构出具报告。
在对外推动和配合上,虽然底层开发有时候有一些观点比较正确,毕竟在一线开发,对于系统和业务上了解还是比较深入的。但是你的级别比较低,你说话没有分量,涉及到跨团队配合的时候,对与错已经不重要,重要的是谁的级别高,谁说话有分量,有分量就够了,至于对于错,执行之后在看看结果。
在工作环境上,底层开发感觉是最恶劣的,有无数流程在卡开发,比如代码规范报告,review报告,代码质量报告,缺陷分析报告,sql规范报告,发布计划(一个发布计划里面将近有100想 check list)等等,上面列举的还只是一小部分。很多开发,做事情都必须求着配合方干事,比如求dba,求sa,求架构,求asa,求pd 等。而且一旦除了线上故障,开发首先需要背责任,由于老板也会有等级观念,级别低的我可以说说,级别高的,我不能说,所以往往底层开发又是最受气的一个群体,架构们弄错了,最后估计不了了之,毕竟可以说这个本来就是探索性的,但是开发产生bug了,就是实实在在的问题,能导致线上实际的影响,自然要被说。
在团队文化上,由于开发的前途由一些已经不再编码的人来决定,那么这个是很难做到公正客观的。你的编码能力强,代码写的好对于上级来说,他根本都不知道。所以导致一种表现文化。简单的说,就是做表面功夫以取得上级的认可,而不是切实提高自己的技术能力。很多人开口闭口谈架构,谈设计,而这些人的代码质量可能非常差,编码能力非常差,因为架构和设计是不需要编码的,而这些就是上级做的工作,这样上级就认为你非常牛逼,导致整个团队整体编码质量下降。我一同事就是这样,嘴皮子功夫相当那个厉害,可惜给一个项目让他做,就是做不好,而另外一个同事技术能力不错,是一个做实事的人,给他做的项目比较放心,但结果前一个人能晋升。
最近看了 左耳朵耗子 写的工程师文化,很有感触,可惜公司的业务不一样,导致开发模式不一样。比较羡慕啊。抄送一张图片送给那些底层的码农和编码爱好者们。