論程序員的戾氣

古人曾經說過文人相輕，最近愈來愈發現，程序員其實也沒有啥不一樣。戾氣，鄙視鏈一點也很多。很久沒更新了，就想談談我最近作項目裏面的一些感覺，關於程序員裏面一些很差的心態。寫這篇文章不是爲了標榜我本身有多麼清高，偏偏相反，而是爲了自省。就在文章動筆以前，我才發現戾氣是多麼容易傳播，本身也成了程序員內的害羣之馬。

就在上個周，我無心間發現掘金的一篇文章。

一看，是一篇關於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，想一想換了是本身應該作什麼樣的決定。若是對方作的不對，再想一想若是換了是本身之後怎麼避免一樣的錯誤，而不是在一句句」垃圾「中，關掉你的代碼編輯器。。。。

最後

寫在最後，也是一點點總結,雖然這篇文章不是什麼技術類型的東西，可是我以爲這是我最近作項目的一些收穫，也是屬於自我檢討。望與你們共勉。