1 前言

做一下21年技術(shù)復(fù)盤，也許有不一樣的收獲。整個一年，在技術(shù)上投入相對更大一些，從小的優(yōu)化方案到具體系統(tǒng)設(shè)計，都有一些投入。那些達到目標，并且比較細小的技術(shù)實現(xiàn)，這里就不回顧了，我想復(fù)盤一些投入比較大的技術(shù)建設(shè)，因為過程中，這樣的項目會有很多問題出現(xiàn)。

2 前端監(jiān)控

自研的前端監(jiān)控一直是我自己在發(fā)力的系統(tǒng)，說實話它很有用，也一直在幫助團隊解決很多問題。但是這個系統(tǒng)也有它自己的問題。

• 上手難度大
• 投入維護成本較高
• 和團隊使用的Sentry并存，有點重復(fù)
• 利用率還不夠

2.1 上手難度大

首先因為是全棧js項目，還使用了3個數(shù)據(jù)庫，因此要在本地把項目跑起來就已經(jīng)比較麻煩了，前端同學(xué)們有全棧能力的也比較少，如果一個同事想要參與，前期需要學(xué)很多知識。

前后端功能比較多，代碼量也比較大，看代碼改代碼比較費力。客戶端采集數(shù)據(jù)的SDK，就更有難度了，很多底層的API大部分同學(xué)是不熟悉的。

在項目的迭代過程中，有投入較多精力的同事，慢慢熟悉了系統(tǒng)，可以對其中一部分功能進行開發(fā)，但是缺少全局視野。還有一部分業(yè)務(wù)繁忙的同事，本想?yún)⑴c進來，但是也是時間投入不足，而擱淺了。

現(xiàn)在這個系統(tǒng)始終只有我最了解，而且還在不停的優(yōu)化調(diào)整，因此這個項目對于團隊來說，我就是一個單點獨狼。要是我跑了，這個項目就很尷尬，但是沒有什么意外的話，我不會跑，所以這個項目還沒被領(lǐng)導(dǎo)給干死吧～

2.2 投入維護成本較高

監(jiān)控系統(tǒng)，因為收集的數(shù)據(jù)很多，因此使用的頻率是很高的，每天都有百千萬的數(shù)據(jù)存儲量。在使用過程中，性能瓶頸開始凸顯，因此花了很多時間去做優(yōu)化，還得偶爾注意一下數(shù)據(jù)的空間占用情況（我們盡可能的保障數(shù)據(jù)留存時間更長）。其它同事在使用的時候，也會提出很多建議或者他們想要某些功能，這都是成本。但這也不是壞事，有新的需求說明系統(tǒng)有使用價值。

也是由于投入成本比較高，所以我比較謹慎，有時候可能常常把它的優(yōu)先級降低，能達到80%就夠了，如果再提高到100%就會投入非常多的成本，80%能力的系統(tǒng)功能平時使用起來稍微麻煩一點點，但是也可以用的，也不是不能接受。做到極致的成本又太高了，目前大部分情況下，還是看收益性價比。

2.3 sentry 并存

雖然現(xiàn)在 Sentry 越來越強大，公司也一直在使用，配合上神策，能夠滿足公司很大一部分需求了。但依然不能覆蓋很多場景，我們自研監(jiān)控收集的數(shù)據(jù)能覆蓋的更廣，能實現(xiàn)更多的能力。而開源系統(tǒng)由于通用性設(shè)計，能力受制于開發(fā)者，并且很難再進行二次開發(fā)。

所以目前這兩個監(jiān)控都在用，這樣有點重復(fù)，也容易分散同事的精力，這是一個矛盾點。但也不是沒有好處，要是其中一個監(jiān)控SDK出了問題，另一個監(jiān)控還能監(jiān)控到，當然之前出問題的都是我們自研的SDK，所以還是利用Sentry拖個底。Sentry不能實現(xiàn)的功能，又由自研監(jiān)控拖底，目前團隊就是這樣考慮的。

2.4 利用率還不夠

之前由于性能問題和系統(tǒng)功能設(shè)計的問題，我一直沒有大力的推廣它，因為用起來有點別扭，有點慢，大家知道這個系統(tǒng)，但很多時候并沒有用起來。大部分時候，可能是我進入后臺發(fā)現(xiàn)問題再推給大家；或者是同事遇到了問題，求助于我。這個也和業(yè)務(wù)訪問量有關(guān)系，訪問量越大，功能越復(fù)雜的應(yīng)用，就越需要它，去年我們的C端項目就經(jīng)常使用監(jiān)控。

讓更多的系統(tǒng)接入，大家更加主動使用系統(tǒng)，最大化系統(tǒng)的價值，這是需要解決的問題。

2.5 問題和解決

上手難度問題:

去年我們完善了項目入門文檔，只要按照教程走，也是沒有什么問題的，技術(shù)上面要學(xué)習(xí)，好像也不可避免，但是有人能夠指導(dǎo)，也會少很多坑。單點問題，這個比較難處理，要培養(yǎng)一個熟悉這個系統(tǒng)的同事，需要對應(yīng)的同事有足夠的精力才行，明年基建小分隊里面，得選拔一個副手，并且要堅持做下去的人才行。

投入成本問題:

有需要就有投入，至于是否投入資源，這個還是采取和基建委員會協(xié)商溝通的方式，對于迭代的功能投入必要性進行討論、投票。

Sentry并存問題:

這個暫時還不是什么大問題，有另一個團隊的同事在跟著學(xué)習(xí)Sentry也是一種知識視野的補充，保持現(xiàn)狀也好。

利用率問題:

21年底性能問題和系統(tǒng)功能設(shè)計的問題，我已經(jīng)解決了很大一部分并且上線了，所以明年，在推廣上會更加的有信心。其次是把同事的體驗后的建議收集起來，進行迭代優(yōu)化，覆蓋更多需求場景。

3 前端路由重定向系統(tǒng)

這個系統(tǒng)因為是下半年提出并且設(shè)計開發(fā)的，所以還是項目初期階段，系統(tǒng)本身設(shè)計的比較合理，前期做足了功課，設(shè)計和評審都比較認真，所以目前系統(tǒng)運行和版本迭代的很穩(wěn)定，初版迭代之后自己就把項目交給另一個同事作owner。秀操作的就不說了，復(fù)盤一下系統(tǒng)的問題

• 新的owner對系統(tǒng)的把控能力還不夠
• 開發(fā)的功能被別人水了
• 系統(tǒng)使用率偏低

3.1 新的owner對系統(tǒng)的把控能力還不夠

系統(tǒng)從零到一這位同學(xué)都是一起參與的，并且由于他比較認真，所以學(xué)到了更多的知識，他自己也有獨立思考。但是現(xiàn)在想想系統(tǒng)其中還是有很多他的知識盲區(qū)，如果一旦我長期不介于其中，系統(tǒng)就會設(shè)計出問題。雖然他有主動性，但是我覺得，作為owner，他做的還不夠，每次迭代，我都是叮囑他需要做什么，考慮什么，他沒想到的我就直接給他補充了。這樣對他成長不利，也比較消耗我的精力。

所以明年，應(yīng)該對他提更高的要求，自己也應(yīng)該多提問引導(dǎo)，而不是指導(dǎo)式引導(dǎo)。

3.2 開發(fā)的功能被別人水了

系統(tǒng)在做第二次迭代的時候，NATIVE同事，希望我們能夠給他們提供管理他們（RN路由、NATIVE路由、WEB路由）路由的能力，大概功能就是通過后臺配置，他們客戶端來拉取配置，滿足動態(tài)更新。于是需求評審、技術(shù)評審我們拉著技術(shù)委員會和NATIVE同事都做了，最后也按照需求開發(fā)出了功能。結(jié)果最后他們沒有接。因為NATIVE團隊另一個后來加入的同事，使用了另一套方案。當時我也是很氣，我們投入了精力，你們說不用就不用了，而且還沒主動告知我們，我都是無意間了解到的。上去理論一番，主要是想知道原因，然后就知道了原因，當然不是我們系統(tǒng)設(shè)計的不好的問題，最后也就不了了之了，我想的是你們要用就用，開發(fā)的功能在那里，還有一部分你們沒解決的問題，后面應(yīng)該也用得到，就暫時擱淺了，不管這個事情了。感覺吃了個啞巴虧，還好這個功能的投入并沒有特別大，就先這樣吧。

現(xiàn)在復(fù)盤這個問題，我想，要不是系統(tǒng)本身前期沒設(shè)計好，就是后期改方案，沒溝通到位。目前看來是后期改方案，沒有經(jīng)過大家的討論，白白浪費人力，后期改的方案，也沒有經(jīng)過委員會的溝通，可能NATIVE團隊內(nèi)部溝通過，但是這個事情已經(jīng)牽扯到其他團隊了。我在了解到情況后，就沒有作為了，如果說浪費人力的問題要追責(zé)下來，我應(yīng)該是最大責(zé)任人。所以以后遇到這種問題，應(yīng)該還是把大家召集起來，再討論一下，而不是發(fā)現(xiàn)了問題就沒然后了。

3.2 系統(tǒng)使用率偏低

說起這個問題，我想到當初提出這個需求的同事，好像他負責(zé)的一個業(yè)務(wù)系統(tǒng)都沒接進來，倒是另一個團隊的同事開始用起來了。目前公司接入此系統(tǒng)的業(yè)務(wù)比較少，如果要找理由的話：

• 因為推廣不足，很多老的業(yè)務(wù)，沒有接入的動力（因為需要投入成本，并且沒有合適的理由和機會）
• 系統(tǒng)還是處于初期，需要有人試水
• 大部分同事都是抽時間開發(fā)的，這并不是主業(yè)，系統(tǒng)迭代比較慢、

推廣方面，我認為至少大部分同事還是知道這個事情，畢竟我們有經(jīng)過委員會討論，有做過分享。老的業(yè)務(wù)，沒有接入的動力，我覺得也是情有可原，現(xiàn)在跑的穩(wěn)定的，專門去投入改造好像也沒啥特別大用處，還容易出問題。這個問題我想其實應(yīng)該就是業(yè)務(wù)出現(xiàn)變動的時候，再來接我們項目，是合理的，理由充分的。

系統(tǒng)初期試水，這個我認為年底已經(jīng)有業(yè)務(wù)運行過兩個月了，也算試水完成了，開年可以放心使用啦。

系統(tǒng)迭代慢，說明需求沒那么緊急，之前有個迭代我們?yōu)榱藵M足業(yè)務(wù)需求，立馬作了設(shè)計并且很快開發(fā)完成，趕在業(yè)務(wù)系統(tǒng)開發(fā)前我們上線。結(jié)果后面那個業(yè)務(wù)系統(tǒng)延期了，所以我們的使用率又低了。唉，生意不好做～

最后還有那個提出需求的同事，他作為前端架構(gòu)師，當初也是考慮到其它業(yè)務(wù)需要，提出的需求。我之前有想過應(yīng)該和他一起復(fù)盤討論一下后期的接入情況，哪些系統(tǒng)需要接入（因為他對公司業(yè)務(wù)項目更熟悉），但是一直沒去做這個事情。這個事情，今天復(fù)盤下來，我覺得開年我就去找他，把這個事情先討論了。早點解決，早點讓項目走上正道！

4 公共數(shù)據(jù)圖表平臺

這個系統(tǒng)是我和一個后端同事做的，現(xiàn)在他長時間沒空寫代碼了，平臺在實現(xiàn)了幾個查詢需求之后，就沒有再怎么迭代了。這個系統(tǒng)最大的問題是沒有經(jīng)過前后端委員會討論，目前就我和2個后端同事比較熟悉，本身系統(tǒng)是挺好的，但是沒有完全發(fā)揮出能力來。也不知道，是不是還有很多應(yīng)用場景，就是需要這個系統(tǒng)，眼前是漆黑一團的，我自己視野有限，所以這個系統(tǒng)最大的問題，就是需要拉出來和大家一起審視審視。

5 NODE基建小分隊

去年，我們成立了NODE基建小分隊。通過前端路由重定向系統(tǒng)，我們找到了一個比較好的技術(shù)項目開發(fā)模式：結(jié)合每個人的精力，找個一個owner，拉取更多有興趣的小伙伴加入，同時又不給大家造成太大的負擔(dān)，前期嚴格設(shè)計、細分任務(wù)、相互分享、一起開發(fā)、達成目標。最后還能輸出演講分享。這是好的方面。

作為負責(zé)人，最大的問題，我認為還是對已有成果的文檔輸出和抽象不夠，這些也是比較費精力的事情，又因為各種原因，就是沒把該完成的收尾總結(jié)工作完成。這個事情該怎么做，誰來做，隊伍建設(shè)也不足，我的精力也有限，團隊吸納的人員較少，事情有點難以推動了。我也會考慮，團隊還有很多其它的事情要投入，我們這塊的建設(shè)實際并不應(yīng)該投入太多人力，平衡點怎么找。這樣想下來，又得拉著委員會同事討論一番了。

不久前發(fā)現(xiàn)公司還有6年前的NODE老項目，出了點問題被扒出來了，版本低到本地都跑不起來。這種項目操了重構(gòu)成本也非常高，而且有風(fēng)險。后面還是找到了bug的解決方案，于是還是先繼續(xù)掛起，讓它先跑著。這個項目早就三不管了，現(xiàn)在有了小分隊，這個項目我們得負責(zé)起來。

6 最后

基于我涉及到的主要技術(shù)項目，就此做出了一些回顧和思考。現(xiàn)在把它們拉通來看，最重要的一點發(fā)現(xiàn)還是溝通層面出現(xiàn)了問題。所有的技術(shù)立項，都需要經(jīng)過前期討論，否則容易丟失很多思考角度，做出一個半吊子產(chǎn)品。在開發(fā)完成后，還需要盡快的進行復(fù)盤。而不是說我開發(fā)完成了，我就任務(wù)完成了。開發(fā)投入了人力，后續(xù)沒有合理使用，要不就是前期設(shè)計的問題，要么就是后期運營不足。這樣沒有產(chǎn)生價值，是浪費公司的錢。對于技術(shù)能力本身而言，也可能只是學(xué)了點皮毛，沒有在后期維護迭代中獲取到更深層次的提升。