前言

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

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

那我呢？似乎還沒有。

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

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

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

思維方式

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

工作優(yōu)先級

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

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

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

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

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

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

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

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

ROI考量

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

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

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

技術與業(yè)務關聯(lián)

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

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

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

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

尋求長期方案

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

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

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

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

直面問題

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

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

問題排查

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

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

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

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

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

格式一致性校驗

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

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

有意處理的場景：

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

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

漏處理的場景：

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

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

實際上，返回的結(jié)構是對象數(shù)組{id:number}[]，而不是數(shù)字數(shù)組number[]。

請求響應一致性校驗

服務里定義的路由地址和前端請求時的地址對不上，導致請求404。

可能是因為單詞拼寫錯誤：username or ursename? cornjob or cronjob? 或者cv后沒有改全。

前置條件確認

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

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

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

分區(qū)間排查

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

我將其劃分為三段式：

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

---

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

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

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

偽代碼如下：

function getGraph(vertex:Vertex){// 查詢某個點在整張圖上的關聯(lián)點const nodes=await getNodes(vertex);console.log('get nodes')// return  分割區(qū)間一，后續(xù)直接return// 遍歷每個點，查詢?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ù)點查詢?nèi)脒吅统鲞?/span>const itemEdges=await findEdge(vertex);res = [ ... res, ... itemEdges];}// return res 分割區(qū)間三，不執(zhí)行uniqWith返回res// 深度去重return uniqWith(res, isEqual);
}

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

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

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

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

---

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

結(jié)論是lodash的uniqWith和isEqual方法對大數(shù)據(jù) 量且重復率不高的數(shù)據(jù)進行深度去重會導致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è)務方使用或者說當前服務存在開放性接口(未設置權限)的情況下，都有可能存在非預期調(diào)用，其中最典型的是參數(shù)錯誤和session信息缺失。

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

安全日志記錄

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

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

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

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

超時歸因

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

善用工具

argos觀測診斷平臺

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

飛書機器人

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

飛書表格

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

技術思考

規(guī)范

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

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

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

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

質(zhì)量

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

穩(wěn)定性

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

文檔先行

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

沉淀總結(jié)

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

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

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

落地統(tǒng)計

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

總結(jié)

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

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

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

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

完結(jié)，撒花！