1 前言
做一下21年技術覆盤，也許有不一樣的收穫。整個一年，在技術上投入相對更大一些，從小的優化方案到具體系統設計，都有一些投入。那些達到目標，並且比較細小的技術實現，這裡就不回顧了，我想覆盤一些投入比較大的技術建設，因為過程中，這樣的專案會有很多問題出現。
2 前端監控
自研的前端監控一直是我自己在發力的系統，說實話它很有用，也一直在幫助團隊解決很多問題。但是這個系統也有它自己的問題。
- 上手難度大
- 投入維護成本較高
- 和團隊使用的Sentry並存，有點重複
- 利用率還不夠
2.1 上手難度大
首先因為是全棧js專案，還使用了3個資料庫，因此要在本地把專案跑起來就已經比較麻煩了，前端同學們有全棧能力的也比較少，如果一個同事想要參與，前期需要學很多知識。
前後端功能比較多，程式碼量也比較大，看程式碼改程式碼比較費力。客戶端採集資料的SDK，就更有難度了，很多底層的API大部分同學是不熟悉的。
在專案的迭代過程中，有投入較多精力的同事，慢慢熟悉了系統，可以對其中一部分功能進行開發，但是缺少全域性視野。還有一部分業務繁忙的同事，本想參與進來，但是也是時間投入不足，而擱淺了。
現在這個系統始終只有我最瞭解，而且還在不停的優化調整，因此這個專案對於團隊來說，我就是一個單點獨狼。要是我跑了，這個專案就很尷尬，但是沒有什麼意外的話，我不會跑，所以這個專案還沒被領導給乾死吧～
2.2 投入維護成本較高
監控系統，因為收集的資料很多，因此使用的頻率是很高的，每天都有百千萬的資料儲存量。在使用過程中，效能瓶頸開始凸顯，因此花了很多時間去做優化，還得偶爾注意一下資料的空間佔用情況（我們儘可能的保障資料留存時間更長）。其它同事在使用的時候，也會提出很多建議或者他們想要某些功能，這都是成本。但這也不是壞事，有新的需求說明系統有使用價值。
也是由於投入成本比較高，所以我比較謹慎，有時候可能常常把它的優先順序降低，能達到80%就夠了，如果再提高到100%就會投入非常多的成本，80%能力的系統功能平時使用起來稍微麻煩一點點，但是也可以用的，也不是不能接受。做到極致的成本又太高了，目前大部分情況下，還是看收益價效比。
2.3 sentry 並存
雖然現在 Sentry 越來越強大，公司也一直在使用，配合上神策，能夠滿足公司很大一部分需求了。但依然不能覆蓋很多場景，我們自研監控收集的資料能覆蓋的更廣，能實現更多的能力。而開源系統由於通用性設計，能力受制於開發者，並且很難再進行二次開發。
所以目前這兩個監控都在用，這樣有點重複，也容易分散同事的精力，這是一個矛盾點。但也不是沒有好處，要是其中一個監控SDK出了問題，另一個監控還能監控到，當然之前出問題的都是我們自研的SDK，所以還是利用Sentry拖個底。Sentry不能實現的功能，又由自研監控拖底，目前團隊就是這樣考慮的。
2.4 利用率還不夠
之前由於效能問題和系統功能設計的問題，我一直沒有大力的推廣它，因為用起來有點彆扭，有點慢，大家知道這個系統，但很多時候並沒有用起來。大部分時候，可能是我進入後臺發現問題再推給大家；或者是同事遇到了問題，求助於我。這個也和業務訪問量有關係，訪問量越大，功能越複雜的應用，就越需要它，去年我們的C端專案就經常使用監控。
讓更多的系統接入，大家更加主動使用系統，最大化系統的價值，這是需要解決的問題。
2.5 問題和解決
上手難度問題:
去年我們完善了專案入門文件，只要按照教程走，也是沒有什麼問題的，技術上面要學習，好像也不可避免，但是有人能夠指導，也會少很多坑。單點問題，這個比較難處理，要培養一個熟悉這個系統的同事，需要對應的同事有足夠的精力才行，明年基建小分隊裡面，得選拔一個副手，並且要堅持做下去的人才行。
投入成本問題:
有需要就有投入，至於是否投入資源，這個還是採取和基建委員會協商溝通的方式，對於迭代的功能投入必要性進行討論、投票。
Sentry並存問題:
這個暫時還不是什麼大問題，有另一個團隊的同事在跟著學習Sentry也是一種知識視野的補充，保持現狀也好。
利用率問題:
21年底效能問題和系統功能設計的問題，我已經解決了很大一部分並且上線了，所以明年，在推廣上會更加的有信心。其次是把同事的體驗後的建議收集起來，進行迭代優化，覆蓋更多需求場景。
3 前端路由重定向系統
這個系統因為是下半年提出並且設計開發的，所以還是專案初期階段，系統本身設計的比較合理，前期做足了功課，設計和評審都比較認真，所以目前系統執行和版本迭代的很穩定，初版迭代之後自己就把專案交給另一個同事作owner。秀操作的就不說了，覆盤一下系統的問題
- 新的owner對系統的把控能力還不夠
- 開發的功能被別人水了
- 系統使用率偏低
3.1 新的owner對系統的把控能力還不夠
系統從零到一這位同學都是一起參與的，並且由於他比較認真，所以學到了更多的知識，他自己也有獨立思考。但是現在想想系統其中還是有很多他的知識盲區，如果一旦我長期不介於其中，系統就會設計出問題。雖然他有主動性，但是我覺得，作為owner，他做的還不夠，每次迭代，我都是叮囑他需要做什麼，考慮什麼，他沒想到的我就直接給他補充了。這樣對他成長不利，也比較消耗我的精力。
所以明年，應該對他提更高的要求，自己也應該多提問引導，而不是指導式引導。
3.2 開發的功能被別人水了
系統在做第二次迭代的時候，NATIVE同事，希望我們能夠給他們提供管理他們（RN路由、NATIVE路由、WEB路由）路由的能力，大概功能就是通過後臺配置，他們客戶端來拉取配置，滿足動態更新。於是需求評審、技術評審我們拉著技術委員會和NATIVE同事都做了，最後也按照需求開發出了功能。結果最後他們沒有接。因為NATIVE團隊另一個後來加入的同事，使用了另一套方案。當時我也是很氣，我們投入了精力，你們說不用就不用了，而且還沒主動告知我們，我都是無意間瞭解到的。上去理論一番，主要是想知道原因，然後就知道了原因，當然不是我們系統設計的不好的問題，最後也就不了了之了，我想的是你們要用就用，開發的功能在那裡，還有一部分你們沒解決的問題，後面應該也用得到，就暫時擱淺了，不管這個事情了。感覺吃了個啞巴虧，還好這個功能的投入並沒有特別大，就先這樣吧。
現在覆盤這個問題，我想，要不是系統本身前期沒設計好，就是後期改方案，沒溝通到位。目前看來是後期改方案，沒有經過大家的討論，白白浪費人力，後期改的方案，也沒有經過委員會的溝通，可能NATIVE團隊內部溝通過，但是這個事情已經牽扯到其他團隊了。我在瞭解到情況後，就沒有作為了，如果說浪費人力的問題要追責下來，我應該是最大責任人。所以以後遇到這種問題，應該還是把大家召集起來，再討論一下，而不是發現了問題就沒然後了。
3.2 系統使用率偏低
說起這個問題，我想到當初提出這個需求的同事，好像他負責的一個業務系統都沒接進來，倒是另一個團隊的同事開始用起來了。目前公司接入此係統的業務比較少，如果要找理由的話：
- 因為推廣不足，很多老的業務，沒有接入的動力（因為需要投入成本，並且沒有合適的理由和機會）
- 系統還是處於初期，需要有人試水
- 大部分同事都是抽時間開發的，這並不是主業，系統迭代比較慢、
推廣方面，我認為至少大部分同事還是知道這個事情，畢竟我們有經過委員會討論，有做過分享。老的業務，沒有接入的動力，我覺得也是情有可原，現在跑的穩定的，專門去投入改造好像也沒啥特別大用處，還容易出問題。這個問題我想其實應該就是業務出現變動的時候，再來接我們專案，是合理的，理由充分的。
系統初期試水，這個我認為年底已經有業務執行過兩個月了，也算試水完成了，開年可以放心使用啦。
系統迭代慢，說明需求沒那麼緊急，之前有個迭代我們為了滿足業務需求，立馬作了設計並且很快開發完成，趕在業務系統開發前我們上線。結果後面那個業務系統延期了，所以我們的使用率又低了。唉，生意不好做～
最後還有那個提出需求的同事，他作為前端架構師，當初也是考慮到其它業務需要，提出的需求。我之前有想過應該和他一起復盤討論一下後期的接入情況，哪些系統需要接入（因為他對公司業務專案更熟悉），但是一直沒去做這個事情。這個事情，今天覆盤下來，我覺得開年我就去找他，把這個事情先討論了。早點解決，早點讓專案走上正道！
4 公共資料圖表平臺
這個系統是我和一個後端同事做的，現在他長時間沒空寫程式碼了，平臺在實現了幾個查詢需求之後，就沒有再怎麼迭代了。這個系統最大的問題是沒有經過前後端委員會討論，目前就我和2個後端同事比較熟悉，本身系統是挺好的，但是沒有完全發揮出能力來。也不知道，是不是還有很多應用場景，就是需要這個系統，眼前是漆黑一團的，我自己視野有限，所以這個系統最大的問題，就是需要拉出來和大家一起審視審視。
5 NODE基建小分隊
去年，我們成立了NODE基建小分隊。通過前端路由重定向系統，我們找到了一個比較好的技術專案開發模式：結合每個人的精力，找個一個owner，拉取更多有興趣的小夥伴加入，同時又不給大家造成太大的負擔，前期嚴格設計、細分任務、相互分享、一起開發、達成目標。最後還能輸出演講分享。這是好的方面。
作為負責人，最大的問題，我認為還是對已有成果的文件輸出和抽象不夠，這些也是比較費精力的事情，又因為各種原因，就是沒把該完成的收尾總結工作完成。這個事情該怎麼做，誰來做，隊伍建設也不足，我的精力也有限，團隊吸納的人員較少，事情有點難以推動了。我也會考慮，團隊還有很多其它的事情要投入，我們這塊的建設實際並不應該投入太多人力，平衡點怎麼找。這樣想下來，又得拉著委員會同事討論一番了。
不久前發現公司還有6年前的NODE老專案，出了點問題被扒出來了，版本低到本地都跑不起來。這種專案操了重構成本也非常高，而且有風險。後面還是找到了bug的解決方案，於是還是先繼續掛起，讓它先跑著。這個專案早就三不管了，現在有了小分隊，這個專案我們得負責起來。
6 最後
基於我涉及到的主要技術專案，就此做出了一些回顧和思考。現在把它們拉通來看，最重要的一點發現還是溝通層面出現了問題。所有的技術立項，都需要經過前期討論，否則容易丟失很多思考角度，做出一個半吊子產品。在開發完成後，還需要儘快的進行復盤。而不是說我開發完成了，我就任務完成了。開發投入了人力，後續沒有合理使用，要不就是前期設計的問題，要麼就是後期運營不足。這樣沒有產生價值，是浪費公司的錢。對於技術能力本身而言，也可能只是學了點皮毛，沒有在後期維護迭代中獲取到更深層次的提升。