前言

作為脈脈和前端技術(shù)社區(qū)的活躍分子，我比較幸運(yùn)的有了諸多面試機(jī)會并最終一路升級打怪如愿來到了這里。正式入職時間為2021年1月4日，也就是元旦后的第一個工作日。對于這一天，我印象深刻。踩著2020年的尾巴接到offer,屬實(shí)是過了一個快樂的元旦。不知不覺已經(jīng)兩年多了,細(xì)細(xì)回想起來，更多的是歲月推移，并沒有回頭看看現(xiàn)在的自己和兩年前的自己有什么差別。

決定寫文章記錄一下還要感謝那個離職前在飛書上和我告別的老哥，他說已經(jīng)學(xué)到了想學(xué)的。

那我呢？似乎還沒有。

和優(yōu)秀的人做有挑戰(zhàn)的事不止是簡單的一句話。

在字節(jié)停留時間越久，越是能感覺到身邊人的優(yōu)秀，也正是這份優(yōu)秀推動著我不斷前進(jìn)。

本文將會從思維方式、問題排查、技術(shù)思考三個方面以回顧自我成長的視角展開敘述，歡迎閱讀。

思維方式

思維方式指的是看待事物的角度、方式和方法。放到工作當(dāng)中來看，我逐漸摸索出了幾個具體的點(diǎn)。

工作優(yōu)先級

曾很長一段時間里，我在工作上沒有刻意區(qū)分優(yōu)先級或者說有優(yōu)先級但是區(qū)分度不是那么明顯。這意味著只要不是恰好有緊急事情處理，基本上業(yè)務(wù)方提過來的合理需求我都會第一時間安排。不論需求大小，也不問緊急程度，都默認(rèn)當(dāng)作緊急處理。

誠然，在交付后得到業(yè)務(wù)方肯定的那一刻是有成就感的。但我逐漸意識到，這真的是有點(diǎn)本末倒置。由于我負(fù)責(zé)的這部分工作和底層數(shù)據(jù)相關(guān)，可能很多需求直接或間接的都會找到我。事實(shí)上，完成對齊過的工作才是我更應(yīng)該高優(yōu)做的事，剩下時間用來完成這些零散需求才更為合理。

起初我覺得有些小需求可能就是一兩行代碼的事，順手一個分支就帶上去了。但仔細(xì)想想，這好像引發(fā)了蝴蝶效應(yīng)。一件事僅僅完成是不夠的，該有的環(huán)節(jié)要有。 開發(fā)，測試，上線，周知業(yè)務(wù)方驗(yàn)收。這樣一個小流程走下來耗費(fèi)的時間可不僅僅是一兩行代碼占用的時間可比。更何況，可能還不止一個零散需求。時不時被打斷，自然就會導(dǎo)致原有工作安排非預(yù)期delay。

在意識到這個問題后，來自業(yè)務(wù)方的需求我會主動問一下優(yōu)先級。如果不是特別緊急的事情將不會安排在當(dāng)前周期的工作計劃里。此外，優(yōu)先級判定上我會和業(yè)務(wù)方確認(rèn)完使用場景后有自己的思考。對接次數(shù)多了，發(fā)現(xiàn)有些緊急并不是真的緊急，只是單純的性子急。后來，對于這種零散需求，我會在項(xiàng)目管理平臺寫好描述和需求提出人，方便后續(xù)溝通。

這個記錄還是很有意義的，深感好處明顯。

• 可以起到一個備忘錄的作用，定期查看，提醒自己有todo要處理
• 業(yè)務(wù)方(需求提出人)可能因業(yè)務(wù)場景變更或有了其他解決方案，不再需要后續(xù)支持
• 原業(yè)務(wù)方(需求提出人)轉(zhuǎn)崗或離職，不再需要后續(xù)支持

等到?jīng)Q定去做的時候，如果發(fā)現(xiàn)時間間隔較久，不要急著寫代碼，先和業(yè)務(wù)方二次確認(rèn)這個需求是否有必要繼續(xù)做。試想，如果耗時耗力做完，最后邀請業(yè)務(wù)方驗(yàn)收時候?qū)Ψ接址答佊貌坏搅?。什么心?#xff1f;那肯定滿臉黑人問號啊？實(shí)慘如我，曾有過這樣的經(jīng)歷。深感前置確認(rèn)真的很有必要，這樣能有效避免打黑工的場景。

在有意識對工作優(yōu)先級進(jìn)行劃分后，原定對齊的工作進(jìn)展基本都可以得到保障。等到工作周期結(jié)束進(jìn)行總結(jié)的時候，看到比較高的完成度，我覺得這份成就感更高。

ROI考量

ROI 全稱為 Return On Investment，指的是投資回報率。我是在完成一個比較重要的功能模塊遷移后才更加認(rèn)識到這個東西的重要性。在做數(shù)據(jù)遷移的時候，我寫腳本進(jìn)行的全量遷移。為了兼容新舊平臺的格式差異，我做了好幾處的格式轉(zhuǎn)換，過程中還遇到好幾個bad case需要手動處理，總之并不是那么順利。等到一切準(zhǔn)備就緒，我開始拉群周知用戶并以表格形式逐個進(jìn)行使用情況的回訪。結(jié)果很尷尬，實(shí)際使用的用戶遠(yuǎn)低于歷史存量用戶。量少到我完全可以采用更快的手動遷移，省去做格式轉(zhuǎn)換和寫腳本的時間。

對于那些實(shí)際沒人用的數(shù)據(jù)，我后來又進(jìn)行了刪除處理。這一波操作下來，真的投入產(chǎn)出比就不高了。算是吃一塹長一智吧，在對一個功能模塊進(jìn)行遷移的時候，前置工作除了搞清楚歷史背景，實(shí)現(xiàn)原理，更應(yīng)該確定實(shí)際使用人群。尤其是對于一個存在年頭比我入職時間還久的功能，更應(yīng)該花時間在這個點(diǎn)上好好調(diào)研下。確定目標(biāo)人群才好"對癥下藥",這樣才有可能是多人的狂歡而非僅僅是一個人單純完成遷移工作的孤獨(dú)玩耍。

有心和無意真的是兩種不同的感覺。 實(shí)際上，在經(jīng)歷這個事情之前我對自己研發(fā)的模塊也會有很多想法。有較長一段時間里，我腦海中冒出來的小想法會連同某個分支功能帶上去，改動不大，但是可能要思考的點(diǎn)會比較多?，F(xiàn)在回想起來，大多數(shù)屬于ROI比較低的。而現(xiàn)在，不論是業(yè)務(wù)方提出的需求還是我自己的小想法我都會優(yōu)先考慮ROI的問題。時間是很寶貴的，在有限時間內(nèi)產(chǎn)生更高價值帶來的成就感和自我認(rèn)同感絕對是翻倍的。

技術(shù)與業(yè)務(wù)關(guān)聯(lián)

在來字節(jié)前，我很喜歡花大把的時間去鉆研一些自己喜歡但可能實(shí)際未必會用到或者說使用場景比較局限的東西。比如我曾跟著視頻教程鼓搗過一段時間的Angular 1.x 。當(dāng)時覺得ng-xx這個指令寫起來倍感新奇，有種發(fā)現(xiàn)新大陸的小激動。也曾跟風(fēng)學(xué)過一段時間的php,被其數(shù)量龐大的內(nèi)置函數(shù)所震驚。等轉(zhuǎn)回到業(yè)務(wù)上，發(fā)現(xiàn)花費(fèi)大量時間研究的東西和業(yè)務(wù)根本不沾邊或者說沒必要為了嘗試而去強(qiáng)切技術(shù)棧。如此一來，割裂就產(chǎn)生了。我曾好長一段時間困在這個技術(shù)和業(yè)務(wù)二選一的局面走不出來。

等入職字節(jié)并工作了一段時間后，我發(fā)現(xiàn)當(dāng)業(yè)務(wù)形態(tài)開始變得復(fù)雜，對技術(shù)的考驗(yàn)也會隨之而來。善于運(yùn)用技術(shù)恰到好處地解決業(yè)務(wù)痛點(diǎn)，遠(yuǎn)遠(yuǎn)比單純研究技術(shù)有意義。 自嗨終究是自嗨，沒有實(shí)際落地場景，過一段時間就會忘記。如果還沒想清楚技術(shù)服務(wù)于業(yè)務(wù)這個關(guān)鍵點(diǎn)，那就會陷入【鉆研技術(shù)->長久不用->遺忘->鉆研技術(shù)】這個循環(huán)。保持技術(shù)熱情是好事，但是對于一個幾乎沒有業(yè)務(wù)落地場景的技術(shù)，投入大把時間研究又有什么用呢？知識是檢索的，當(dāng)需要時自然會朝著這個方向靠近，有具體落地場景才能更好地鞏固。

進(jìn)一步讓我體會到技術(shù)與業(yè)務(wù)是相輔相成的契機(jī)是對圖數(shù)據(jù)庫bytegraph的相關(guān)技術(shù)調(diào)研和最終的投入使用。業(yè)務(wù)場景需要，我這邊會涉及不同類型數(shù)據(jù)之間關(guān)聯(lián)關(guān)系的管理(CRUD操作)。這個關(guān)聯(lián)有層級的概念，全部關(guān)聯(lián)建立數(shù)據(jù)量已到千萬級別。從設(shè)計角度和實(shí)踐角度綜合考量，已經(jīng)不是MySQL擅長的場景。細(xì)想一下，層層關(guān)聯(lián)鋪開不就是一張圖嗎？自然是圖數(shù)據(jù)庫存儲更為合適。

在我看完bytegraph相關(guān)文檔并使用Gremlin圖數(shù)據(jù)庫語言寫了幾個符合自我預(yù)期的基礎(chǔ)語句后，突然又找回了曾經(jīng)獨(dú)自鉆研技術(shù)的快樂。在使用過程中，很自然的就和業(yè)務(wù)關(guān)聯(lián)起來了。比如如何設(shè)計點(diǎn)和邊？如何提高關(guān)聯(lián)圖查詢速度？我曾寫過一篇關(guān)于圖數(shù)據(jù)庫bytegraph介紹和基本使用的文檔，有同學(xué)在看過后就著某個具體業(yè)務(wù)場景下點(diǎn)該如何設(shè)計這個話題和我進(jìn)行了語音交流，最后我結(jié)合實(shí)際使用場景給出了有效結(jié)論，被肯定的瞬間同樣是成就感滿滿。此外，在工作中對bytegraph的使用訴求，還推動了bytegraph NodeJS SDK 的誕生。有幸成為第一個吃螃蟹的人，真的很有紀(jì)念意義。

尋求長期方案

很多時候，解決問題的方案都不止一個。絕大多數(shù)情況下，選擇臨時解決方案是最快最省力的。當(dāng)然，也不排除某些極限情況下足夠的臨時趨近于長久。但臨時終歸是臨時，這意味著中后期規(guī)劃可能會有變更，從而導(dǎo)致現(xiàn)有的方案不再適用，所以說尋求長期穩(wěn)定的解決方案才是最終目的。尤其是當(dāng)系統(tǒng)穩(wěn)定性和切換成本沖突時，更應(yīng)攻堅(jiān)克難去破局。近期完成了權(quán)限平臺相關(guān)接口的升級替換，由于歷史包袱沉重，舊的權(quán)限接口越來越不穩(wěn)定，已經(jīng)影響平臺側(cè)權(quán)限的正常使用。在這種情況下，真的是不得不換。好處還是很明顯的，雖然過程艱難，但穩(wěn)定性上確實(shí)得到了保障。

相信字節(jié)內(nèi)很多平臺都是對權(quán)限系統(tǒng)強(qiáng)依賴的，這意味著一旦權(quán)限系統(tǒng)服務(wù)出了問題，其他的下游服務(wù)都會受牽連。這種權(quán)限問題感知相當(dāng)明顯，最簡單的一個例子：為什么自己創(chuàng)建的東西在操作時提示沒權(quán)限？

為了降低權(quán)限系統(tǒng)不可用對自身業(yè)務(wù)的影響，我用redis對所有涉及權(quán)限讀數(shù)據(jù)的地方做了緩存(如用戶權(quán)限列表)。每次刷新頁面會在獲取用戶信息的同時查詢最新的權(quán)限信息，當(dāng)檢測到返回結(jié)構(gòu)非預(yù)期時，則不再更新，直接返回緩存數(shù)據(jù)。一般來說，讀權(quán)限場景比寫權(quán)限場景更多，有這樣一層緩存來兜底，還是很有價值的。

此外，為了避免自己創(chuàng)建的東西在操作時提示沒權(quán)限的尷尬局面，我進(jìn)行了業(yè)務(wù)自身數(shù)據(jù)庫優(yōu)先權(quán)限系統(tǒng)接口查詢的處理。這個很好理解，寫到自己數(shù)據(jù)庫再讀取往往比寫到權(quán)限系統(tǒng)數(shù)據(jù)庫再讀取來的方便，后者可能會有延遲。完成整體權(quán)限系統(tǒng)接口升級替換，再結(jié)合redis緩存，數(shù)據(jù)庫優(yōu)先權(quán)限系統(tǒng)接口讀取這兩個策略，在業(yè)務(wù)側(cè)整體權(quán)限穩(wěn)定性上可以看作是一個長期穩(wěn)定的方案了。

直面問題

對于一個開發(fā)來說，出現(xiàn)問題在所難免。解決問題固然重要，但是擺正心態(tài)也同樣重要。工作中基本都是多人協(xié)作開發(fā)，當(dāng)收到線上報警消息時，如果能確定和自己的某些操作有關(guān)應(yīng)及時和相關(guān)同學(xué)說明，避免其他人一同跟著排查。有句話聽起來很矛盾，但是語境還挺合適的：“我知道你很慌，但是先別慌?！?出現(xiàn)問題，排查清楚后，及時修復(fù)就好，切莫諱疾忌醫(yī)。

此外，有些問題隱藏比較深，復(fù)現(xiàn)鏈路較為隱晦，甚至可能除了開發(fā)自身，其他人幾乎不會有感知。我曾遇到過一個這樣的case,代碼寫完過了一年，也沒有人反饋，最后還是我自己在某次調(diào)試時候發(fā)現(xiàn)并修復(fù)的。隨著編碼經(jīng)驗(yàn)的積累，思維發(fā)散性也會更廣，不同階段考慮的點(diǎn)自然也有差異。沒必要過多糾結(jié)當(dāng)時為什么沒有考慮到這個場景，更應(yīng)該思量的是下次遇到類似情況如何避免。亡羊補(bǔ)牢，為時未晚。

問題排查

問題排查可以說是一個開發(fā)人員必備的能力。個人感覺保證開發(fā)永遠(yuǎn)不出bug的方式就是不去開發(fā)。當(dāng)然，這并不現(xiàn)實(shí)。在字節(jié)這兩年多的時間里，我踩過好多的坑，也出過事故，逐漸摸索出了一些問題排查的經(jīng)驗(yàn)。

環(huán)境一致性校驗(yàn)

工作中我這邊常用到的是本地環(huán)境、測試環(huán)境(boe)，生產(chǎn)預(yù)覽環(huán)境(ppe)和正式生產(chǎn)環(huán)境(prod)。每個階段都有可能會引發(fā)問題，在開始排查問題前，需要先確定自己的調(diào)試環(huán)境與引發(fā)問題的環(huán)境一致。乍一看可能感覺這句話是廢話，但是有過相關(guān)經(jīng)驗(yàn)的人都知道這一條真的很重要。

說來慚愧，我有過本地調(diào)試半天發(fā)現(xiàn)死活不生效最后意識到看的是生產(chǎn)環(huán)境頁面的尷尬經(jīng)歷，真的是又氣又無奈。

優(yōu)先保證這一點(diǎn)，能少走很多彎路。

格式一致性校驗(yàn)

格式一致性校驗(yàn)指的是確認(rèn)原始數(shù)據(jù)在有意格式處理或漏處理后，是否和后續(xù)程序要接收的數(shù)據(jù)格式保持一致。

一般來說，編碼粗心或者測試不夠充分都有可能引發(fā)格式相關(guān)的問題。

有意處理的場景：

const list=[1,2,3]
// 有意處理
const formatList =list.map(d=>({id:d
}))
// 省略一大段代碼// 此處錯誤傳入了list，應(yīng)使用formatList
getData(list)function getData(list){// do something...return xxx
}

在前端操縱數(shù)據(jù)store也有可能存在類似的問題，原始數(shù)據(jù)格式在某個組件里被修改導(dǎo)致另一個組件無法預(yù)期解析。

漏處理的場景：

// sequelize findAll查詢 限定只返回id屬性
const ids = await modelA.findAll({attributes: ['id'],
});await modelB.findAll({where: {id: ids,//這里漏掉了對ids的處理 },
});

如圖，使用了sequelize model方法中的findAll查詢并限定只返回id屬性，且變量命名為ids。

實(shí)際上，返回的結(jié)構(gòu)是對象數(shù)組{id:number}[]，而不是數(shù)字?jǐn)?shù)組number[]。

請求響應(yīng)一致性校驗(yàn)

服務(wù)里定義的路由地址和前端請求時的地址對不上，導(dǎo)致請求404。

可能是因?yàn)閱卧~拼寫錯誤：username or ursename? cornjob or cronjob? 或者cv后沒有改全。

前置條件確認(rèn)

這個偏向于涉及事件觸發(fā)的場景，要先滿足其前置條件。

下面列舉幾個有代表性的場景:

1. 如果想在群里接收某個機(jī)器人推送的消息，需要先把機(jī)器人拉進(jìn)群
2. 如果想在eventbus消費(fèi)生產(chǎn)者產(chǎn)生的數(shù)據(jù)，需要確保消費(fèi)者是開啟狀態(tài)
3. 如果想使用sdk正常解析hive數(shù)據(jù)，需要先申請表權(quán)限

分區(qū)間排查

這種方式適用于排查由程序代碼引起但尚不確定具體代碼位置的場景。

我將其劃分為三段式：

1. 給懷疑會出問題的代碼圈定一個區(qū)間，非懷疑區(qū)間代碼直接注釋(前端更有效)或return掉(后端更有效)
2. 添加相關(guān)打印并重新運(yùn)行程序，觀測輸出和程序運(yùn)行結(jié)果是否符合預(yù)期
3. 收縮區(qū)間，重復(fù)1，2步驟，直至發(fā)現(xiàn)問題

---

這里舉一個我在使用bytegraph過程中親身遇到的一個cpu暴漲的例子。

最初bytegraph并不支持全圖查詢，所以在獲取某個點(diǎn)所在的整張關(guān)聯(lián)圖譜時拆分成了以下三個步驟：

1. 查詢某個點(diǎn)在整張圖上的關(guān)聯(lián)點(diǎn)
2. 遍歷每個點(diǎn)，查詢?nèi)脒吅统鲞?/li>
3. 根據(jù)邊的指向拼出完整的圖譜

偽代碼如下：

function getGraph(vertex:Vertex){// 查詢某個點(diǎn)在整張圖上的關(guān)聯(lián)點(diǎn)const nodes=await getNodes(vertex);console.log('get nodes')// return  分割區(qū)間一，后續(xù)直接return// 遍歷每個點(diǎn)，查詢?nèi)脒吅统鲞叀?/span>const edges=await getEdges(nodes)console.log('get edges')// return  分割區(qū)間二，后續(xù)直接return // ... other
}async function getEdges(vertexs: Vertex[]) {let res: any = [];for (let i = 0; i < vertexs.length; i++) {const vertex = vertexs[i];// 根據(jù)點(diǎn)查詢?nèi)脒吅统鲞?/span>const itemEdges=await findEdge(vertex);res = [ ... res, ... itemEdges];}// return res 分割區(qū)間三，不執(zhí)行uniqWith返回res// 深度去重return uniqWith(res, isEqual);
}

采用分區(qū)間排查問題的思路，在關(guān)鍵節(jié)點(diǎn)添加打印日志，觸發(fā)調(diào)試。

查看打印信息，發(fā)現(xiàn)每次都是在獲取所有邊那里卡住。

此時可以進(jìn)到getEdges里邊查看，發(fā)現(xiàn)內(nèi)部有一個去重操作。

試著去掉這個過程，再重試，問題未復(fù)現(xiàn)。ok,定位問題。

---

針對這個問題，我寫了一個可復(fù)現(xiàn)的最小demo，感興趣的可自行嘗試。

結(jié)論是lodash的uniqWith和isEqual方法對大數(shù)據(jù) 量且重復(fù)率不高的數(shù)據(jù)進(jìn)行深度去重會導(dǎo)致cpu暴漲。

const { uniqWith, isEqual } = require('lodash');
const http = require('http');
http.createServer(async (req, res) => {const arr = [];for (let i = 0; i < 10000; i++) {arr.push({n: Math.random() * 20000,m: Math.random() * 20000,});}console.log(uniqWith(arr, isEqual));res.end('hello world');}).listen(3000);

請求溯源

對于有提供Open API 給其他業(yè)務(wù)方使用或者說當(dāng)前服務(wù)存在開放性接口(未設(shè)置權(quán)限)的情況下，都有可能存在非預(yù)期調(diào)用，其中最典型的是參數(shù)錯誤和session信息缺失。

我有過類似經(jīng)歷，某個已經(jīng)線上穩(wěn)定運(yùn)行過一段時間的接口突然開始報錯，從錯誤信息來看是參數(shù)錯誤。隨后我仔細(xì)查找了代碼里的調(diào)用點(diǎn)，只有可能在平臺使用時觸發(fā)。進(jìn)一步查看，確認(rèn)是開放性接口，沒有權(quán)限管控。意識到應(yīng)該是某個用戶手動觸發(fā)的,因?yàn)槠脚_側(cè)正常使用的請求參數(shù)符合預(yù)期。如果能定位到具體的人自然最好，如果找不到人就需要在代碼層面做一個參數(shù)校驗(yàn)，如果傳遞過來的參數(shù)不符合預(yù)期，直接return掉。類似的，平臺側(cè)調(diào)用一定可以拿到session信息，但是接連幾次報錯都是拿不到session導(dǎo)致的，懷疑是非常規(guī)調(diào)用，直接return。

安全日志記錄

我負(fù)責(zé)的工作中涉及很多底層數(shù)據(jù)，這些數(shù)據(jù)屬性變更有可能會引發(fā)非預(yù)期的安全卡點(diǎn)。開啟卡點(diǎn)的資產(chǎn)越多，類似問題感知就會越明顯。內(nèi)部定時任務(wù)，外部平臺配置變更，掃描任務(wù)，人工變更都可以導(dǎo)致資產(chǎn)屬性發(fā)生變化。因此，究竟是哪一環(huán)節(jié)發(fā)生的變更顯得尤為重要，這能有效縮短問題排查鏈路。

通過在每個變更節(jié)點(diǎn)添加一條安全日志記錄，可以有效輔助排查。此外，還可以作為業(yè)務(wù)方溯源的一個途徑。比如解答某個資產(chǎn)卡點(diǎn)什么時候開啟的？卡點(diǎn)開啟同步自哪個部門？

審查數(shù)據(jù)庫字段

在某些業(yè)務(wù)場景里會在數(shù)據(jù)庫中存儲JSON 字符串，此時需要對實(shí)際可能的JSON大小做一個預(yù)判，之后再設(shè)定與之匹配的字段類型和數(shù)據(jù)大小。否則當(dāng)實(shí)際長度超過數(shù)據(jù)庫設(shè)定字段長度時，JSON字符串就會被截斷，導(dǎo)致最后的解析環(huán)節(jié)出錯。

超時歸因

開發(fā)中遇到網(wǎng)絡(luò)超時問題太常見了，大多數(shù)情況下都可以通過添加重試機(jī)制，延長timeout的方式解決。這里我想說的是一個比較特別的場景，海外，國內(nèi)跨機(jī)房通信。 絕大多數(shù)海外和國內(nèi)的通信都是存在區(qū)域隔離的，調(diào)用不通表現(xiàn)上可能就是網(wǎng)絡(luò)超時，這種情況下，重試也沒用。解決途徑也比較直觀，要么直接避免這種情況，海外調(diào)海外，國內(nèi)調(diào)國內(nèi)，要么申請豁免。

善用工具

argos觀測診斷平臺

在問題排查上，觀測診斷平臺能起到有效的輔助作用。除了報錯日志，還可以看到所在服務(wù)psm，集群，機(jī)房。這些都是縮短問題排查鏈路的有效信息，在服務(wù)實(shí)例比較多的情況下表現(xiàn)尤為明顯。此外，還可以配置報警規(guī)則，命中后會有報警機(jī)器人進(jìn)行推送，可及時感知線上問題的發(fā)生。

飛書機(jī)器人

真心覺得飛書機(jī)器人是一個很好用的小東西。用它可以干很多事，比如按時提醒該喝水了。在報警感知上，也可以通過機(jī)器人搞點(diǎn)事情。例如在某個裝飾器里對核心接口請求地址(如包含/core/)進(jìn)行識別，隨后在catch代碼塊里捕獲錯誤，最后將error message or error stack 推送到指定的飛書群里，這樣團(tuán)隊(duì)其他成員也能及時感知。

飛書表格

個人精力有限，不可能時時刻刻盯著報警信息其他什么都不干。對于一些看起來影響不大，不用緊急修復(fù)的報警可以先通過飛書表格記錄下來，等有時間后當(dāng)成待辦事項(xiàng)逐一解決。親測，這種先收集后集中處理的方式比發(fā)現(xiàn)一個處理一個更省時間。

技術(shù)思考

規(guī)范

很長一段時間里我對技術(shù)的理解是運(yùn)用掌握的知識完成開發(fā)，僅此而已。但事實(shí)上，開發(fā)流程不應(yīng)僅局限于開發(fā)環(huán)節(jié)，還有其他很多有價值的事情需要關(guān)注,比如一些規(guī)范。團(tuán)隊(duì)協(xié)作和獨(dú)立開發(fā)還是有明顯區(qū)別的，沒有規(guī)矩不成方圓。既然是協(xié)作，就要有達(dá)成一致的規(guī)范。

我曾寫過一篇關(guān)于lint的文章并在小組內(nèi)和其他同事對齊，共同商討縮進(jìn)風(fēng)格，哪些規(guī)則要開啟，哪些規(guī)則要禁用。項(xiàng)目編碼風(fēng)格統(tǒng)一的管控實(shí)現(xiàn)上依賴husky和lint-staged,在提交代碼時進(jìn)行l(wèi)int檢測，不符合檢測規(guī)則無法提交，這樣可以有效避免個人編碼風(fēng)格差異導(dǎo)致的格式change。

在代碼提交上，由組內(nèi)另一個同學(xué)制定了git工作流規(guī)范，共同約定了不同功能分支如何命名，分支間如何檢出與合并，commit 應(yīng)該如何編寫。這種規(guī)范形成文檔后作用明顯，不論是日常開發(fā)還是線上部署，都有了更清晰的操作流程。此外，見名知意的commit message也更有助于查找具體功能點(diǎn)。試想一下，如果簡寫一個fix,或fix err ,等過段時間再看，哪里還記得到底fix了個什么？

類似的，小組內(nèi)還有需求迭代，上線部署等相關(guān)規(guī)范，這些規(guī)范站在開發(fā)的全局視角來看，都是很有價值的。

質(zhì)量

研發(fā)質(zhì)量問題是一個非常值得重視的點(diǎn)，開發(fā)完成并不意味著整個研發(fā)環(huán)節(jié)就結(jié)束了，質(zhì)量過關(guān)才是最后的收尾節(jié)點(diǎn)。簡單來說，上線后功能平穩(wěn)運(yùn)行，無bug和性能問題，這樣才算是合格。雖說百密一疏，但反復(fù)踩同樣的坑或者踩不應(yīng)該踩的坑就有些說不過去了。我印象比較深刻的踩坑點(diǎn)在于數(shù)據(jù)格式處理，這個在上文報警排查處有提到，不再贅述。還有一點(diǎn)，對于跨越大版本的sdk升級，一定要認(rèn)真且足夠詳細(xì)的審查是否存在break change。有些break change是比較隱晦的，乍一看可能察覺不到玄機(jī)，切記想當(dāng)然，在項(xiàng)目代碼中搜索看看，總比自我回憶要可信的多。想要收獲一批忠實(shí)用戶，研發(fā)質(zhì)量一定是排位比較靠前的。

穩(wěn)定性

這里特指研發(fā)的系統(tǒng)穩(wěn)定性，初期我這邊涉及到的系統(tǒng)架構(gòu)比較簡單，所有功能模塊共用一個服務(wù)。這樣好處是很多代碼可以復(fù)用，開發(fā)和上線也比較方便。禍福相依，但是一旦服務(wù)崩潰，除了影響自身業(yè)務(wù)正常使用，還會朝著下游其他業(yè)務(wù)輻射。具體表現(xiàn)上來看，一般是OEPN API不可用。為避免類似問題再發(fā)生，我和小組內(nèi)其他同事一起完成了服務(wù)架構(gòu)升級，將不同子模塊拆分成不同的服務(wù)，接口層面根據(jù)重要等級和業(yè)務(wù)類型并借助負(fù)載均衡能力，分散至各自所在服務(wù)的不同集群。架構(gòu)升級完成后，即使某個子模塊出現(xiàn)問題，也不至于牽動整個服務(wù)崩盤。在此次架構(gòu)升級中更深刻體會到了不同類型數(shù)據(jù)庫在特定場景下的使用，Redis,MySQL,MongoDB,bytegraph都有涉及，收獲頗多。

文檔先行

對于一些偏復(fù)雜的模塊，先找個文檔梳理一下，逐步拆解清楚后再開始編碼，屬于磨刀不誤砍柴工。以前我的習(xí)慣是想一個大概，然后投入開發(fā)，寫著寫著發(fā)現(xiàn)之前想錯了，然后刪掉代碼，再寫新的，這個過程可能會反復(fù)好幾次。冷靜下來好好想想，真不如先寫清楚文檔更省時省力。實(shí)測，讓思維在文檔上交鋒，遠(yuǎn)比在編輯器里打架輕松的多。

沉淀總結(jié)

我始終覺得，有輸入就應(yīng)該有輸出。不論是日?；A(chǔ)搬磚，還是攻堅(jiān)克難了某個業(yè)務(wù)痛點(diǎn)，又或者加深了自己對某項(xiàng)技術(shù)的理解，都應(yīng)該有所展現(xiàn)。并不是說非要落筆成文，但至少應(yīng)該在一個屬于自己的小天地里留些痕跡。如果實(shí)在懶得打字，不妨試試拍照式記憶。親測，這個是科學(xué)中帶有點(diǎn)玄學(xué)的方法。

先找到想要記住的畫面，可以是控制臺的數(shù)據(jù)打印，也可以是bug調(diào)試截圖，又或者某段關(guān)鍵代碼，然后想一個主題，與之進(jìn)行關(guān)聯(lián)，重復(fù)思考幾次。好的，記住了。

還是那句話，有心和無意是不一樣的。有心留意，這份記憶就會更為深刻。當(dāng)下次遇到類似場景，近乎是條件反射的思維反應(yīng)。比如我現(xiàn)在每次寫刪除語句一定會檢查是否加上了where條件。這是有特殊意義的一段經(jīng)歷，不堪回首。

落地統(tǒng)計

辛辛苦苦搬磚究竟產(chǎn)生了怎樣的價值呢？究竟有哪些人在用？這同樣是一個比較關(guān)鍵的點(diǎn)。我曾梳理了一個關(guān)于OPEN API 業(yè)務(wù)落地情況的表格，里邊記載了哪些業(yè)務(wù)方在用，什么場景下會用，對接人是誰。這樣除了價值考量，還可以在接口變更或下線時及時聯(lián)系使用方，避免造成非預(yù)期的影響。

總結(jié)

不知不覺，洋洋灑灑寫了幾千字，夢回畢業(yè)論文。曾覺得自己屬于有所成長，但是成長算不上快那種。寫完這篇文章后再回首，竟也方方面面很多點(diǎn)。不錯，經(jīng)過一番努力，終于從一棵小蔥茁壯成長為一棵參天大蔥了。

回到最初的問題上，時至今日，我仍然覺得還有很多東西要學(xué)。距離把想學(xué)的都學(xué)到，大概還有很長一段路要走。

好在這一路不算孤獨(dú)，能和身邊優(yōu)秀的人一起做有挑戰(zhàn)的事。

前方的路，仍然值得期待。

完結(jié)，撒花！