這篇文章我們繼續說架構師大劉的故事：
老田升職了，年薪漲到了百萬級別！
這是大劉在加班搞技術攻堅的時候，聽別的同事聊了那麼一嘴。
大劉心裡不是滋味兒。老田和大劉其實在這家公司之前就是同事了，老田能到這家公司，說起來還是大劉推薦的。
但是，在公司的這幾年，老田越來越受領導賞識，到如今，晉升成功，赫然成了大劉的上司。大劉百思不得其解。
大劉和老田本身在前家公司都是高階程式設計師，前後腳跳槽到了現在這家公司。
大劉來的早，成了架構師。老田呢，技術本就不如大劉，被大劉拉來後，先是當了個高階工程師，只是為了避嫌，沒跟大劉一個團隊。
後來，老田被那時候的 Leader 賞識，做了帶專案的組長，再後來，就是現在成功的晉升總監了。而大劉，好幾年了卻依然在架構師這崗位原地踏步，動彈不得。
大劉陷入了濃濃的迷茫，他自問自己工作態度毫無問題，做事情也兢兢業業。公司的技術攻關，經常也是大劉牽頭搞定。公司的技術培訓，作為架構師的大劉儼然是一個非常權威的大牛講師。
就算是老田，也需要時不時去找大劉請教一些技術難題和技術方向。可是，即使這樣，在公司技術領域造詣很深的大劉，卻依然沒有獲得進身之階，被老田壓了一頭。
大劉沒忍住，找了個不忙的日子，拉著老田去了個小飯館，在飯桌上，大劉就說起了他自己的尷尬處境以及對老田升職加薪的不解。
老田對大劉並沒有藏著掖著，在飯桌上，他和大劉坦誠溝通了他的經驗，並列出了他認為他可以升職加薪的一些非常突出的能力。
二人酒足飯飽，大劉回到家後，仔細琢磨深究，他總結了以下幾點。
1. 儘量努力的多去閱讀別人的程式碼，越多越好
這點大劉開始並沒當回事，可是在和老田溝通的過程中，大劉發現，老田理解的閱讀別人的程式碼和他理解的閱讀程式碼是兩回事。
大劉閱讀程式碼，特別喜歡看那些開源的好程式碼。跟著文件品讀那些開源的優秀程式碼的卓越之處，每當看到妙處，大劉都覺得學到了新東西，感覺自己技術進步了許多。
但是，當大劉閱讀自己公司的各種程式碼的時候，大劉是相當沒有耐心的。他覺得別人程式碼寫的太次了，他把這些程式碼統統成為“屎山”。
而老田恰恰相反。老實說，老田對市面上各種開源框架的瞭解水平，對各種中介軟體的內部原理理解都是遠遠不如大劉的，經常還需要諮詢大劉。
但是，對於公司的各專案程式碼，老田卻是瞭如指掌，對各專案中的那些程式碼和問題都是有十分深入的瞭解。
那麼最終升職加薪不是大劉，這是為什麼？
二人聊完之後，大劉終於明白了。
首先，公司除了需要大劉的技術能力，更需要的是作為技術專家解決公司實際問題的能力。
由於大劉牴觸閱讀公司很多專案的程式碼，所以，往往大劉的某些技術方案在落地的時候會出現脫節。有時候，又由於對專案程式碼的不理解，甚至沒有給出有效的解決方案。
而老田，由於對公司專案程式碼瞭解的很深入，雖然技術能力或者說知識面不如大劉，但是卻總是能給出最合理的解決方案來。
長此以往，老田反而比大劉更展示出了一位高階技術人員應該具有的能力。
很多程式設計師和大劉其實是一樣的，他們不喜歡自己公司的很多程式碼，認為這些程式碼質量極差，文件也非常欠缺，對自己的成長幫助不大。
其實這個觀念其實是很有問題的。
對這些所謂“屎山”的程式碼，你如果全都讀進去，研究下去，你起碼會有兩個好處:
-
你能具體知道程式碼爛在什麼地方，那麼以後你的程式碼就不會出現同樣的問題——由於你知道了爛程式碼爛在哪裡，你一定能寫出更好的程式碼，從而讓那些屎山的程式碼逐漸會被自己寫的好程式碼所替代。這樣一比較，你的專業能力會顯得非常突出，讓更多的人認可你這位架構師的能力。
-
你對公司這些程式碼讀的越多，掌握的越多，你越不可替代——對公司這些程式碼讀的越通透，你越能更快速輕鬆地把控這些程式碼，讓以後對這些程式碼的變革變得更容易。而輕鬆修改、革新這些程式碼的能力，就會變成你在這家公司不可替代性的重要因素。
所以，各種程式碼，無論質量好壞，都需要能讀懂讀通，並且讀的越多越好。
能讀懂讀通任何質量的程式碼，才是真正的掌握了閱讀程式碼的能力。讀的越多，則能識別程式碼質量的能力就越強，將來自己就越能寫出更好質量的程式碼。
2. 能準確判斷專案的發展方向
大劉和老田談的時候，讓大劉印象最深刻的就是，老田對專案發展狀態的精準判斷。
三年前，倆人一起搞了個供公司所有業務專案用的監控系統，目的是解決公司專案錯誤無法及時發現和處理的問題。
當時，這套監控系統公司要的急，大家匆匆設計了一版，就趕緊趕鴨子上架的做了一版。
技術方案也沒花太多心思，怎麼快怎麼來。搞完之後，大劉覺得這專案以後也就這樣了，公司內部專案，既沒有發展，也沒有什麼前景。
可是，如今和老田溝通後，大劉才吃驚的發現，老田居然一直跟著這個專案，並對這專案進行了無數次總結分析和優化。
隨著不斷地改進，這套專案竟然發展出來了一套非常完備的 APM 系統，使用體驗非常不錯。公司的商務給客戶出解決方案的時候，經常也會連帶著把這套監控系統包含到解決方案裡。客戶的反饋也很好，為公司拿下了更多的訂單。
而大劉自己呢，為公司的核心繫統設計了一套底層的服務排程編排框架，公司很多系統的底層都依賴於這套框架。
雖然這套框架大劉自己認為寫的很棒，但是由於部署複雜，對應的一些輔助工具鏈也由於大劉的忽視，沒有及時開發出來。導致後續的新專案，大家寧肯用一些開源框架自己改進，也不再使用大劉的這套框架。
分析起來，其實這也算是大劉和老田對各自專案的發展判斷能力的差距導致的。
老田根據使用者反饋和市場行情，他感覺監控系統本身應該是有前途的。並在調研了市面上競對產品的基礎上，讓這套監控系統迸發出來了絢爛的色彩。
而大劉，高開低走，寫出來一個好框架，但是由於對框架的預期判斷錯誤，加上對使用者反饋重視不夠，最終導致本來應該非常出彩的框架就此沉淪了下去。
3. 去主動管理會議
作為公司比較重要的技術專家，大量的會議是免不了的。
大劉對此非常煩惱，經常因為這些冗長的會議，耽誤了許多手頭的工作。
特別是，大劉作為架構師，需要大塊連續的時間去思考技術難題，解決系統問題，以及考慮新專案的架構設計。但是頻繁的會議，把大劉的時間攪和的支離破碎。
對於這個問題，大劉在飯桌上請教了老田。老田說，他也面對了這些問題，好在他通過一些自己的方法，很大程度緩解了這些問題。
老田做了如下幾個事情:
-
老田對第二天的會議提前和參會各方溝通，開會時間儘量協調到一起，這樣老田能騰出一整塊兒時間，把當日所有可能的會議都集中開完。後續老田就會有連續的時間去深度工作了。
-
老田會在開會前一天，把會議內容和可能出現的問題都預先做功課。一方面是防止會議開著開著跑題；二是萬一出現爭議問題，老田可以列舉出來事先準備的技術方案，這樣也能加快會議進度。
-
還有，對於一些不那麼重要的會議，老田一定會態度堅決的避開或者指派別人參加。
4. 版本控制工具的熟練應用
這個問題是老田主動和大劉提出來的。
老田發現，對於版本工具使用不當，會耽誤開發人員很多時間。而版本控制工具，即使一些工作多年的程式設計師，往往也經常會使用不當。
這些不當的使用，會造成許多問題。比如，各種各樣的程式碼衝突、版本重疊，莫名其妙的程式碼丟失。
對此，老田每次負責一個新專案，都會嚴格指定版本工具的使用規範，會花時間對開發人員統一培訓版本工具的使用。同時，也會把各種技巧、注意事項、常用命令整理好，放在內部的共享文件中。
老田的這些舉措，在實踐中，大大改善了版本控制工具不當使用造成的問題。
有一個專案組在規範使用之後，竟然比之前的開發速度快了三分之一。可想而知，這個問題有多嚴重了。
5. 不要把解決方案複雜化
老田和大劉談了談關於技術和技術落地之間存在的問題。
老田和大劉都發現有些程式設計師特別喜歡炫技，這些炫技某些時候會導致整個系統複雜化，最終產出反而不盡如人意。
老田舉了個例子，比如，一套內部使用的資產管理系統，中間有一個需要呼叫公司其他專案介面的小功能，這種簡單的東西交給了一個比較年輕的程式設計師。
結果這個程式設計師又是考慮對方介面不穩定的情況，又是考慮這個功能會有使用過度頻繁的情況，還使用了快取去儲存一些狀態，防止頻繁呼叫資料庫。
對於這種情況，從純技術角度，當然會鼓勵人們想的越全面越好。但是，在實際落地的時候，你要明白這只是一個公司內部使用的小專案，沒必要為了各種概率很低的風險，把明明很小的一個功能給做的很複雜。
針對這種問題，就需要技術 Leader 及早發現、介入，防止出現過度設計、過度開發。
6. 把任務安排的井井有條
老田其實和大劉一樣，每天雜事兒很多，每天的任務也很多。大家對這些任務的管理能力自然就有高有低。
老田對於任務緊急程度的判斷都是經過深思熟慮、實際分析過的，任務之間的先後順序，也和任務交付人認真溝通過。對一些根本沒必要的任務，老田會態度堅決的對這些任務說 No。
大劉自我總結，他這方面做的不好。首先，他安排任務容易被任務交付人的情緒影響，對方催的急，他就優先安排。其次，任何任務大劉都沒有拒絕過，頂多是排期靠後。最後，大劉沒有考慮任務和任務之間的關係，有些任務之間是關聯的，完全可以融合一起搞定，大劉卻沒有思考，從而割裂開安排，這也是很大的問題。
比如上次，大劉接到兩個任務：1、去掉 VMware；2、MQ 版本升級。
這兩個任務都需要業務系統停服才能幹，大劉當時也沒在意，兩個任務放在兩天，連續兩天停服，雖說每天停的時間不長吧……
這倆任務完全可以放在一起，利用一次停服集中解決。這樣對使用者影響更小，業務部門也不會那麼不滿。
7. 不要死板的寫程式碼
很多程式設計師知識面很寬，基本功也非常紮實。但是，有一種能力，是學校教不出來、面試也不容易看出來的，就是程式碼能力。
所謂的程式碼能力，有的是指寫程式碼不出 Bug 的能力，有的是指演算法落地能力……但這裡想說的，是不寫死板的呆程式碼的能力。
這是什麼意思呢？
我們都知道，程式設計師少不了要維護老專案。在維護專案的時候，我們面對各種不斷的新需求，經常要去修改程式碼。
修改程式碼是個很危險的事情，因為我們修改的程式碼往往會和別的功能耦合住。改了一點程式碼，結果影響一大片功能的情況經常出現。最虐心的是，這種連帶影響可能不會馬上出現，不知道哪天就突然冒出來折騰一把。
如果改程式碼經常出問題，這誰扛得住啊！別說你自己的技術話語權了，也別說在職場脫穎而出了，工作能不能保得住都不好說。
所以，對於修改程式碼的事情，我們需要學會的是不要寫呆程式碼。再說的直白點就是，你不能寫完程式碼執行下沒問題就覺得正常了，你在寫程式碼之前需要好好思考。
這種思考，既不是什麼搞設計模式鬆耦合，也不是搞功能切分獨立成塊。這種思考本質是需要你寫程式碼前去理解業務，去真正明白業務在實際是怎麼運作的。
簡單說兩個例子：
7.1. 修改完程式碼後，使用者會怎麼使用你現在修改的功能？
比如，你修改了註冊功能，可以相容第三方登入。那麼，可能有的老使用者會重新註冊一個賬號，以方便第三方登入。那你對這種情況，其實該做的是繫結，而不是讓使用者重新註冊個新賬號。
這種疏漏，等到上線之後才發現就晚了。這不能完全依賴產品經理，作為一個技術人員本來就應該對自己的功能做通盤的考慮，這才是真正的負責。
7.2. 你現在修改的功能，會不會由於運營需要，會換成你完全沒想過的用法？
比如，你搞一個使用者充值功能。本來你只是想著使用者遊戲內購直接充值即可。但是，在實際上線後，有時候運營為了方便 vip 客戶或者為了和第三方渠道互換資源，也會使用這個充值功能。
運營大批量的連續充值，並且這些充值轉換成系統中的貨幣，就像遊戲中的元寶，就有可能超出 Java 中的整數上限，從而造成問題。如果你提前知道使用者、運營人員都是怎麼使用這個功能的，你就會把資料型別修改成 Long 了。
類似的例子有很多，老田還要繼續說下去的時候，大劉給他打斷了，“扎心了，你說這些坑我沒少掉進去。”
後記
通過和老田溝通，大劉知道自己的問題出在哪了。他明白了，技術只是技術人員的基礎，在實際工作中想脫穎而出，除了要有過硬的技術，還需要你的態度、你的各種軟實力，需要你把技術轉化為實際生產力的能力。
大劉的故事這次先說到這裡。
我準備了一些純手打的高質量PDF：
深入淺出Java多執行緒、HTTP超全彙總、Java基礎核心總結、程式設計師必知的硬核知識大全、簡歷面試談薪的超全乾貨。
別看數量不多，但篇篇都是乾貨，看完的都說很肝。
領取方式：掃碼關注後，在公眾號後臺回覆：666
