论程序员的戾气

迷南。 2022-10-17 11:20 121阅读 0赞

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

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

![7aad55ad5a24b70999f989c658f4a5ef.png][]

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

![c874b5efe6d00b482c708456cc1c18e5.png][]

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

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

### 程序员的鄙视链 ###

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

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

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

![071a999de91b64b767fd134a644ec29f.png][]

这个平台部所做的就是类似于`中台`的开发模式。 字节跳动包括今日头条和西瓜视频在内，有至少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的么。朋友说那是针对浏览器而言，后端微服务直接互调又不是浏览器。。。

![013e558d6989fd26006758560ba6deee.png][]

仔细了解了之后我才知道，后端的逻辑部署在服务器上，服务器的性能，比如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的跨平台原理完完全全不一样。对跨平台的偏见让我一年内都没有学习这个优秀的框架。

### 多体谅他人 ###

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

![49f457f9e45a88de827f7de8edd8ca67.png][]

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

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

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

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

### 最后 ###

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

[7aad55ad5a24b70999f989c658f4a5ef.png]: /images/20221014/10f38cf83e6f4977aef40be52d6e4337.png
[c874b5efe6d00b482c708456cc1c18e5.png]: /images/20221014/73e9af07d2e24d0280a6352ef621ef55.png
[071a999de91b64b767fd134a644ec29f.png]: /images/20221014/adc228e915ab49f5ad0cd8c21ced5ba1.png
[013e558d6989fd26006758560ba6deee.png]: /images/20221014/481983f37c354cc5b409ac82ae2f83d2.png
[49f457f9e45a88de827f7de8edd8ca67.png]: /images/20221014/8b758676dd6f47729a5c4c208dd00451.png