高考畢業那年，計算機專業非常火，我沒怎麼猶豫就入了程序員的“坑”。大學兼職時，我給一個高一男孩做家教。還記得第一天給他演示編程，他就驚呼起來：“哇，米哥，你也忒牛了吧，以前在電視裡感覺挺神的，真看到代碼運行出來的結果，崇拜、佩服！”
看著他崇拜的眼神，我雖然表面平靜，但心裡還是忍不住小開心了一下，那是我第一次感受到編程帶來的成就感。從那時開始，我就有了程序員的極致“潔癖”，以及不安分的好奇心。
第一次給代碼動手術
進入職場，和所有的年輕人一樣，我渾身有一股使不完的衝勁兒。有些人說我急性子，對於代碼，眼裡容不得一粒沙子。而隨著對業務及代碼的理解更加深入，我的代碼“潔癖”也愈發凸顯，看著“將就”的代碼，就覺得難受。
那時，我們一直在做A產品的特性交付，B模塊歷來是我們的老大難，經過長年累月不同開發人員的堆疊，架構早已令大家詬病不已，看起來很燒腦，要看懂得費半天勁兒，改起來就更別提了。
我思量著：“這麼費勁兒，不如一把改掉，以後看起來也乾淨利落，如果改好了，新員工進來都能秒懂，性能也能提升不少……”我決定對B模塊來一次大開刀！
起初，代碼咔咔地很快就寫出來了，正在我覺得即將大功告成、內心竊喜的時候，卻迎來當頭一棒：驗證階段一開始就出現了嚴重的性能問題。那天，我正在驗證C特性，按照以往的經驗，應該秒速獲得結果，可這回運行時間卻翻了N倍。我這急性子哪受得了，抓著頭，苦惱不已：這和預期差別也太大了！
幸運的是，當時算法部的兄弟小趙出差西安，收到我滿懷期待的求助，很快就成了我的盟友。
他仔細看了我的代碼：“這裡的算法還可以提升性能的……”講得特別細，讓我茅塞頓開。“天啊，不愧是研究算法的”我心裡暗想，“嗯，確實，有些細節還可以再優化。”
那些日子，我拉著他天天一起研究，他從算法維度提升性能，我再基於代碼本身提升性能。有時，為了一行代碼、一個函數，我和他會PK很久，誰都不讓誰，也會為突然閃現的一瞬間心有靈犀而嘿嘿一笑。我已經不記得改了多少次代碼、編了多少次版本。經過“地獄式”的磨練後，代碼性能相對之前提升了十倍，也因為這份全新的B模塊代碼，我獲得了那年的“網絡十大金碼獎”。
我還記得小趙離開西安前說的一句話：“米哥，我終於感受到什麼叫一線研發兄弟的炮火了，真的就像打仗啊！”可不是，不想將就，不就得大幹一場！
從修改300行代碼，到修改30行代碼
多年來，針對不同客戶的定製化需求，產品E已經衍生出多個版本。2017年，我成為PL，正值開發客戶定製的產品EF，由於老代碼的架構限制，每定製一個版本就需要修改300行代碼，而且修改點非常零散，需要投入很多人去開發、檢視、測試代碼，時常出現問題。
於是，我決定要改變這種長年累月的“困境”。我和彪哥連同小常、小曾重新梳理架構。然而，很快我就發現，這次重構與版本人力產生了一定衝突，隨之而來的質疑也讓我感受到了身心的雙重巨大壓力。
“米哥，重構能不能以後再搞？感覺對特性交付衝擊有點大。”有兄弟抱怨。
“咱們上一個定製版本遭的罪還歷歷在目啊，這個產品再這樣下去，一直做大量重複工作，我們的時間就是這樣被浪費的，效率低，質量也難以保證。”有兄弟提出不同意見。
“大家都知道這個情況，不過這麼多年了，一直沒人敢嘗試把它拎起來重新搞一遍。”還有人說。
我明白大家的難處，但是咬咬牙，這次挺過去，以後所有E產品就不用再耗那麼多時間和精力了。因此我和大家說：“版本交付節奏方面，我和項目組再商量下，適當給大家多留一些時間。但我們不能放棄！”
於是，我們針對零散的特性開關，整合了所有的能力集合、屬性集合，將不同定製版本的公共點提取出來，針對差異點集中適配。我還搭建起了“白盒測試框架”，開發階段就能夠深入到代碼的具體流程，可視化地看到每一步執行後的數據變化，進一步保障代碼交付質量。
這一次的代碼重構對整個項目組的收益是巨大的，曾經需要修改300行代碼被減少為30行。後來開發客戶定製的產品EG時，入職不到一年的新員工也能輕鬆交付，研發成本大幅度降低，質量也更好了。那一年，我們獲得了公司級架構優化的優秀實踐，我也因此獲得了公司“金牌個人”獎。
打造一支可信的團隊
我們時常會去思考：可信這個工作，團隊到底要做些什麼？但在我看來，有一個問題更為重要，那就是：為了帶動團隊落地可信，基層主管要先做些什麼？如果基層主管能夠在意識和行動上做出表率，那麼很多事情就變得簡單。
2019年，我成為了CGM（Component Group Manager），團隊從8個人變成了30個人，挑戰不小。我想，公司一直在倡導寫好代碼，可大家寫了那麼多年代碼，基本都有了自己的習慣，其實挺難改變的，得真切地讓大家感受到寫好代碼的好處、寫壞代碼的弊端。
為了給大家帶好頭，我整理了公司可信學院的所有資料，初步梳理了一些可以優化的模塊，套用設計模式修改。不久，我迎來了第一次“代碼壞味道Kill時刻”分享會。
“我們以前沒少被代碼壞味道坑，咱們自己一直在填坑。”我說。
“其實，咱也沒少挖坑。”大家都哈哈大笑了起來。是的，小李說出了大家的心聲。
“大家是不是每個人都知道設計模式有哪些？是不是都有一些編程思路和技巧的‘藏貨’？”我問大家。
“知道一些，但感覺不用那些設計模式，似乎也能搞定交付。”有人回答道。
會上，我以之前的G模塊為例，從思路到代碼框架，再到其中的編程技巧，向大家對比了修改前後的代碼差異，無論是代碼量、效率還是可讀性，都比之前要明顯好很多。
“要寫出這樣的好代碼，得先有這樣的硬能力。”有兄弟一針見血地說。
“沒錯，公司可信學院現在有一些資料，我們也可以買一些技術書籍，我和總工帶頭先看，後面把讀書收穫也納入我們的分享。”我說。
“最重要的還是實踐，不如以後我們就‘輪值’來分享自己的新嘗試、新發現？”有人提議。
大家你一言，我一語，討論得很火熱，提出了很多問題，也想出了很多妙招。為了將這樣的學習和討論滲入整個團隊，後來我們從每個小組抽取一人擔任“種子選手”，大家在一起研究試點模塊該如何重構、好的學習資源和思路，再讓“種子選手”們給各個小組帶回去，激發每個小組的學習意願，小組內互相分享、交流思想，大家寫好代碼的意識更足了，技術氛圍也比以前更濃了，交付的代碼比以前“漂亮”了，出的問題也比以前更少了。
永不停歇的編碼打怪之路
有人問我：“小米，你為什麼那麼痴迷於寫代碼？而且團隊還帶得那麼好？”
在我看來，知道自己喜歡幹什麼並去堅持下來，這是一件非常難能可貴的事情，在我的職場生涯中，唯一沒有落下的就是代碼，因為興趣，因為成就感，也為了避免自己的職場焦慮。
作為基層主管，如果在技術上不是團隊領先，那麼兄弟們就很難打心裡去信服你。技術強了，技術決策會更加高效、正確，才會有團隊威信力，每個人的勁兒也才能更好地使出來，團隊也才能擰成一股繩。
技術一直在變，我們要學的總是很多，可信之路很漫長，如果不去努力奔跑，就很難跟上前進的步伐。這個世界從來沒有免費的午餐，程序員的領地也總是充滿未知，與其焦慮，不如開啟“學霸式”編碼打怪之路，主動出擊。
可信不易，信者無疆；暗夜至深，自現光芒。
閱讀更多 菊廠工程師 的文章
