开发者社区> 咖啡机(K.F.J)> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

带团队后的日常思考(七)

简介:   最近被插入了一个需求,我们组经常会被插入各式各样的需求,因为之前负责的范围非常广。   这次的需求就和一个陈年接口有关,其实要修改的地方并不多,就是为一个请求多加一个参数。   但是比较麻烦的地方就是验证阶段,就是我在加上这个字段后,我得知道发请求的时候真的带上了。   根据URL地址反查到了页面代码,在本地启动项目,访问页面,直接报错。   调试陈年项目,这种情况是经常发生的,涉及的问题很多,例如内部接口不通了,数据库表结构变了,需要的数据记录本地没有等等。
+关注继续查看

一、日常问题


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,零点的时候着实捏了把冷汗。所以今年,需要对性能的各方面把把关,避免再出现这种类似问题。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
带团队后的日常思考(八)
  最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。   那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。   在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。   UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。
30 0
移动端 iOS 年终工作总结-纯干货请自备酒水(下)
移动端 iOS 年终工作总结-纯干货请自备酒水(下)
43 0
【集合框架】JDK1.8源码分析之LinkedList(七)
  在分析了ArrayList了之后,紧接着必须要分析它的同胞兄弟:LinkedList,LinkedList与ArrayList在底层的实现上有所不同,其实,只要我们有数据结构的基础,在分析源码的时候就会很简单,下面进入正题,LinkedList源码分析。
15 0
团队紧密协作
团队紧密协作
37 0
对研发团队稳定性的思考
创业团队是一个高风险的团队,包括内部核心人员和管理者,因为好产品不是决定成功的唯一因素,这里暂且不谈论市场,运营,单单从团队稳定性来做一些探讨。 自己做过一些年的开发,包括现在也在兼做开发,也没有买房,在如此浮躁的年代,恰巧又身处大城市,屌丝一个,自己凭什么不跳槽? 大城市太辛苦了,没有节操的房价,每年一涨的房租,狗日的公立学校。
1229 0
团队紧密协作
版权声明:欢迎转载,请注明沉默王二原创。 https://blog.csdn.net/qing_gee/article/details/44965793 前言:jeff atw...
644 0
团队精神
<p style="text-align:center"><strong><span style="font-family:Microsoft YaHei; font-size:18px">当所有人都怀疑我能力的时候</span></strong></p> <p style="text-align:center"><strong><span style="font-family:Micr
1009 0
+关注
咖啡机(K.F.J)
每天进步一点点 研磨生活的香甜
350
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载