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 最后

基于我涉及到的主要技术项目，就此做出了一些回顾和思考。现在把它们拉通来看，最重要的一点发现还是沟通层面出现了问题。所有的技术立项，都需要经过前期讨论，否则容易丢失很多思考角度，做出一个半吊子产品。在开发完成后，还需要尽快的进行复盘。而不是说我开发完成了，我就任务完成了。开发投入了人力，后续没有合理使用，要不就是前期设计的问题，要么就是后期运营不足。这样没有产生价值，是浪费公司的钱。对于技术能力本身而言，也可能只是学了点皮毛，没有在后期维护迭代中获取到更深层次的提升。