论程序员的戾气

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

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

一看，是一篇关于 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，想想换了是自己应该做什么样的决定。如果对方做的不对，再想想如果换了是自己以后怎么避免同样的错误，而不是在一句句”垃圾“中，关掉你的代码编辑器。。。。

最后

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

作者：qing 的世界
链接：https://juejin.im/post/5ddad5356fb9a07abc1c1efb
来源：掘金