盡量努力的多去閱讀別人的代碼闽烙，越多越好
A閱讀代碼，特別喜歡看那些開源的好代碼。跟著文檔品讀那些開源的優(yōu)秀代碼的卓越之處黑竞，每當看到妙處捕发，A都覺得學到了新東西，感覺自己技術進步了許多很魂。
但是扎酷，當A閱讀自己公司的各種代碼的時候，大劉是相當沒有耐心的遏匆。他覺得別人代碼寫的太次了法挨，他把這些代碼統統成為“屎山”。
而B恰恰相反幅聘。老實說凡纳，B對市面上各種開源框架的了解水平，對各種中間件的內部原理理解都是遠遠不如A的帝蒿，經常還需要咨詢A荐糜。但是，對于公司的各項目代碼葛超，B卻是了如指掌暴氏，對各項目中的那些代碼和問題都是有十分深入的了解。
那么最終升職加薪不是A绣张，這是為什么答渔？
首先，公司除了需要A的技術能力侥涵，更需要的是作為技術專家解決公司實際問題的能力研儒。
由于A抵觸閱讀公司很多項目的代碼，所以独令，往往A的某些技術方案在落地的時候會出現脫節(jié)。有時候好芭，又由于對項目代碼的不理解燃箭，甚至沒有給出有效的解決方案。
而B舍败，由于對公司項目代碼了解的很深入招狸，雖然技術能力或者說知識面不如A，但是卻總是能給出最合理的解決方案來邻薯。長此以往裙戏，B反而比A更展示出了一位高級技術人員應該具有的能力。
很多程序員和A其實是一樣的厕诡，他們不喜歡自己公司的很多代碼累榜，認為這些代碼質量極差，文檔也非常欠缺，對自己的成長幫助不大壹罚。其實這個觀念其實是很有問題的葛作。
對這些所謂“屎山”的代碼，你如果全都讀進去猖凛，研究下去赂蠢，你起碼會有兩個好處:
（1）：你能具體知道代碼爛在什么地方，那么以后你的代碼就不會出現同樣的問題——由于你知道了爛代碼爛在哪里辨泳，你一定能寫出更好的代碼虱岂，從而讓那些屎山的代碼逐漸會被自己寫的好代碼所替代。這樣一比較菠红，你的專業(yè)能力會顯得非常突出第岖，讓更多的人認可你這位架構師的能力。
（2）：你對公司這些代碼讀的越多途乃，掌握的越多绍傲，你越不可替代——對公司這些代碼讀的越通透，你越能更快速輕松地把控這些代碼耍共，讓以后對這些代碼的變革變得更容易烫饼。而輕松修改、革新這些代碼的能力试读，就會變成你在這家公司不可替代性的重要因素杠纵。
所以，各種代碼钩骇，無論質量好壞比藻，都需要能讀懂讀通，并且讀的越多越好倘屹。
能讀懂讀通任何質量的代碼银亲，才是真正的掌握了閱讀代碼的能力。讀的越多纽匙，則能識別代碼質量的能力就越強务蝠，將來自己就越能寫出更好質量的代碼。-
能準確判斷項目的發(fā)展方向
A和B談的時候烛缔，讓A印象最深刻的就是馏段，B對項目發(fā)展狀態(tài)的精準判斷。
三年前践瓷，倆人一起搞了個供公司所有業(yè)務項目用的監(jiān)控系統院喜，目的是解決公司項目錯誤無法及時發(fā)現和處理的問題。
當時晕翠，這套監(jiān)控系統公司要的急喷舀，大家匆匆設計了一版，就趕緊趕鴨子上架的做了一版。
技術方案也沒花太多心思元咙，怎么快怎么來梯影。搞完之后，A覺得這項目以后也就這樣了庶香，公司內部項目甲棍，既沒有發(fā)展，也沒有什么前景赶掖。
可是感猛，如今和B溝通后，A才吃驚的發(fā)現奢赂，B居然一直跟著這個項目陪白，并對這項目進行了無數次總結分析和優(yōu)化。
隨著不斷地改進膳灶，這套項目竟然發(fā)展出來了一套非常完備的 APM 系統咱士，使用體驗非常不錯。公司的商務給客戶出解決方案的時候轧钓，經常也會連帶著把這套監(jiān)控系統包含到解決方案里序厉。客戶的反饋也很好毕箍，為公司拿下了更多的訂單弛房。
而A自己呢，為公司的核心系統設計了一套底層的服務調度編排框架而柑，公司很多系統的底層都依賴于這套框架文捶。
雖然這套框架大劉自己認為寫的很棒，但是由于部署復雜媒咳，對應的一些輔助工具鏈也由于A的忽視粹排，沒有及時開發(fā)出來。導致后續(xù)的新項目涩澡，大家寧肯用一些開源框架自己改進恨搓，也不再使用大劉的這套框架。
分析起來筏养，其實這也算是A和B對各自項目的發(fā)展判斷能力的差距導致的。
B根據用戶反饋和市場行情常拓，他感覺監(jiān)控系統本身應該是有前途的渐溶。并在調研了市面上競對產品的基礎上，讓這套監(jiān)控系統迸發(fā)出來了絢爛的色彩弄抬。
而A茎辐，高開低走，寫出來一個好框架，但是由于對框架的預期判斷錯誤拖陆，加上對用戶反饋重視不夠弛槐，最終導致本來應該非常出彩的框架就此沉淪了下去。 去主動管理會議
作為公司比較重要的技術專家依啰，大量的會議是免不了的乎串。
A對此非常煩惱，經常因為這些冗長的會議速警，耽誤了許多手頭的工作叹誉。
特別是，A作為架構師闷旧，需要大塊連續(xù)的時間去思考技術難題长豁，解決系統問題，以及考慮新項目的架構設計忙灼。但是頻繁的會議匠襟，把大劉的時間攪和的支離破碎。
對于這個問題该园，大劉在飯桌上請教了B酸舍。B說，他也面對了這些問題爬范，好在他通過一些自己的方法父腕，很大程度緩解了這些問題。
B做了如下幾個事情:
B對第二天的會議提前和參會各方溝通青瀑，開會時間盡量協調到一起璧亮，這樣B能騰出一整塊兒時間，把當日所有可能的會議都集中開完斥难。后續(xù)B就會有連續(xù)的時間去深度工作了枝嘶。
B會在開會前一天，把會議內容和可能出現的問題都預先做功課哑诊。一方面是防止會議開著開著跑題群扶；二是萬一出現爭議問題，B可以列舉出來事先準備的技術方案镀裤，這樣也能加快會議進度竞阐。
還有，對于一些不那么重要的會議暑劝，B一定會態(tài)度堅決的避開或者指派別人參加骆莹。
- 版本控制工具的熟練應用
這個問題是B主動和A提出來的。
B發(fā)現担猛，對于版本工具使用不當幕垦，會耽誤開發(fā)人員很多時間丢氢。而版本控制工具，即使一些工作多年的程序員先改，往往也經常會使用不當疚察。
這些不當的使用，會造成許多問題仇奶。比如貌嫡，各種各樣的代碼沖突、版本重疊猜嘱，莫名其妙的代碼丟失衅枫。
對此，B每次負責一個新項目朗伶，都會嚴格指定版本工具的使用規(guī)范弦撩，會花時間對開發(fā)人員統一培訓版本工具的使用。同時论皆，也會把各種技巧益楼、注意事項、常用命令整理好点晴，放在內部的共享文檔中感凤。
B的這些舉措，在實踐中粒督，大大改善了版本控制工具不當使用造成的問題陪竿。
有一個項目組在規(guī)范使用之后，竟然比之前的開發(fā)速度快了三分之一屠橄∽艴耍可想而知，這個問題有多嚴重了锐墙。
- 不要把解決方案復雜化
B和A談了談關于技術和技術落地之間存在的問題礁哄。
B和A都發(fā)現有些程序員特別喜歡炫技，這些炫技某些時候會導致整個系統復雜化溪北，最終產出反而不盡如人意桐绒。
B舉了個例子，比如之拨，一套內部使用的資產管理系統茉继，中間有一個需要調用公司其他項目接口的小功能，這種簡單的東西交給了一個比較年輕的程序員蚀乔。
結果這個程序員又是考慮對方接口不穩(wěn)定的情況烁竭，又是考慮這個功能會有使用過度頻繁的情況，還使用了緩存去儲存一些狀態(tài)乙墙，防止頻繁調用數據庫颖变。
對于這種情況，從純技術角度听想，當然會鼓勵人們想的越全面越好腥刹。但是，在實際落地的時候汉买，你要明白這只是一個公司內部使用的小項目衔峰，沒必要為了各種概率很低的風險，把明明很小的一個功能給做的很復雜蛙粘。
針對這種問題垫卤，就需要技術 Leader 及早發(fā)現、介入出牧，防止出現過度設計穴肘、過度開發(fā)。
- 把任務安排的井井有條
B其實和A一樣舔痕，每天雜事兒很多评抚，每天的任務也很多。大家對這些任務的管理能力自然就有高有低伯复。
B對于任務緊急程度的判斷都是經過深思熟慮慨代、實際分析過的，任務之間的先后順序啸如，也和任務交付人認真溝通過侍匙。對一些根本沒必要的任務，B會態(tài)度堅決的對這些任務說 No叮雳。
A自我總結想暗，他這方面做的不好。首先债鸡，他安排任務容易被任務交付人的情緒影響江滨，對方催的急，他就優(yōu)先安排厌均。其次唬滑，任何任務A都沒有拒絕過，頂多是排期靠后棺弊。最后晶密，A沒有考慮任務和任務之間的關系，有些任務之間是關聯的模她，完全可以融合一起搞定稻艰，A卻沒有思考，從而割裂開安排侈净，這也是很大的問題尊勿。
比如上次僧凤，A接到兩個任務：1、去掉 VMware元扔；2躯保、MQ 版本升級。
這兩個任務都需要業(yè)務系統停服才能干澎语，A當時也沒在意途事，兩個任務放在兩天，連續(xù)兩天停服擅羞，雖說每天停的時間不長吧……
這倆任務完全可以放在一起尸变，利用一次停服集中解決。這樣對用戶影響更小减俏，業(yè)務部門也不會那么不滿召烂。
- 不要死板的寫代碼
很多程序員知識面很寬，基本功也非常扎實垄懂。但是骑晶，有一種能力，是學校教不出來草慧、面試也不容易看出來的桶蛔，就是代碼能力。
所謂的代碼能力漫谷，有的是指寫代碼不出 Bug 的能力仔雷，有的是指算法落地能力……但這里想說的，是不寫死板的呆代碼的能力舔示。
這是什么意思呢碟婆？
我們都知道，程序員少不了要維護老項目惕稻。在維護項目的時候竖共，我們面對各種不斷的新需求，經常要去修改代碼俺祠。
修改代碼是個很危險的事情公给，因為我們修改的代碼往往會和別的功能耦合住。改了一點代碼蜘渣，結果影響一大片功能的情況經常出現淌铐。最虐心的是，這種連帶影響可能不會馬上出現蔫缸，不知道哪天就突然冒出來折騰一把腿准。
如果改代碼經常出問題，這誰扛得住笆奥怠吐葱！別說你自己的技術話語權了街望，也別說在職場脫穎而出了，工作能不能保得住都不好說弟跑。
所以它匕，對于修改代碼的事情，我們需要學會的是不要寫呆代碼窖认。再說的直白點就是，你不能寫完代碼運行下沒問題就覺得正常了告希，你在寫代碼之前需要好好思考扑浸。
這種思考，既不是什么搞設計模式松耦合燕偶，也不是搞功能切分獨立成塊喝噪。這種思考本質是需要你寫代碼前去理解業(yè)務，去真正明白業(yè)務在實際是怎么運作的指么。
簡單說兩個例子：
7.1. 修改完代碼后酝惧，用戶會怎么使用你現在修改的功能？
比如伯诬，你修改了注冊功能晚唇，可以兼容第三方登錄。那么盗似，可能有的老用戶會重新注冊一個賬號哩陕，以方便第三方登錄。那你對這種情況赫舒，其實該做的是綁定悍及，而不是讓用戶重新注冊個新賬號。
這種疏漏接癌，等到上線之后才發(fā)現就晚了心赶。這不能完全依賴產品經理，作為一個技術人員本來就應該對自己的功能做通盤的考慮缺猛，這才是真正的負責缨叫。
7.2. 你現在修改的功能，會不會由于運營需要枯夜，會換成你完全沒想過的用法弯汰？
比如，你搞一個用戶充值功能湖雹。本來你只是想著用戶游戲內購直接充值即可咏闪。但是，在實際上線后摔吏，有時候運營為了方便 vip 客戶或者為了和第三方渠道互換資源鸽嫂，也會使用這個充值功能纵装。
運營大批量的連續(xù)充值，并且這些充值轉換成系統中的貨幣据某，就像游戲中的元寶橡娄，就有可能超出 Java 中的整數上限，從而造成問題癣籽。如果你提前知道用戶挽唉、運營人員都是怎么使用這個功能的，你就會把數據類型修改成 Long 了筷狼。
類似的例子有很多瓶籽，B還要繼續(xù)說下去的時候，A給他打斷了埂材，“扎心了塑顺，你說這些坑我沒少掉進去∏蜗眨”
后記
通過和B溝通严拒，A知道自己的問題出在哪了。他明白了竖独，技術只是技術人員的基礎裤唠，在實際工作中想脫穎而出，除了要有過硬的技術莹痢，還需要你的態(tài)度巧骚、你的各種軟實力，需要你把技術轉化為實際生產力的能力格二。
