原创

我所向往的技术团队

我思我在
5 条评论
11 人喜欢
288 次阅读
全文共 1462 预计阅读时长 5 分钟

这些都只是我所向往的好的技术团队的一些我自己的看法,可能会有些片面,但是这就是我想说和想要的,也希望未来能和这样一个团队,和这个团队里的小伙伴们一起玩耍和工作

我所向往的技术团队:

  1. 技术放在第一位
  2. 团队成员不怕闷,但必须得骚
  3. 团队执行力可以不强,但是绝不能弱
  4. 流程规范必须重视

技术放在第一位

Amazon 的使命是 “To be Earth’s most customer-centric company”,就像阿里巴巴「让天下没有难做的生意」一样,都是伟大的使命。无论是潜规则抑或明文规定,每一个技术团队都应该有自己的使命,且一定是以技术为第一位。

一个业务驱动的部门里,平常聊的都是业务,周会里也在谈业务,周报里依然全是业务项目汇报,全TM是业务。说实话我反感这样的团队,这样的团队往往变得越来越业务,越来越忽视技术,变得很“稳”,特别是团队项目都是哪些老旧的、念旧失修的系统的时候,“稳”到做很多技术规划时,都需要先把背景、目标和收益翻来覆去捯饬清楚,成员的激情一点点被消磨殆尽,技术人员会妥协,渐渐地更偏向于业务,反正只要系统运行良好就行了。

我想说对于一个团队来说,这种技术重视度的缺乏其实是非常可惜的,也很不利于技术人员的成长和发展,很难想象一个没有技术追求的团队能开发一个健壮、可维护性好、可扩展性强的系统,而是基本上都停留在系统能稳定运行上,这种对技术的忽视,到头来变现的只是一坨坨业务代码的堆砌。

你可能会说“我需求很快完成了呀”,对,从短期来看是快速地完成了业务需求,但是真的是这样吗?长远来看,这种堆砌就跟shit一样,对系统的可维护性没有一点帮助,技术人员被迫在业务需求和这些shit之间来回切磋,浪费时间。这样的堆砌形成的系统往往技术债越积越高,会像“黑洞”一样,吞噬着技术人员的时间和激情。

团队成员不怕闷,但必须得骚

扯点儿淡,都说程序员很闷,网上各种要嫁就嫁程序员的段子,毕竟话少钱多死得早的老公并不是到处都有的。一名优秀的程序员往往是闷骚的,当然明骚的程序员也不是没有,只不过TA们把大部分的经历都花在骚上,这也不好。

在我看来,只闷不骚的同学,对问题都是采取封闭式回答,短句了事,让你接茬都不知道咋接,那这样不好吗?不,我觉得挺好,好在对于技术问题往往能言简意赅,一针见血,没有长篇大幅的铺垫和扯淡,但是,这个还可以更好。

更好的地方是可以更骚一点,一名极度闷骚的程序员,面对TA感兴趣的话题,往往能像黄河之水滔滔不绝一样一直讲下去,拦也拦不住,而且有自己的想法,不愿妥协,针对技术问题往往会跳你的刺儿,非常的自信。我觉得这样的人真的很有特点,很有意思。

当然这种人也是少数,大部分的程序员都还是听本分的,中规中矩,闷中带着一点儿骚的。

团队执行力可以不强,但是绝不能弱

为什么说可以不强,但是绝不能弱呢?那是因为一个有着强执行力的团队,太TM少了,而且打造这样的团队也太TM难了。

团队各个成员性格,兴趣,水平各异,在这样一个环境下,一个团队的执行力,凝聚力往往要由团队TL来号召,这也就牵扯到如何做好一个团队的TL了。

一个没有执行力或者执行力弱的团队,就像上面“技术放在第一位”里面所讲的,往往会妥协,这个对于团队的发展和成员的成长也是很不利的。

所以我不求一个团队的执行力有多强,但是必须要有,而且还不能弱,当然如果处在一个强执行力的团队,那么可以说是非常幸运的了。

流程规范必须重视

这个流程规范其实更偏向于技术方面了,包括各种开发规范,代码规范,分支规范,review规范等等

其实这个是挺受团队历史原因影响的,往往团队的各个发展阶段都会继承上一个阶段的流程规范,可以说是一脉相承的了。如果流程规范最开始重视不起来,那么这个团队可能以后都会走这相同的一条路了。

就我目前来说,团队对于这个流程规范是没有重视的,各个成员代码风格混乱,code review可能就只是为了点那个 Approve按钮,对于技术细节的设计和实现没有一点自己的思考,而且对于前端测试这块更是嗤之以鼻,说前端业务代码不需要写测试。

其实归根结底,还是团队对于技术的重视程度不够

想到啥再写吧。。。

相关文章
5 条评论
中国  -  上海市 Mac OS X Chrome | 70

每次进你的 blog,都感觉自己电脑不行了 😐

中国  -  上海市 Mac OS X Chrome | 72

我没有什么设计能力,博客可以用你的样式吗(已经用了),如不允许我会尽快下线的