一、日常问题
1）陈年接口调试的噩梦
最近被插入了一个需求，我们组经常会被插入各式各样的需求，因为之前负责的范围非常广。
这次的需求就和一个陈年接口有关，其实要修改的地方并不多，就是为一个请求多加一个参数。
但是比较麻烦的地方就是验证阶段，就是我在加上这个字段后，我得知道发请求的时候真的带上了。
根据URL地址反查到了页面代码，在本地启动项目，访问页面，直接报错。
调试陈年项目，这种情况是经常发生的，涉及的问题很多，例如内部接口不通了，数据库表结构变了，需要的数据记录本地没有等等。
像这次我只是想验证下参数是否发送成功，并不会涉及到内部逻辑的修改，那么只要写死一段假数据绕过那些业务逻辑就能跑通。
但要得到数据结构也不容易，因为之前没有相关资料，只能通过错误提示一个字段一个字段的加，不然就会报undefined的错误。
废了大力气加好后，页面总算是跑通了，一个细小的改动，却也花了我将近2个小时，效率低下。
想了下，其实还有有对策的，比如通过单元测试，记录某些数据的结构，将来要使用时查看相关的测试代码即可。
数据库的更改也可以开辟一张日志页面，将每次的更改记录起来，供其他人查看。
2）下班时间问题排查
如果只是界面展示的问题，只要不妨碍阅读，一般问题都不大，整个页面仍然可用，说句明天修复即可。
这是我上家公司的套路，但是在这边不行，因为我们也会负责后端逻辑，也就是说，会影响用户使用。
这个用户可能是公司员工，也可能是普通会员。一般有活动在线的时候，我们都会带电脑回家，随时准备排查。
但是日常，并不都会携带电脑回去，这个时候上报的问题，一般都是内部问题，但也需要做些初步排查。
首先连上VPN，打开公司管理后台，进入异常页面，如果是活动页面，就打开，并且确认是否也能看到异常。
然后就是确认接口，PC页面比较好找，打开控制台就能找到接口；移动页面需要打开Charles这类代理工具，抓包看接口。
再就是分析接口中的逻辑，一般就是查表或内部通信，借助之前的接口日志查看工具，就能看到SQL语句和内部接口，有些细节就需要查看源码了。
接着就是确认表的数据来源，由哪一端写入；或内部接口的响应值是否正确，接口由谁负责。
最麻烦的就是联调了，上面一通操作下来后，基本就能确定是哪一端出问题了，这个过程还是比较长的。
昨晚遇到一个问题，说主播在直播，但是无法推荐。看截图，发现问题出在管理后台，那肯定得我来出面解释了。
经过上面一通流程下来之后，确定有三端都与此功能有联系，并且服务端给出了发生这种问题的特殊场景。
如果在WIKI文档中，已经记录了这个功能的前后逻辑，那么也不必这么大费周章的排查了，目前很多内部逻辑都只能是口口相传。
文案断代很严重，还有很多文档需要补充，但资源有限，目前是遇到一个补一份。
3）内容审核优化
有一个领取任务的功能，每次运营都会领取1K条数据，在该接口中，首先会从一张内容表中读取1K条数据。
然后循环遍历这些数据，其中会有一次count()聚合计算，以及一次读日志表的操作。
如果只是几条数据，那么处理起来也很快，但是一旦量多了后，处理起来就会费时，接口平均响应达到了令人发指的15秒以上。
由于接口中的逻辑操作都得是同步的，所以无法剥离出来，优化的重点还是减少数据库访问次数和数据量。
经过观察发现，内容表中有730多W条记录是无法被领取的，需要对这些数据做进一步的释放，要么迁移，要么增加流程处理。
在将这些无法领取的数据迁移归档后，原表的容量从6.9G降低到224M，索引从2G多降低到100M。
随后就是创建一个定时任务，每天迁移一部分的数据到备份表中。
第二天得到反馈，部分页面的确提速了，但仍然有两个功能还是比较慢，所以还需要进一步的优化。
于是就继续观察，发现可以将需要聚合的数据事先一次性取出来，然后用代码计算是否满足条件，省了999次数据库读取。
修改代码后，接口的响应时间可以控制在1秒内，快的时候只要120ms。
二、工作优化
1）12月年底的挑战
12月份原本计划是2个版本的迭代，2个年终活动和2个年度回顾，中途还插入了1个充值活动。
版本有明确的提测时间，一个8号，一个10号，年终活动和充值活动有明确的上线时间，一个19，两个29。
与业务沟通后，将2个年度回顾延到了明年1月份，但即使如此，在开发期间，每个月都要并行的处理版本和活动的需求。
9号的时候，产品还想插入一个月度活动的需求，我算了下时间，太赶了，只有20号后才有时间，那就需要并行开发两个活动了。
在与产品据理力争后，同意将月度活动放到下一个版本中再开发。中旬的时候，团队有个人员要请两天假，我们的开发时间需要进一步压缩。
不过好在，今年团队创建了活动组件库，相同形式的年终打榜活动，去年要做5天，今年只要2天。
比较费时间的是另一种活动形式，即领任务拿奖励，任务规则和奖励还没做抽象，如果做了抽象，那么就能开箱即用了。
所以这是我们组下一步的计划，联合产品，将任务规则和奖励制作成可配置的，未来就不用再重复开发了。
我们组接到的版本需求也还好，有时间开发，虽然时间比较紧，但还是够的。
目前的生产力已经无法满足消费力了，需要再加个人，并且还得再想方设法的提升工作效率。
2）识别潜在风险
带团队之后，识别潜在风险也成了一项傍身技能，因为这些风险很有可能影响团体整体的工作进度、效率和体验。
11号晚上22点，收到一个充值故障，涉及到的又是一个陈年接口，并且这个接口目前已经没人维护了，就是公司早期用Node写的业务接口。
现在业务都被服务端接过去，大部分都已改成Go语言了，就剩下几个还在使用未迁移的接口。之前因为各种理由，得过且过，一直拖着，而这些就是潜在风险。
这次遇到问题了，才知道这件事的重要性，今天出错的接口会直接影响公司的收益，有必要尽快迁移至新接口中，由服务端统一维护。
除了上面这类技术风险之外，还有一些管理风险。10号收到一个小程序问题，说PC客户端中的一些图片不显示了，排查后将问题定位在微信客户端3.2.2版本。
网上一查，居然是个必现问题，然后赶紧安排人来修复，团队成员修复后就提测了，流程上没问题。但是她没意识到，这个问题比较紧急，应该要大力推进的。
她在发提测邮件后，就不管后续了。但其实，应该让QA安排人手加快验证，我在快下班的时候才想起这件事情，问同事后，才了解到没有推进下去，卡在QA。
无奈，也只能自己加班提交小程序审批，提交时需要写隐私条款，拉上了产品一起加班。其实这个加班也是完全可以避免的，但由于我的管理不到位，只能自己默默吃进。
自己对组内成员的特点没有拿捏到位，也是一种风险，其他组的成员特点，必要时也需要拿捏，以免不经意间就被坑了。
3）文档分散
目前我们各个组在维护着各自的文档，存在于WIKI系统、飞书、BUG系统中，文档之间都是隔离，没有关联。
例如产品写了份版本需求，与这份版本有关的技术方案会分散在各个技术小组内。
而与之相关的BUG也只会存在于BUG系统中，无法与这份版本需求文档关联。
当需要检索版本需求的技术方案或BUG时，会比较曲折，不够直观。
像一些长期迭代的项目，一旦开发或产品离职，原本的文档也会因无人维护而逐渐被人遗忘。
如果有办法将完整的业务逻辑聚合在一起，那么就能在原先文档的基础上进行更新，可维护性方面将大大提升。
手动将文档关联的话，这个脏活累活由谁来维护是个大问题。现在就缺了这么一个平台，不过自己也只是想想，还没任何计划。
4）2022年度规划
围绕降本提效，体验优化展开工作。
人员方面，打算再补充一个人，这样3个人中两个人各自负责一个APP的迭代，还有一个人负责整个后台管理系统。目前公司的双月计划中，会收到很多版本之外的需求，除了有时间截点的活动之外，剩下的需求都没有资源来做，导致这些需求被无限制的往后排，大部分是管理后台需求，所以这次加人就是打算彻底解决这类问题的。当然，在实际工作中会灵活协调三个人的工作内容，以免出现一个人很忙，另一个人很闲的情况。
低代码化，这是我2022年的重点，目前计划是制作一款搭建系统和规则引擎，抽象出公司常规的活动界面和活动规则。活动的后台服务，都是我们组自己维护的Node代码。愿景是希望开发时间浓缩至1天以内，并且保证开发质量。2021年虽然公司APP出现了点意外，但还是涉及130+各类大大小小的需求，20+各类活动和30次版本迭代。2022年随着业务回归正常，开发的工作量也一定会有所增加，除了加人之外，如何在有限资源下，完成最大价值化就是我思考的一个问题了。当然，不能用加班来保证业务进度，而低代码化就是我目前想到的一种解放生产力的方法。
文档化的推进，2021年虽然引入了很多文档，但是大部分是我编辑的。组内成员文档化的意识还不够强烈，并且代码中的注释并不多，包括一些关键位置的缺失，给自己阅读也会带来障碍。之前还想过文档分散导致高维护成本的问题，今年的话，希望能有所改观。
技术能力的提升，公司每半年会有一次360评测，这次评测收到反馈。业务部门的人希望我们组能提升下总体的技术能力，他们认同我们组的努力和成果，但他们觉得我们组可以做的更好，人员还有很大的潜力。如何提升，我最近也一直在思考，观察下来，大家的基础还是比较薄弱的，有必要先从基础入手，打打扎实。
加深与业务方的合作，挖掘她们的意图，提供增值服务。在产品将需求分发到我们组之后，一般都是被动的接收，很少会提出自己的观点，那么今年就希望做出些改变，大家能积极主动地去和产品沟通，帮助她发现那些盲点。与业务方的关系谈不上好也谈不上坏，但是她们其实经常会反馈系统难用，只能让人来适应系统，那么今年也希望能做出些突破。集中时间搜集体验需求，或者自己在使用时觉得难用就随手修复。增值服务就是那些能提升她们幸福指数的事情，例如页面秒开，人性化的功能设计等等。我自己虽然有这些意识，但被这样那样的杂事缠身，有时间就无法抽身来做。而自己的组员现在这方面的意识也比较薄弱，需要有人在背后推一把。
页面的性能优化，这是我2021年一直想做，但是没有精力做的事情。例如最近的年终活动，上线后发现页面一访问就会发起5个请求，因为有5个赛道。但其实稍微优化一下就能做到页面初始化时只需要一个请求，另外的请求完全可以在点击菜单时触发。在活动进行到第四个赛道时，由于请求量突然比平时高了4倍，导致pod扩容，从而访问接口都会返回502，零点的时候着实捏了把冷汗。所以今年，需要对性能的各方面把把关，避免再出现这种类似问题。
若有收获，就点个赞吧
0 人点赞
