带团队后的平常（三）

1、平常问题

1）BUG反馈

　　参与制订业务方的BUG规范，业务方最近投诉咱们技术部，在飞书群中提出BUG后，技术部没有人响应，认为咱们的态度太冷漠。

　　后面我就提出任何看到的人，只要知道是谁负责的，就@那我的，你们都不要客气，这是第一步。

　　第二步就是业务方建条BUG单，方便以后的追踪和回溯，固然，若是条件不容许或者不会建，那就让测试组的人建立单子。

　　后面其余人补充了第三步，那就是测试组的人会检查这条单子是否重复，若重复就直接关闭。

　　我感受这个流程中有个瓶颈，那就是测试组的人须要关注着BUG单，须要损耗一点他们组的人力。

2）量化效率

　　常常会收到各种Web需求的优化，改完测试完后就上线，一套流水线，咱们只是其中的一环。

　　虽然咱们知道这是用来提高他们效率的，可是没法直接量化提高的效率，这是我最近在思考的问题。

　　量化后，就能知道本身为他们的工做带来的多大的价值，其实也能够提高咱们的工做积极性和参与度。

　　通过验证后，发现能够经过以前搭建的监控系统的通讯和点击日志，来一步步地计算出耗时，而经过优化先后的两个耗时，就能得出效率值。

　　固然，并非全部的效率提高都能计算出来，还有不少须要业务方的反馈才能获得。

3）协调人

　　当须要多端联合解决问题时，若是没有协调人从中穿针引线，强力push的话，那么问题解决将会异常缓慢、效率低下。当无人主动承担时，可由本身担任。

　　这两天客服反馈用户充值后，虚拟币没有到帐，因而查看后台发现是不少是未支付状态，联系财务进入第三方支付后台，导出已支付订单。

　　将两边导出的数据作Excel比对，筛选出了50多张有问题的订单。发现订单在特定的时间段内（0点~6点之间）出现了问题，根据以前画的一张问题画像大体能够推断出是第三库的问题。

　　因而在日志中搜索他们要回调的接口，发如今那段时间里一条都没有。立刻再去联系那边的商务，将问题抛给他们。

　　这里必须得吐槽下他们的工做效率实在过低，12点50分反馈，一直到17点才说是总部系统问题，期间还得打电话给他们催促。

　　那只能咱们自救了，联系客服咨询补单流程，再去查看补单以及审核的代码。而且查看回调接口的逻辑，以避免二次补发。

　　一切就绪后，和财务一块儿整理补单须要的数据，再联系当时的运营（他也充值了没收到虚拟币），测试一条，一切正常后，再让客服和财务处理剩余的问题订单。

　　这样来来回回，也搞了大概一天的时间。

4）控制需求

　　控制需求并非为了逃避责任，偏偏是为了更好地尽责，好钢用在刀刃上。

　　最近接到一个需求，是在隐私条款更新后，要在APP中弹个框告诉用户。那么这里就会涉及三端：客户端、服务端和前端。业务方但愿能在后台开放一个可视化页面供他们操做，服务端但愿由咱们提供数据的写入，他们直接读取（咱们组有操控数据库的权限）。客户端经过读取服务端的接口来作相应地提示。

　　理想状况下是作一张为此功能服务的新页面，但状况并不理想。须要控制下需求，功能要作，但实现方式须要商量，并且要给出明确的解释。

1. 衡量后认为作新页面的性价比过低，不只功能太单一，并且还要作两套（服务两个APP）。在目前的管理后台中有不少这样服务某个功能而已经废弃的页面，其实彻底能够先预判一下，值不值得作或者有什么更合适的替代方案。
2. 目前的人力资源捉襟见肘，优先级很高的需求正在进行中，若作新页面，时间成本咱们没法负担。
3. 那些页面被废弃除了公司的客观缘由以外，还有人为缘由，新来的运营都不知道有这些功能，长此以往就用其余方式替代了，他们的交接有严重的问题。
4. 在后台为了应付这类动态配置，开发了一套通用配置系统，能够在此处配置参数，这是一段JSON格式的数据，对运营并不友好。由于更新不会频繁，因此若要更新数据，可由测试、产品或咱们组的人代劳。
5. 服务端若不想读取咱们的数据库，则能够提供内部接口，帮他们读取。亦或者他们本身读库，缓存起来。

　　由通用配置来实现该需求是一个折中的方案，既能维持咱们本身的开发进度，也不会影响产品的发版。综合考量后，决定采起此方案，固然在实际使用中还会碰到些问题，这些都好解决。

　　在项目的开发中会碰到不少这样的场景，并且我相信基本上开发时间人力资源都会很紧张。为了让本身不被动，须要想办法控制住需求，控制的方式有多种，例如提早未雨绸缪实现可复用的技术方案和系统，分析出需求存在的矛盾点引导产品顺着本身的思路走，让出现冲突的业务方本身PK先作胜的那方需求。

5）沟通细节

　　在跨组联调以前必定要沟通好细节，不能粗粗的一过。要细到数据库表的一个字段都没有歧义，不然很容易会在阴沟里翻船。

　　以前要作一个加密音频的功能，客户端播放加密的音频文件，服务端将这些文件下发给客户端，后台管理系统将原始音频上传到加密平台。

　　在一开始的会议时讨论的方案是从咱们这边拿到加密后的文件地址，而后再更新数据库表的一个新字段，服务端读取此字段，最后下发给客户端。

　　可是中途他们的实现方案发生了改变，没有通知到我这边（信息不对称），致使在发生联调时数据不匹配。

　　我在中途也想固然的觉得更新加密地址就行，没有对清楚需求。好在，服务端须要的数据在个人代码中已经读取到，只要换个参数就能完成联调。不过下次真的是要好好捋一捋了。

　　通过此次事件后，团队协做规范中也要补充一条确认细节，以避免再次发生这类失误。

2、工做优化

1）Node服务升级

　　Node服务升级失败，原本想从 v8升级到 v10，但出现一个时区问题，没法解决，只得回退，原本打算用代理转发的方式，后来想一想这样太绕了，不必。

　　因而新建一个项目，分配独立域名，运用TS语言，依托框架 egg.js，它的优点包括：

• 基于KOA，定制上层框架的能力。
• 按照约定进行开发，奉行『约定优于配置』，团队协做成本低。
• 稳定，功能完善，文档齐全，适合多种场景。
• 支持TypeScript，提供了应用层开发规范，有了强类型约束和静态检查，能够下降软件腐化的速度。
• 支持代码的声明索引，不用再经过项目搜索来查找变量或方法的声明处了。
• 让成员使用新技术新语法的，开辟新的成长空间，并与当前主流接轨。

　　具体迁移步骤包括：

• 引入JWT（egg-jwt），自定义JWT验证中间件。
• MySQL，MongoDB，Redis的链接和配置，引入egg专用插件，egg-sequelize，egg-mongoose和egg-redis。
• 日志的配置，包括自定义的请求日志，数据库查询语句日志（包括MySQL和MongoDB），内部请求通讯日志。
• 将config目录中的文件所有上传到配置服务器中，保留 config.default.ts、config.{env}.ts和plugin.ts文件。
• 在服务器中部署时须要先将TS文件编译成JS文件，再执行start命令，而且传递环境参数。
• 当sequelize版本6以上时，要求MySQL最低版本得是5.7，但目前线上的版本都是5.6，所以没法更改，得想办法将egg-sequelize降配。
• 在部署Node性能监控平台的时候也遇到了点麻烦，搜集不到监控数据，主要是运维配置的问题，前先后后搞了好几天。

2）问题画像图

　　将问题和技术点经过一张图联系起来，可快速而有序地定位到问题的出处。

　　统计每周遇到的BUG，浏览公司的BUG单平台，再将BUG抽象成问题画像图，按照“问题 --> 平台 --> 技术点”的方式梳理。

　　Web端的不少业务都是各种短时间活动，并不是阶段性的，所以在提炼的时候比较难以抽象共性，不少问题不具表明性。

　　下图是通过整理后的问题画像图。

　　

　　例如遇到页面空白，那有多是JSON.parse()数据解析遇到了问题，也多是语法编译后浏览器不支持，亦或者是接口504了得不到渲染数据等等。

　　最后推荐一款开源的办公软件：LibreOffice，支持PPT、Word、Draw，本次的图就是用该软件制做的，它也支持各个平台，包括mac、windows和linux。

3）疑难杂症

　　为每一个项目增长疑难杂症的wiki，记录花费了不少时间修复或常见问题的排查过程。

　　目的是在下次遇到时，不用再重头开始，减小修复时间，提高工做效率。既能间接地补充文档，也能梳理旧逻辑。

　　像以前的那些充值问题，就能够记录在案，下次遇到相似问题，均可以此为参考。

　　在休息时间，线上遇到BUG，若找不到相关人员或相关人员不方便操做电脑，那么就能让其余人员按照记录的排查步骤，一步步地修复，尽可能作到一个问题可多人修复。

4）先后端分离

　　这是我进公司后一直在推动的一件事，可是得不到服务端的支持，因此一直搁置着。最近遇到个站内信发送的问题，才将此问题又提上了日程。

　　目前服务端与咱们组分工的职责界线很模糊，很容易发生冲突，因此我才一直致力于先后端分离。

　　咱们组维护着一个比较庞大的管理后台，它链接的数据库多达8个，但其中只有一个MySQL和MongoDB才是咱们组维护的，其余都是与业务相关的数据库。

　　个人设想是除了本身维护的系统以外，其余逻辑都应经过调用接口的方式与后端交互（包括增删改查），咱们组须要与服务端的数据库表以及缓存作隔离。

　　前端监控系统，开发者工具，后台帐户管理等是咱们组的自有系统，仍然由咱们来维护。

　　讨论后的方案：

• 将来管理后台数据请求直接走服务端接口，服务端提供一个新的跨域域名。
• 保留管理后台的鉴权和权限功能，在登陆时将用户的权限传输给服务端。
• 服务端的鉴权和权限验证与当前保持一致。
• 日志保存在MongoDB中，需将其与服务端隔离，开放操做日志接口，供服务端调用，统一日志格式。

　　H5活动会走一个Node.js提供的中间层服务，经过它再调用服务端接口。

　　主流的先后端分离是前端只作页面交互，数据处理全由服务端提供接口，目前在咱们公司有不少现实问题使得难以这么搞。

　　折中的方案是咱们本身维护Node中间层，业务数据从服务端读取。但若是是一个大活动，会有很大并发量的，那么就不走中间层，所有读取服务端接口。

　　讨论后的方案：

• 将来仍是要走分离线路，但目前服务端对活动这块仍是空白，须要有个搭建过程。
• 先从几个小活动开始，尝试着分离，稳步前进。

5）单元测试

　　在公司的几个项目中，其实早就将单元测试的环境搭建完成，但一直没有启用。

　　不作的理由一大堆，诸如：接口就是简单的增删改查，让测试组作功能测试就好了；工期太紧，来不及作；异步通讯须要有后台接口等。

　　后面读了篇专栏才了解到，单元测试是不须要依赖外部服务的，也就是说不须要链接数据库，调用内部接口、读取本地文件等。

　　借助单元测试框架库（例如sinon.js），可以模拟出那部分外部服务，从而就能完成各个功能的单元测试。

　　结合当前项目的实际状况，我并不要求组内成员覆盖率达到一个数字，只须要对那些比较核心和复杂的业务逻辑加上单元测试便可。

　　我在使用时，会修改源码，让源码更容易测试，以函数或方法做为一个单元，在测试的过程当中，发现了些潜在的问题，并当场修复，免得测试的时候出现而返工。

6）Code Review

　　虽然每周都会开个周会，但Code Review还从未作过，根本缘由仍是由于没有认识到Code Review的价值。

　　最近有个比较重要的年中活动，因此在提测以前先作了简单的Code Review。

　　在这个过程当中纠正了一些影响思路和视觉的写法，例如 if 的一个判断分支要一百多行，另外一个分支就两行，那能够将短的分支移到上面加个 return，长分支转移到后面便可。

　　还找到了几个联调错误，避免在测试阶段才发现，形成没必要要的返工，影响测试进度。

7）B计划

　　软件的风险管理是必需要考虑的，在项目的开发阶段，就要提早考虑线上出现情况时的B计划，未雨绸缪，防患于将来。

　　例如定时任务中会计算榜单，当计算出现错误时，该如何快速恢复榜单数据？补救措施是提早备好脚本，在后台管理系统中留执行该脚本的入口。

　　还例如会员充值从银联支付替换为微信公众号支付，在试运行期间须要保留一个能够在二者之间切换的开关，当出现问题时，可快速应对。