研发的英文是R&D,即研究(Research)与开发(Development)。软件研发这个词包含了两个意思,第一是架构设计,即决定一个系统采用什么样的架构,怎么做,通常这是系统分析师或者架构师的责任,系统分析师是比较传统的叫法,现代互联网公司往往喜欢用架构师来替代;第二是代码实施,也就是通过编写代码把系统实施出来,一般这是 程序员 的工作。
现在我国互联网行业的软件研发人员的职业生涯往往从写代码开始,然后逐步积累经验向系统设计的方向发展,例如模块设计,系统设计等,等到积累了足够的经验并在思维能力提升之后,程序员可能逐渐成长为专门从事系统设计的架构师。所以程序员与架构师之间有一段很长的路,而且这是一条渐进的灰色地带,有时候两者之间在职位分工方面很难区别。不知道从哪朝哪代开始,行业里用软件研发人员笼统地涵盖相关的职位。
实际上,不同的企业在职位设计上有不同的做法,中国的互联网企业多数参考硅谷的做法,就是以软件研发工程师覆盖写代码的程序员,负责系统设计的系统分析师,以及专门负责架构设计的架构师等不同职位。
R(研究)/架构师
D(开发)/程序员
春节前在一个互联网CTO的微信群里,大家聊起了对程序员落实系统架构设计的担忧。有的时候架构设计得很优秀,但是真正落地的系统一塌糊涂,也有的时候没有架构设计,程序员自发完成设计和编程。 近期观察到一个支付公司的研发团队,尽管研发工程师们非常努力,但是该团队所负责的应用系统,在架构设计和代码实施上却是 坑坑洼洼乏善可 陈。
架构设计是这样的
代码实施是这样的
流量不大时是这样的
洪水来了是这样的
这些现象让我回想起了自己在新加坡、日本、美国和中国的四段职业生涯。反思这四段职业经历,对比目前所面临的困局,我感觉有必要对比分析四个国家的互联网公司在软件研发职位方面的设计,希望能从中提炼出有价值的经验,或许对互联网企业的CTO有一定的启发意义。
新加坡曾经是英国的殖民地,不论是法律体系、政治制度还是职场文化都继承了不少英国的传统,其主要特点是阶层和分工明确。公司研发团队的系统分析师和程序员之间的分工非常明确,系统分析师主要负责系统设计,程序员根据系统分析员的设计来实现代码。90年代公司对这些程序员的要求并不高,可以是高中毕业生,学习财务专业的大专毕业生,而现在更多的是计算机软件专业的毕业生。系统分析师一般是经过训练有经验的计算机专业的工程师。有些人能够从程序员逐步提升到系统分析师,有些人则在程序员的岗位上长期工作。
日本公司对职位的区分更加清楚,系统分析师经常用Excel定义好系统要实现的具体功能,然后由程序员严格按照Excel的描述把定义好的功能逐一实现。日本企业有两个特点,第一是员工的忠诚度比较高,他们往往会在同一个企业里工作一辈子,所谓终身雇佣制。
而互联网技术的发展很快,员工跳槽去不同的企业可以学习到很多新的知识,积累更多的经验。忠诚于企业这个优良传统在互联网时代可能具有负面效果。第二是新老员工之间的隔阂,员工越老在企业里越有地位,发言权越大,新员工必须无条件地尊重和服从老员工,简而言之就是有论资排辈的现象。但是互联网是个快速变化的行业,新知识新技术往往更加重要。比如老员工只会用 C语言 写代码,对 Java 和 Go 语言等不清楚,他们往往凭经验选择自己熟悉的C语言,这对企业的技术发展是个障碍。
美国硅谷的情况则非常不一样,因为大多数的硅谷互联网公司都是从创业公司发展而来的,这些创业公司的研发人员从公司成立开始就什么都做,产品设计、代码实现、应用测试,缺什么就做什么。 我曾经在同一个时间担任Oracle DBA、系统管理员和Java 程序员。所以硅谷公司对研发人员的职位分得没有那么清楚,笼统地称为软件工程师。
这种安排与美国的文化有极大的关系,美国是一个比较开放、包容和平等的社会,只要能完成企业的创新,年纪大小、学历高低、皮肤黑白都不是问题。经常会在企业里看到掌握新技术的年轻人挑大梁,也常见到50岁,甚至60岁的程序员大叔在编写代码。
中国的互连网公司与美国硅谷的情况比较接近,就是企业大多数都是从无到有,从小到大,公司对负责架构设计的工程师和负责代码实施的程序员的区别不严格。不同的地方在于中国的互联网技术人员,受“学而优则仕”传统观念的影响,一旦做到30多岁就开始考虑向管理岗位转,停止写代码和做设计,很难找到50多岁还在一线写代码的情况。还有一个不同点是中国大学计算机相关专业的毕业生,他们选择专业往往是以能否容易就业为考虑的基础,对代码实施和架构设计的深入研究和长期坚持有限,换句话说真正热爱写代码的人少,而以写代码养家糊口的人多。
比较和反思这四段经历,可以得出以下两个结论:
第一、社会文化传统对公司研发职位的设计有直接的影响。等级森严的社会文化自然要求架构师、系统分析师和程序员分工明确,各司其职。比较包容和平等的社会文化可以模糊定义这些职位。
第二、在不同的发展阶段,公司应该采用不同的职位安排。初创性公司的员工人数很少,不必明确区分架构师与程序员,可以采用软件研发工程师来做模糊处理。有一定基础的成熟型公司,则可以明确地区分架构师和程序员。
中国的文化既不同于美国硅谷,也与日本和新加坡差异很大。我们的文化在平等和包容方面与硅谷差不多,在开放和技术素养方面,强于日本和新加坡,但比硅谷稍差,所以职位不能完全照搬硅谷的做法,以研发工程师的职位模糊所有其他的软件研发职位,而应该在编写代码和架构设计的分工上稍有不同。
在实际工作中,经常有初级的软件研发人员不仅编写代码,而且还负责设计架构。受到仅具备程序员水平的软件研发人员专业水平的局限,所以研发出来的应用系统的架构设计水平低下,代码实现也杂乱无章,这是很多CTO经常担心和苦闷的地方。
解决这个问题的主要方法是 ,根据中国社会的文化传统,互联网企业的不同文化以及公司的不同发展阶段,因地制宜地确定软件研发人员职位定义的模糊度。
在公司的初创阶段,在平等、开放、包容和技术人员素质较好(精英团队)的情况下,可以在一定程度上模糊程序员和架构师之间的职位差别,充分发挥工程师的主动性和创新精神。
但是对创业超过10年的老牌互联网公司而言,或者团队的精英含量较低的情况下,我们就不能简单地只设置软件研发工程师的岗位,而应该清楚地区分出架构师和程序员至少两种不同级别的职位。 明确架构师对架构负责,程序员对代码质量负责。避免小鬼当家,让程序员做架构师的设计工作,或者浪费架构师的时间写代码等类似的奇怪现象,以确保金融科技公司的架构能够有效地落地实施。
---------- END ----------
本公众号编辑部维护读者群之架构群,邀请了坐馆老司机曲健、伟山、安晓辉、史海峰嘉宾等参与交流。加群请在公众号回复:架构群。
往期推荐:
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Python Algorithms
Magnus Lie Hetland / Apress / 2010-11-24 / USD 49.99
Python Algorithms explains the Python approach to algorithm analysis and design. Written by Magnus Lie Hetland, author of Beginning Python, this book is sharply focused on classical algorithms, but it......一起来看看 《Python Algorithms》 这本书的介绍吧!