程序员的迷思——技术痛

程序员的迷思——技术痛

解放研发。

1 引子

带着耳机踮着脚的日子一去不复返,金属与轻音乐成为屏蔽外界的手段。熟练的敲击,机械的ENTER,过去翘首着的今天。

唯快不破,省去IDE,VIM里默念口诀,GyypA;

唯快不破,跳出C++,Python中背诵技法,for line in sys.stdin;

唯快不破,忘掉Coding,Copying组合重建,Ctrl-C Ctrl+V。

快到停不下来,一起翻车。

2 技术痛

信手拈来中,当下晴空万里。早有所料,人机合一的日子已然来到。

人活在代码里,或者说,代码流淌在血肉中。我是代码,代码是我。剪不断理还乱,累觉不爱。撕心裂肺的痛,外面放射着万丈光芒——敏捷开发、拥抱变化。

痛到麻木,心如止水,拼凑的逻辑不忍直视;痛到深处,远走高飞,留下的历史值得品味。

研发被技术束缚,内心充满无奈,耐心与精力随之耗尽,这便是技术痛。

3 认识痛

技术痛与技术债有不同,技术债是项目需要承担的;而技术痛是个人需要承受的。技术痛不像技术债那样可以轻易转移,更换环境可以延缓或改变痛苦的形式,但痛还会在那里。技术痛可以引发技术债,技术债亦可导致技术痛,处理不当容易恶性循环。

认识到这一点,可以帮助我们从埋怨的情绪里走出来。理性思考,我们为何而痛,以及如何减缓痛苦。

曾经研发是研发的产品,那时候外面的车轮声都与键盘合拍。现在,我们是技术的奴隶,似乎只能承接需求。拒绝意味着不专业,推脱等价于不负责。

我们张开双臂,口中大喊,来吧。内心则排斥,在这场集体活动里,大家在轻歌艳舞,你我独享呵呵。

综上,痛的来源主要有二:

  1. 业务带来的痛苦,痛在对需求的理解,做也痛,不做也痛
  2. 实现带来的痛苦,痛在对实现的把握,实现痛,实现之后更痛

3.1 业务痛

是不是权利空降,我们掌握需求大权,即可回到车轮声的年代。显然不是,那时我们会更加痛苦,Coding与价值,如何权衡?编码与产出,如何保证?

但这给我们带来了启发,如果技术之外了解产品,思考未来,或许可以避免一些不必要的呵呵。

这也早已写入一些公司的职业发展要求,技术不是边界,只是开始。

阿里巴巴内部晋升的渠道有四步:

  1. 晋升资格
  2. 主管提名
  3. 晋升委员会面试

个人述职包含:自我介绍、技术突破业务突破、述职总结、未来规划

  1. 晋升委员会投票

3.2 实现痛

业务可以有千千万,变化也是层出不穷。我们除了要考虑实现问题,更要思考设计问题。

架构设计的主要目的是为了解决软件系统复杂度带来的问题。

——李运华《从0开始学架构》

当我们陷入实现细节不能自拔的时候,反问一下自己,除了解需求,有没有解复杂度。

此时再品痛苦,实现带来的痛苦实质上是复杂度带来的。

这个思路同样可以拿来思考“业务痛”,产品眼里的妙不可言,研发心里则为一团乱麻,这也是复杂度。

因此,解痛就是解复杂度。

4 解复杂度

解复杂度首先要定位复杂度的根源,可以通过时间花费来判断,或者干脆问问内心,做什么事情的时候最痛苦,且这个痛苦很高频。

如果时间主要花在查Case,是否可以把一些常用的代码脚本化;更进步,是否可以提供一个平台,让产品查;再进一步,是否有更加智能的方式让查询和解决更高效。

如果时间主要花在改代码上,是否可以对代码优化,使其易于阅读和理解,可维护。

如果时间主要花在重复Coding上,是否可以把核心逻辑框架化,减少重复消耗,把精力花在优化框架上。

如果时间主要花在测试和上线,同样的逻辑,释放研发,让研发做专业的事情。

总之,解决的核心思路是使用中间层把研发释放出来。

计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。

——《代码之美》

中间层不会是雨前的晴空,一次次的重复与痛苦,在下一次狂风暴雨后,会来到。

可以肯定的是,手持一门技法可能会熬成婆,不设边界或许可以给予我们惊喜。

参考