古人曾經說過文人相輕，最近越來越發現，程序員其實也沒有啥不同。戾氣，鄙視鏈一點也不少。好久沒更新了，就想談談我最近做項目裏面的一些感受，關於程序員裏面一些不好的心態。寫這篇文章不是爲了標榜我自己有多麼清高，恰恰相反，而是爲了自省。就在文章動筆之前，我才發現戾氣是多麼容易傳播，自己也成了程序員內的害羣之馬。
就在上個周，我無意間發現掘金的一篇文章。
一看，是一篇關於java教程的文章，github博主宣傳了一下自己的教程repo。當時還不自知，但是一瞬間一股酸意就蔓延我全身，覺得這種教程類的東西看的太多了，還每次當github開源來宣傳，有點騙人的感覺。再加上看到一條和我想法差不多的評論，就順勢的再添油加醋了一下:
一不小心，我變成了我最討厭的那種人。事後三天，我又再仔細想了想自己的所作所爲，實在很不妥。看看別人60k star的repo，再看看我自己空蕩蕩的github。。。shame on me。於是我馬上在原文下面給博主道了歉，如果他能看到我這篇文章，也希望他真的感受到我的愧疚。
不管是不是程序員，人，都是很容易被自己的既定思維所禁錮的。 而且給予否定比肯定更容易。直白了，就是判定對方是sb比由衷佩服要簡單。
程序員的鄙視鏈
坊間流傳的鄙視鏈，幹人工智能的瞧不起做後端的，做後端的瞧不起做前端的，做前端的瞧不起做客戶端的。相信大家都有所耳聞。我以前也曾經因爲是做安卓開發，總覺得自己很low，相比於自己做雲計算的朋友們，好像說話的底氣就少了一些。
直到前些時間，我才發現一個人的聰明和智慧，並不會因爲他身處哪一端而被掩蓋。
最近很流行一個大中臺的概念。但是說的比較多的都是後端。比如阿里的中間件等等。但是其實很多人都沒想過，其實客戶端開發也是有中臺的。
舉個例子，前段時間字節跳動組織了一次flutter的分享。袁輝輝和徐夢雲老師就分享了他們在flutter技術上的一些突破和創新。值得注意的是，他們兩個都是來自移動平臺部。
這個平臺部所做的就是類似於中臺的開發模式。 字節跳動包括今日頭條和西瓜視頻在內，有至少20-30+款產品。每一個產品的基礎架構都由該部門負責。 比如，圖片加載在flutter上的高效實現，個app上的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的開發模式實在是辣雞。。。等大家開始用RN了，我也是一樣的態度，覺得這種中間轉換層的方法不高效。等到去年出了flutter，我也是抱着一樣的想法，所以也一直沒接觸和了解。直到今年看到了袁輝輝老師的博客，我才知道flutter的跨平臺原理完完全全不一樣。對跨平臺的偏見讓我一年內都沒有學習這個優秀的框架。
多體諒他人
相信很多程序員剛剛入職，瞭解產品代碼的時候都會有下面這種心情:
我們經常習慣性的去吐槽，去抱怨。然後到自己離職的時候，公司新人一樣可能會吐槽你寫的代碼，從而陷入一個循環。。。。
在我看來，不給解決方案的吐槽都是耍流氓。大家都知道，破壞比建設簡單，同樣的，吐槽也比去改進難。
程序員有時候很容易陷入一種自視甚高的幻覺之中，總覺得自己寫的代碼就是屌，一旦稍微有點看不懂別人的代碼就覺得是垃圾。其實殊不知自己的代碼在別人眼中也可能是垃圾，但是我們互相又不接受這個事實。我在現在的組裏面有一些相似的體驗，有些同事每每自己的代碼有bug了，最後都不忘挖苦一下前人，說到是因爲前面的代碼結構太亂了，我這邊不好改而導致的。最後問改進意見呢，hmm，說不出來。每週開小組討論會，探討代碼質量的改進方案和benchmark的時候，也不出聲。。。。
一個優秀的程序員，首先應該看到別人代碼的閃光點，對於不同的意見，應該再想想爲什麼當初對方要做出這樣的決定，如果是符合當時情況的一個work around，想想換了是自己應該做什麼樣的決定。如果對方做的不對，再想想如果換了是自己以後怎麼避免同樣的錯誤，而不是在一句句”垃圾“中，關掉你的代碼編輯器。。。。
最後
寫在最後，也是一點點總結,雖然這篇文章不是什麼技術類型的東西，但是我覺得這是我最近做項目的一些收穫，也是屬於自我反省。望與大家共勉。