前语
作为脉脉和前端技能社区的活跃分子，我比较走运的有了许多面试机会并终究一路晋级打怪如愿来到了这儿。正式入职时刻为2021年1月4日，也便是元旦后的第一个作业日。关于这一天，我形象深入。踩着2020年的尾巴接到offer,属实是过了一个高兴的元旦。不知不觉现已两年多了,细细回想起来，更多的是岁月推移，并没有回头看看现在的自己和两年前的自己有什么不同。
决议写文章记载一下还要感谢那个离任前在飞书上和我告别的老哥，他说现已学到了想学的。
那我呢？似乎还没有。
和优异的人做有挑战的事不止是简单的一句话。
在字节停留时刻越久，越是能感觉到身边人的优异，也正是这份优异推动着我不断前进。
本文将会从思想办法、问题排查、技能考虑三个方面以回忆自我生长的视角打开叙说，欢迎阅览。
思想办法
思想办法指的是看待事物的视点、办法和办法。放到作业傍边来看，我逐步探索出了几个详细的点。
作业优先级
曾很长一段时刻里，我在作业上没有故意区分优先级或许说有优先级可是区分度不是那么显着。这意味着只要不是刚好有紧迫作业处理，基本上事务方提过来的合理需求我都会第一时刻组织。不管需求巨细，也不问紧迫程度，都默认当作紧迫处理。
诚然，在交给后得到事务方必定的那一刻是有成就感的。但我逐步认识到，这真的是有点舍本求末。由于我负责的这部分作业和底层数据相关，或许许多需求直接或直接的都会找到我。事实上，结束对齐过的作业才是我更应该高优做的事，剩下时刻用来结束这些零星需求才更为合理。
起先我觉得有些小需求或许便是一两行代码的事，顺手一个分支就带上去了。但细心想想，这如同引发了蝴蝶效应。一件事仅仅结束是不行的，该有的环节要有。 开发，测验，上线，周知事务方检验。这样一个小流程走下来耗费的时刻可不仅仅是一两行代码占用的时刻可比。更何况，或许还不止一个零星需求。时不时被打断，天然就会导致原有作业组织非预期delay。
在认识到这个问题后，来自事务方的需求我会主动问一下优先级。假如不是特别紧迫的作业将不会组织在其时周期的作业计划里。此外，优先级判定上我会和事务方承认完运用场景后有自己的考虑。对接次数多了，发现有些紧迫并不是真的紧迫，仅仅单纯的性子急。后来，关于这种零星需求，我会在项目管理渠道写好描述和需求提出人，便利后续沟通。
这个记载仍是很有含义的，深感优点显着。
- 能够起到一个备忘录的效果，守时检查，提醒自己有todo要处理
- 事务方(需求提出人)或许因事务场景改变或有了其他处理方案，不再需求后续支撑
- 原事务方(需求提出人)转岗或离任，不再需求后续支撑
比及决议去做的时分，假如发现时刻间隔较久，不要急着写代码，先和事务方二次承认这个需求是否有必要持续做。试想，假如耗时耗力做完，终究约请事务方检验时分对方又反应用不到了。什么心境？那必定满脸黑人问号啊？实惨如我，曾有过这样的阅历。深感前置承仔细的很有必要，这样能有用防止打黑工的场景。
在有认识对作业优先级进行区分后，原定对齐的作业进展基本都能够得到保障。比及作业周期结束进行总结的时分，看到比较高的结束度，我觉得这份成就感更高。
ROI考量
ROI 全称为 Return On Investment，指的是投资回报率。我是在结束一个比较重要的功用模块搬迁后才更加认识到这个东西的重要性。在做数据搬迁的时分，我写脚本进行的全量搬迁。为了兼容新旧渠道的格局差异，我做了好几处的格局转化，进程中还遇到好几个bad case需求手动处理，总之并不是那么顺利。比及一切准备就绪，我开端拉群周知用户并以表格形式逐个进行运用情况的回访。结果很为难，实践运用的用户远低于历史存量用户。量少到我完全能够选用更快的手动搬迁，省去做格局转化和写脚本的时刻。
关于那些实践没人用的数据，我后来又进行了删除处理。这一波操作下来，真的投入产出比就不高了。算是吃一堑长一智吧，在对一个功用模块进行搬迁的时分，前置作业除了搞清楚历史背景，实现原理，更应该承认实践运用人群。尤其是关于一个存在年初比我入职时刻还久的功用，更应该花时刻在这个点上好好调研下。承认目标人群才好”对症下药”,这样才有或许是多人的狂欢而非仅仅是一个人单纯结束搬迁作业的孤单游玩。
有心和无意真的是两种不同的感觉。 实践上，在阅历这个作业之前我对自己研制的模块也会有许多主意。有较长一段时刻里，我脑海中冒出来的小主意会连同某个分支功用带上去，改动不大，可是或许要考虑的点会比较多。现在回想起来，大多数归于ROI比较低的。而现在，不管是事务方提出的需求仍是我自己的小主意我都会优先考虑ROI的问题。时刻是很宝贵的，在有限时刻内产生更高价值带来的成就感和自我认同感绝对是翻倍的。
技能与事务相关
在来字节前，我很喜爱花大把的时刻去研究一些自己喜爱但或许实践未必会用到或许说运用场景比较局限的东西。比方我曾跟着视频教程鼓捣过一段时刻的Angular 1.x 。其时觉得ng-xx这个指令写起来倍感别致，有种发现新大陆的小激动。也曾跟风学过一段时刻的php,被其数量巨大的内置函数所震动。等转回到事务上，发现花费大量时刻研究的东西和事务根本不沾边或许说没必要为了测验而去强切技能栈。如此一来，割裂就产生了。我曾好长一段时刻困在这个技能和事务二选一的局势走不出来。
等入职字节并作业了一段时刻后，我发现当事务形状开端变得复杂，对技能的考验也会随之而来。长于运用技能恰到优点地处理事务痛点，远远比单纯研究技能有含义。 自嗨终究是自嗨，没有实践落地场景，过一段时刻就会忘记。假如还没想清楚技能服务于事务这个要害点，那就会堕入【研究技能->持久不必->遗忘->研究技能】这个循环。保持技能热情是功德，可是关于一个几乎没有事务落地场景的技能，投入大把时刻研究又有什么用呢？常识是检索的，当需求时天然会朝着这个方向靠近，有详细落地场景才干更好地巩固。
进一步让我体会到技能与事务是相辅相成的契机是对图数据库bytegraph的相关技能调研和终究的投入运用。事务场景需求，我这边会触及不同类型数据之间相相关系的管理(CRUD操作)。这个相关有层级的概念，全部相关建立数据量已到千万等级。从规划视点和实践视点归纳考量，现已不是MySQL拿手的场景。细想一下，层层相关铺开不便是一张图吗？天然是图数据库存储更为适宜。
在我看完bytegraph相关文档并运用Gremlin图数据库言语写了几个符合自我预期的基础句子后，忽然又找回了从前单独研究技能的高兴。在运用进程中，很天然的就和事务相关起来了。比方怎么规划点和边？怎么提高相关图查询速度？我曾写过一篇关于图数据库bytegraph介绍和基本运用的文档，有同学在看过后就着某个详细事务场景下点该怎么规划这个话题和我进行了语音沟通，终究我结合实践运用场景给出了有用定论，被必定的瞬间同样是成就感满满。此外，在作业中对bytegraph的运用诉求，还推动了bytegraph NodeJS SDK 的诞生。有幸成为第一个吃螃蟹的人，真的很有纪念含义。
寻求长时间方案
许多时分，处理问题的方案都不止一个。绝大多数情况下，选择暂时处理方案是最快最省力的。当然，也不排除某些极限情况下满足的暂时趋近于持久。但暂时终归是暂时，这意味着中后期规划或许会有改变，从而导致现有的方案不再适用，所以说寻求长时间安稳的处理方案才是终究意图。尤其是当体系安稳性和切换本钱抵触时，更应攻坚克难去破局。近期结束了权限渠道相关接口的晋级替换，由于历史包袱沉重，旧的权限接口越来越不安稳，现已影响渠道侧权限的正常运用。在这种情况下，真的是不得不换。优点仍是很显着的，尽管进程困难，但安稳性上的确得到了保障。
信任字节内许多渠道都是对权限体系强依靠的，这意味着一旦权限体系服务出了问题，其他的下流服务都会受牵连。这种权限问题感知相当显着，最简单的一个比方：为什么自己创立的东西在操作时提示没权限？
为了降低权限体系不可用对本身事务的影响，我用redis对所有触及权限读数据的地方做了缓存(如用户权限列表)。每次改写页面会在获取用户信息的同时查询最新的权限信息，当检测到回来结构非预期时，则不再更新，直接回来缓存数据。一般来说，读权限场景比写权限场景更多，有这样一层缓存来兜底，仍是很有价值的。
此外，为了防止自己创立的东西在操作时提示没权限的为难局势，我进行了事务本身数据库优先权限体系接口查询的处理。这个很好理解，写到自己数据库再读取往往比写到权限体系数据库再读取来的便利，后者或许会有延迟。结束全体权限体系接口晋级替换，再结合redis缓存，数据库优先权限体系接口读取这两个策略，在事务侧全体权限安稳性上能够看作是一个长时间安稳的方案了。
直面问题
关于一个开发来说，出现问题在所难免。处理问题固然重要，可是摆正心态也同样重要。作业中基本都是多人协作开发，当收到线上报警音讯时，假如能承认和自己的某些操作有关应及时和相关同学阐明，防止其他人一同跟着排查。有句话听起来很对立，可是语境还挺适宜的：”我知道你很慌，可是先别慌。” 出现问题，排查清楚后，及时修正就好，切莫文过饰非。
此外，有些问题隐藏比较深，复现链路较为隐晦，甚至或许除了开发本身，其他人几乎不会有感知。我曾遇到过一个这样的case,代码写完过了一年，也没有人反应，终究仍是我自己在某次调试时分发现并修正的。随着编码经验的积累，思想发散性也会更广，不同阶段考虑的点天然也有差异。没必要过多纠结其时为什么没有考虑到这个场景，更应该思量的是下次遇到相似情况怎么防止。亡羊补牢，为时未晚。
问题排查
问题排查能够说是一个开发人员必备的才能。个人感觉确保开发永远不出bug的办法便是不去开发。当然，这并不现实。在字节这两年多的时刻里，我踩过好多的坑，也出过事端，逐步探索出了一些问题排查的经验。
环境共同性校验
作业中我这边常用到的是本地环境、测验环境(boe)，出产预览环境(ppe)和正式出产环境(prod)。每个阶段都有或许会引发问题，在开端排查问题前，需求先承认自己的调试环境与引发问题的环境共同。乍一看或许感觉这句话是废话，可是有过相关经验的人都知道这一条真的很重要。
说来惭愧，我有过本地调试半响发现死活不生效终究认识到看的是出产环境页面的为难阅历，真的是又气又无奈。
优先确保这一点，能少走许多弯路。
格局共同性校验
格局共同性校验指的是承认原始数据在有意格局处理或漏处理后，是否和后续程序要接收的数据格局保持共同。
一般来说，编码大意或许测验不行充分都有或许引发格局相关的问题。
有意处理的场景：
const list=[1,2,3]
// 有意处理
const formatList =list.map(d=>({
id:d
}))
// 省略一大段代码
// 此处错误传入了list，应运用formatList
getData(list)
function getData(list){
// do something...
return xxx
}
在前端操作数据store也有或许存在相似的问题，原始数据格局在某个组件里被修正导致另一个组件无法预期解析。
漏处理的场景：
// sequelize findAll查询 限制只回来id属性
const ids = await modelA.findAll({
attributes: ['id'],
});
await modelB.findAll({
where: {
id: ids,//这儿漏掉了对ids的处理
},
});
如图，运用了sequelize model办法中的findAll查询并限制只回来id属性，且变量命名为ids。
实践上，回来的结构是对象数组{id:number}[]，而不是数字数组number[]。
恳求响应共同性校验
服务里界说的路由地址和前端恳求时的地址对不上，导致恳求404。
或许是由于单词拼写错误：username or ursename? cornjob or cronjob? 或许cv后没有改全。
前置条件承认
这个倾向于触及工作触发的场景，要先满足其前置条件。
下面列举几个有代表性的场景:
- 假如想在群里接收某个机器人推送的音讯，需求先把机器人拉进群
- 假如想在eventbus消费出产者产生的数据，需求确保顾客是敞开状态
- 假如想运用sdk正常解析hive数据，需求先申请表权限
分区间排查
这种办法适用于排查由程序代码引起但尚不承认详细代码方位的场景。
我将其区分为三段式：
- 给置疑会出问题的代码圈定一个区间，非置疑区间代码直接注释(前端更有用)或return掉(后端更有用)
- 增加相关打印并从头运转程序，观测输出和程序运转结果是否符合预期
- 缩短区间，重复1，2进程，直至发现问题
这儿举一个我在运用bytegraph进程中亲身遇到的一个cpu暴涨的比方。
开始bytegraph并不支撑全图查询，所以在获取某个点地点的整张相关图谱时拆分成了以下三个进程：
- 查询某个点在整张图上的相关点
- 遍历每个点，查询入边和出边
- 根据边的指向拼出完好的图谱
伪代码如下：
function getGraph(vertex:Vertex){
// 查询某个点在整张图上的相关点
const nodes=await getNodes(vertex);
console.log('get nodes')
// return 切割区间一，后续直接return
// 遍历每个点，查询入边和出边。
const edges=await getEdges(nodes)
console.log('get edges')
// return 切割区间二，后续直接return
// ... other
}
async function getEdges(vertexs: Vertex[]) {
let res: any = [];
for (let i = 0; i < vertexs.length; i++) {
const vertex = vertexs[i];
// 根据点查询入边和出边
const itemEdges=await findEdge(vertex);
res = [ ... res, ... itemEdges];
}
// return res 切割区间三，不执行uniqWith回来res
// 深度去重
return uniqWith(res, isEqual);
}
选用分区间排查问题的思路，在要害节点增加打印日志，触发调试。
检查打印信息，发现每次都是在获取所有边那里卡住。
此刻能够进到getEdges里面检查，发现内部有一个去重操作。
试着去掉这个进程，再重试，问题未复现。ok,定位问题。
针对这个问题，我写了一个可复现的最小demo，感兴趣的可自行测验。
定论是lodash的uniqWith和isEqual办法对大数据 量且重复率不高的数据进行深度去重会导致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 给其他事务方运用或许说其时服务存在开放性接口(未设置权限)的情况下，都有或许存在非预期调用，其中最典型的是参数错误和session信息缺失。
我有过相似阅历，某个现已线上安稳运转过一段时刻的接口忽然开端报错，从错误信息来看是参数错误。随后我细心查找了代码里的调用点，只有或许在渠道运用时触发。进一步检查，承认是开放性接口，没有权限管控。认识到应该是某个用户手动触发的,由于渠道侧正常运用的恳求参数符合预期。假如能定位到详细的人天然最好，假如找不到人就需求在代码层面做一个参数校验，假如传递过来的参数不符合预期，直接return掉。相似的，渠道侧调用必定能够拿到session信息，可是连续几回报错都是拿不到session导致的，置疑是非惯例调用，直接return。
安全日志记载
我负责的作业中触及许多底层数据，这些数据属性改变有或许会引发非预期的安全卡点。敞开卡点的财物越多，相似问题感知就会越显着。内部守时使命，外部渠道装备改变，扫描使命，人工改变都能够导致财物属性产生变化。因此，终究是哪一环节产生的改变显得尤为重要，这能有用缩短问题排查链路。
通过在每个改变节点增加一条安全日志记载，能够有用辅助排查。此外，还能够作为事务方溯源的一个途径。比方回答某个财物卡点什么时分敞开的？卡点敞开同步自哪个部分？
检查数据库字段
在某些事务场景里会在数据库中存储JSON 字符串，此刻需求对实践或许的JSON巨细做一个预判，之后再设定与之匹配的字段类型和数据巨细。不然当实践长度超过数据库设定字段长度时，JSON字符串就会被切断，导致终究的解析环节出错。
超时归因
开发中遇到网络超时问题太常见了，大多数情况下都能够通过增加重试机制，延长timeout的办法处理。这儿我想说的是一个比较特别的场景，海外，国内跨机房通讯。 绝大多数海外和国内的通讯都是存在区域隔离的，调用不通体现上或许便是网络超时，这种情况下，重试也没用。处理途径也比较直观，要么直接防止这种情况，海外调海外，国内调国内，要么申请豁免。
善用东西
argos观测诊断渠道
在问题排查上，观测诊断渠道能起到有用的辅助效果。除了报错日志，还能够看到地点服务psm，集群，机房。这些都是缩短问题排查链路的有用信息，在服务实例比较多的情况下体现尤为显着。此外，还能够装备报警规则，射中后会有报警机器人进行推送，可及时感知线上问题的产生。
飞书机器人
诚心觉得飞书机器人是一个很好用的小东西。用它能够干许多事，比方准时提醒该喝水了。在报警感知上，也能够通过机器人搞点作业。例如在某个装饰器里对核心接口恳求地址(如包括/core/)进行识别，随后在catch代码块里捕获错误，终究将error message or error stack 推送到指定的飞书群里，这样团队其他成员也能及时感知。
飞书表格
个人精力有限，不或许时时刻刻盯着报警信息其他什么都不干。关于一些看起来影响不大，不必紧迫修正的报警能够先通过飞书表格记载下来，等有时刻后当成待办事项逐一处理。亲测，这种先搜集后集中处理的办法比发现一个处理一个更省时刻。
技能考虑
标准
很长一段时刻里我对技能的理解是运用把握的常识结束开发，仅此而已。但事实上，开发流程不该仅局限于开发环节，还有其他许多有价值的作业需求重视,比方一些标准。团队协作和独立开发仍是有显着差异的，没有规矩不成方圆。既然是协作，就要有达成共同的标准。
我曾写过一篇关于lint的文章并在小组内和其他搭档对齐，共同商讨缩进风格，哪些规则要敞开，哪些规则要禁用。项目编码风格一致的管控实现上依靠husky和lint-staged,在提交代码时进行lint检测，不符合检测规则无法提交，这样能够有用防止个人编码风格差异导致的格局change。
在代码提交上，由组内另一个同学制定了git作业流标准，共同约好了不同功用分支怎么命名，分支间怎么检出与兼并，commit 应该怎么编写。这种标准构成文档后效果显着，不管是日常开发仍是线上布置，都有了更清晰的操作流程。此外，见名知意的commit message也更有助于查找详细功用点。试想一下，假如简写一个fix,或fix err ,等过段时刻再看，哪里还记得终究fix了个什么？
相似的，小组内还有需求迭代，上线布置等相关标准，这些标准站在开发的大局视角来看，都是很有价值的。
质量
研制质量问题是一个十分值得重视的点，开发结束并不意味着整个研制环节就结束了，质量过关才是终究的收尾节点。简单来说，上线后功用平稳运转，无bug和性能问题，这样才算是合格。虽然百密一疏，但重复踩同样的坑或许踩不该该踩的坑就有些说不过去了。我形象比较深入的踩坑点在于数据格局处理，这个在上文报警排查办有提到，不再赘述。还有一点，关于跨越大版别的sdk晋级，必定要仔细且满足详细的检查是否存在break change。有些break change是比较隐晦的，乍一看或许察觉不到玄机，牢记想当然，在项目代码中查找看看，总比自我回忆要可信的多。想要收成一批忠诚用户，研制质量必定是排位比较靠前的。
安稳性
这儿特指研制的体系安稳性，初期我这边触及到的体系架构比较简单，所有功用模块共用一个服务。这样优点是许多代码能够复用，开发和上线也比较便利。祸福相依，可是一旦服务溃散，除了影响本身事务正常运用，还会朝着下流其他事务辐射。详细体现上来看，一般是OEPN API不可用。为防止相似问题再产生，我和小组内其他搭档一起结束了服务架构晋级，将不同子模块拆分成不同的服务，接口层面根据重要等级和事务类型并借助负载均衡才能，涣散至各自地点服务的不同集群。架构晋级结束后，即使某个子模块出现问题，也不至于牵动整个服务崩盘。在此次架构晋级中更深入体会到了不同类型数据库在特定场景下的运用，Redis,MySQL,MongoDB,bytegraph都有触及，收成颇多。
文档先行
关于一些偏复杂的模块，先找个文档梳理一下，逐步拆解清楚后再开端编码，归于磨刀不误砍柴工。曾经我的习惯是想一个大约，然后投入开发，写着写着发现之前想错了，然后删掉代码，再写新的，这个进程或许会重复好几回。冷静下来好好想想，真不如先写清楚文档更省时省力。实测，让思想在文档上比武，远比在编辑器里打架轻松的多。
沉淀总结
我始终觉得，有输入就应该有输出。不管是日常基础搬砖，仍是攻坚克难了某个事务痛点，又或许加深了自己对某项技能的理解，都应该有所展现。并不是说非要落笔成文，但至少应该在一个归于自己的小天地里留些痕迹。假如实在懒得打字，无妨试试摄影式回忆。亲测，这个是科学中带有点形而上学的办法。
先找到想要记住的画面，能够是控制台的数据打印，也能够是bug调试截图，又或许某段要害代码，然后想一个主题，与之进行相关，重复考虑几回。好的，记住了。
仍是那句话，有心和无意是不一样的。有心留意，这份回忆就会更为深入。当下次遇到相似场景，近乎是条件反射的思想反应。比方我现在每次写删除句子必定会检查是否加上了where条件。这是有特殊含义的一段阅历，不堪回首。
落地统计
辛辛苦苦搬砖终究产生了怎样的价值呢？终究有哪些人在用？这同样是一个比较要害的点。我曾梳理了一个关于OPEN API 事务落地情况的表格，里面记载了哪些事务方在用，什么场景下会用，对接人是谁。这样除了价值考量，还能够在接口改变或下线时及时联系运用方，防止形成非预期的影响。
总结
不知不觉，洋洋洒洒写了几千字，梦回毕业论文。曾觉得自己归于有所生长，可是生长算不上快那种。写完这篇文章后再回首，竟也方方面面许多点。不错，通过一番努力，总算从一棵小葱茁壮生长为一棵参天大葱了。
回到开始的问题上，时至今日，我依然觉得还有许多东西要学。间隔把想学的都学到，大约还有很长一段路要走。
好在这一路不算孤单，能和身边优异的人一起做有挑战的事。
前方的路，依然值得等待。
结束，撒花！
