论程序员的戾气

7,270 阅读9分钟

古人曾经说过文人相轻,最近越来越发现,程序员其实也没有啥不同。戾气,鄙视链一点也不少。好久没更新了,就想谈谈我最近做项目里面的一些感受,关于程序员里面一些不好的心态。写这篇文章不是为了标榜我自己有多么清高,恰恰相反,而是为了自省。就在文章动笔之前,我才发现戾气是多么容易传播,自己也成了程序员内的害群之马。

就在上个周,我无意间发现掘金的一篇文章。

一看,是一篇关于java教程的文章,github博主宣传了一下自己的教程repo。当时还不自知,但是一瞬间一股酸意就蔓延我全身,觉得这种教程类的东西看的太多了,还每次当github开源来宣传,有点骗人的感觉。再加上看到一条和我想法差不多的评论,就顺势的再添油加醋了一下:

一不小心,我变成了我最讨厌的那种人。事后三天,我又再仔细想了想自己的所作所为,实在很不妥。看看别人60k star的repo,再看看我自己空荡荡的github。。。shame on me。于是我马上在原文下面给博主道了歉,如果他能看到我这篇文章,也希望他真的感受到我的愧疚。

不管是不是程序员,人,都是很容易被自己的既定思维所禁锢的。 而且给予否定比肯定更容易。说白了,就是判定对方是sb比由衷佩服要简单。

程序员的鄙视链

坊间流传的鄙视链,干人工智能的瞧不起做后端的,做后端的瞧不起做前端的,做前端的瞧不起做客户端的。相信大家都有所耳闻。我以前也曾经因为是做安卓开发,总觉得自己很low,相比于自己做云计算的朋友们,好像说话的底气就少了一些。 直到前些时间,我才发现一个人的聪明和智慧,并不会因为他身处哪一而被掩盖。

最近很流行一个大中台的概念。但是说的比较多的都是后端。比如阿里的中间件等等。但是其实很多人都没想过,其实客户端开发也是有中台的。

举个例子,前段时间字节跳动组织了一次flutter的分享。袁辉辉和李梦云老师就分享了他们在flutter技术上的一些突破和创新。值得注意的是,他们两个都是来自移动平台部

这个平台部所做的就是类似于中台的开发模式。 字节跳动包括今日头条和西瓜视频在内,有至少20-30+款产品。每一个产品的基础架构都由该部门负责。 比如,图片加载在flutter上的高效实现,动态化等等。下到flutter engine级别的优化,上到与业务对接的flutter application,都会有方案落地。这不就是相当于移动开发的中台么?

在李梦云的分享中,我看到了他们团队的细致,能深入到机器码和编译原理的角度去分析包大小,去给谷歌fire issue。我不觉得像他这样的人如果换岗位换方向会搞不定。说白了,聪明,勤奋,有思考能力,不管是做哪一端都不是问题,更不要谈什么鄙视不鄙视的了。

可能会有人说,那毕竟这种移动平台端的团队,也不是每个人都能去的了。现在大部分移动开发岗位还是面向业务的,我这么分析属于站着说话不腰疼。

但是大家有没有想过,别的方向,比如后端开发,难道就没有这种困境么?据我所了解,哪怕是大厂,后端开发岗也有每天CRUD的机械化工作。。。。每个后端都想成为架构师,都想做设计,但是到头来还不是大部分情况要和业务逻辑打交道。尤其是我司AWS部门的朋友们,流传着一条金句:抱着做架构师的心进来,带着做support的技术栈离职。调侃归调侃,但是这样的困局是每个”端“都会遇到的。只有让自己少点戾气,多学习,才可能更进一步。 但是除了自己闷头苦学,还要学会睁眼看世界,扩大自己思维的格局。这就引入第二点:

程序员要学会多交流

我在这里举个实际的例子。大家做安卓的,应该都听过所谓的什么网络的三级缓存 .其实无非就是RAM Cache和Disk Cache。尤其是现在很多HTTP框架的源码分析都喜欢强调这一点。这可能会让移动开发的朋友们觉得做Disk Cache是理所应当的。

前几天和我们一个部门后端的朋友无意中聊天,他说最近在想着怎么提高他们调用微服务rest api 的 RAM缓存命中率。我随意问了一句,你们Disk Cache的命中率难道有啥不一样么?朋友说,我们后端不会cache到disk上的。。。当时我就震惊了,还有不缓存到disk上面的?远古的HTTP框架Volley不就是会把api call的response缓存到设备的private folder里面么?这是面试必备的知识点啊。。。你们难道不遵守max-age这个http header的么。朋友说那是针对浏览器而言,后端微服务直接互调又不是浏览器。。。

仔细了解了之后我才知道,后端的逻辑部署在服务器上,服务器的性能,比如RAM大小要比移动设备强得多,这也是为什么后端的in ram的队列中间件这么流行的原因 (Kafka、ActiveMQ、RabbitMQ、RocketMQ, 可能移动端的小伙伴就觉得不就是一个队列嘛,很普通的数据结构而已) 。 再加上微服务直接互相的api call,可能时间上要比服务器访问自己的硬盘速度还要快的多,据这位朋友说是1ms与6-10ms的区别,所以从时间成本的角度来说还不如直接在call一次api 或者调用RAM Cache。

移动设备,因为涉及到用户流量这个问题,尤其是现在大多数app的页面是以展示图片为主,所以把api call缓存到设备上非常合理,这是一种用空间换流量的思维,后端就不一样了,他们没有这样的需要,api call有时候甚至是微服务直接互相调用,也没有节省流量(当然load balancing这种是另一回事了)这样的需求,采用用流量换速度的方式当然没毛病。

这只是一个简单的例子,我的中心思想是,无论是哪一端的程序员,都需要拓展自己的知识面,不能只护着自己的那一亩三分地,以为那才是真理。而应该走出去,多和同一端不同的实现,或者是不同端的同行多交流才能让自己掌握的只是更加夯实。前端的朋友多和后端的朋友交流,才能知道线程池调优是有多么重要,后端的朋友和前端的朋友多交流,才能了解前端开发的一些业务需求和限制,给自己的工作也添砖加瓦。

甚至是同端之间,也需要多参加一些交流会,多看看网上的资料和博客,看看现在的发展趋势。(我就不说我司某朋友到现在2019年了还天天抱着AsyncTask不放。。。。。)

更有甚者,会因为偏见和傲慢导致自己无法进步。自己喜欢使用的一个框架或者编程语言被人嫌弃而在论坛上互喷。比如自己用了RxJava,就觉得这个是最厉害的多线程框架。一旦有人说几句不好的就疯狂攻击。殊不知如果用善意的态度和对方交流,说不定能收获更多。

举个例子,我一直是很看不上所谓的跨平台开发的框架,比如以前我还在IBM支持Cordova的时候,就觉得这种靠webview的开发模式实在是辣鸡。。。等大家开始用React Native了,我也是一样的态度,觉得这种中间转换层的方法不高效。等到去年出了flutter,我也是抱着一样的想法,所以也一直没接触和了解。直到今年看到了袁辉辉老师的博客,我才知道flutter的跨平台原理完完全全不一样。对跨平台的偏见让我一年内都没有学习这个优秀的框架。

多体谅他人

相信很多程序员刚刚入职,了解产品代码的时候都会有下面这种心情:

我们经常习惯性的去吐槽,去抱怨。然后到自己离职的时候,公司新人一样可能会吐槽你写的代码,从而陷入一个循环。。。。

在我看来,不给解决方案的吐槽都是耍流氓。大家都知道,破坏比建设简单,同样的,改进也比吐槽难。

程序员有时候很容易陷入一种自视甚高的幻觉之中,总觉得自己写的代码就是屌,一旦稍微有点看不懂别人的代码就觉得是垃圾。其实殊不知自己的代码在别人眼中也可能是垃圾,但是我们互相又不接受这个事实。我在现在的组里面有一些相似的体验,有些同事每每自己的代码有bug了,最后都不忘挖苦一下前人,说到是因为前面的代码结构太乱了,我这边不好改而导致的。最后问改进意见呢,hmm,说不出来。每周开小组讨论会,探讨代码质量的改进方案和benchmark的时候,也不出声。。。。

一个优秀的程序员,首先应该看到别人代码的闪光点,对于不同的意见,应该再想想为什么当初对方要做出这样的决定,如果是符合当时情况的一个work around,想想换了是自己应该做什么样的决定。如果对方做的不对,再想想如果换了是自己以后怎么避免同样的错误,而不是在一句句”垃圾“中,关掉你的代码编辑器。。。。

最后

写在最后,也是一点点总结,虽然这篇文章不是什么技术类型的东西,但是我觉得这是我最近做项目的一些收获,也是属于自我反省。望与大家共勉。