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

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

简介:   最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。   那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。   在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。   UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。
+关注继续查看

一、日常问题


1)模糊的提测时间

  最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。

  那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。

  在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。

  UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。

  但现在晚了一天,加上大家都不知道上线时间,从而就没有紧迫感,按照往常节奏推进,项目就会有延期风险。

  还好发现的早,还能补救,运营肯定是不接受突然延期,因为她们做了很多前期准备。那只能加加班,赶进度了。

  细究下来,其实还是沟通出现了障碍,之前也发生过一次对上线时间理解不一致的情况,只是当时是精确到小时,而这次是精确到天。

  未来,对于项目,心里一定要明确各个时间截点,免得再出现这种乌龙了。

2)招聘

  招聘是件蛮难的事情,就像找对象一样,要对上眼很不容易。

  在年前的时候,因为业务的上升,需要扩编,于是发布了两个前端岗位。

  可能是年前的原因,也没收到几份简历。HR也很忙,年底还有很多事情要做,也不能全部扑在招聘上。

  后面自己也在V站上发帖,也投稿给知名前端公众号和知名技术周刊上发布招聘信息。虽然转化率还是很低,但是终于收到了几份简历了,也算是0-1的突破了。

  其中年前面试了一名候选人还不错,年后让他过来继续后面两轮,谈下来都还不错,就发了offer。自己也总结了些对求职者的一点小建议

3)无人维护业务的修改

  客服在半年前提过一个业务需求,当时其实也没什么结论,因为是中等级的,所以也没放心上。

  后面又提过一次,得出的结论是服务端招人后,将整个服务全部迁移过去,做个彻底了断。

  但是近期,客服说要经常处理那个业务问题,很影响工作效率,于是提升优先级,当即安排。

  我们组内的其他成员手上都有事情,所以我自己来修改。在改的过程中,根据域名查到了项目文件。

  根据package下载依赖包,但本地却无法运行,代码已然缺失。还好改动程度并不大,于是就将代码修改后,发到预发环境。

  发代码我自己还无法发布,权限在服务端那边,我这边也因为权限组的原因,无法给我开这个项目的发布权限。

  所以我每次修改完,都要请服务端的人发布,然后再让QA验证。期间调用一个接口,涉及到另一个项目的改动。

  这个项目也一样,无法本地运行,也只能发到预发环境。期间查看日志,没有访问记录。

  这个问题还请运维介入排查,原来是因为接口调用了线上的域名。而这个域名其实是个IP地址,直接关联网关。

  由网关根据地址路径做转发,预发环境没有这类地址,又折腾了半天才调好。

  运维前几天打算释放几台服务器,这其中有台服务器搞了个私有的npm,服务于这次修改的项目。

  如果运维将那台服务器释放掉了,那么这次连代码都无法发布了,还要重新配置。

  就是一个简单功能的修改,涉及两个无人维护的项目,前端、QA和运维三端参与,服务端还需要配合,在人力成本上面,还是蛮大的,ROI(投资回报率)有点低。

  不仅开发调试困难,QA验收也困难,没有需求文档,只能通过我对代码的解释和她说明整个项目的流程。

  还有一个比较麻烦的点是,修改的功能需要与支付宝对接,支付宝会回调我们这边的一个接口,需要外网访问,就不能在内网的测试环境验证了。

  有个地方比较庆幸,那就是回调地址可以根据环境改变,否则的话,又要改造,开发成本就更高了。

  这些项目就是安全隐患,平时看不出,一旦有问题,要修复就要花费巨大的成本,今年需要推进迁移计划。

  后面和运维单独将正在使用且无人维护的后端服务找出,并且筛选出正在访问的接口或定时任务,择机做迁移,交给服务端维护。


二、工作优化


1)项目管理的流程漏洞

  最近有个功能的修改是由服务端的人提出的,在和产品沟通后,拉上相关人员开了个需求会,还整理出了相应的产品需求。

  后面产品就没怎么跟,让我们自己开发去了。这个功能前前后后总共持续了1个多月,服务端的那个人由于要去考试,就只能断断续续的开发。

  中间他请假了好多天,QA在预发上对功能都验收后,发出了上线邮件。

  然后这里就有问题了,虽然这个功能只是改动了售后流程的一个地方,但势必会更改客服的工作流程。

  直接上线后,和他们简单的沟通如何使用后,他们就开始使用了。晚上19点多的时候售后有个地方卡住了,咨询服务端,也没响应。

  那么客服只能按照自己的理解采取措施,但是那些订单都创建失败了,等到第二天早上10点,服务端才说他们漏了一步。

  大家都很无奈,一个早上都在配合着改,我这边还回滚了代码。

  从这边我看到了一个项目管理流程的大漏洞,就是在上线前还是得和业务方同步一下,让他们先了解整个操作的步骤,避免出现歧义。

  如果能多这么一小步,那么就不会搞出这么多麻烦事儿出来。很多时候都是人为的给自己制造麻烦,都自以为是很简单的事情,其实不然。

2)Tower

  Tower就是一个需求管理工具,公司的业务人员会将双月需求提交到此工具中。

  我们技术部的工作就按照此工具来排,老板的想法是让业务和技术两个部门的人沟通能无障碍。

  他觉得现在技术部和业务部之间的信息还不够透明。业务部提了需求,有时候就会泥牛入海。

  借助此工具,就能了解到需求进行到了哪一步了。

  在实际操作中,就暴露了很多问题,其实已经实行了一年,但是大家并不会太关注上面的状态。

  也就是说,大家并不会及时更新,也就是上面推了下,自己再写点东西。

  这个工具中的大部分工作,都指向了我们。对于我们来说,这上面的需求排在版本和活动之后,属于第三优先级的需求。

  在过去的一年中,由于人员有限,在完成版本和活动后,也就没剩下多少时间来改需求了。所以对该工具就更不上心了。

  但今年有所不同,管理层对这个工具很上心,还说要和OKR关联。这个双月开了好几次Tower会议,一遍遍的强调该工具的使用。

  其实每个双月都会遗留很多需求到下个双月,除了人员紧缺之外,还有就是落后的生产力,今年这种局面都会有所改变。

3)UmiJS升级

  去年因为要引入微前端,所以做过一次 1.0 到 2.0 的被迫升级。

  今年是想主动升级到 3.0,一则是与主流技术栈接轨,二则是因为3.0 版本默认支持TypeScript。

  今年想要在组内推广 TypeScript,进一步的提升项目质量。

  升级的过程也不是说很困难,但是遇到些体力活,改文件和移动文件,弄了一下午,具体过程在此

  还有比较担心的是,升级后业务的稳定性,我们缺少有效的全局测试,目前只能人工一个一个页面的点击。

  在发到正式环境之前,会先在预发环境发布,邀请相关业务负责人,先在该环境中操作界面,提早发现问题。

4)管理后台发布提速

  管理后台的界面代码发布一直很慢,基本保持在12分钟左右,去年也一直尝试着去优化,不过都没很好的成效。  

  这次和运维仔细分析了下症状,尝试着再做一次优化。

  每次发布大致可分为四段,第一是下载依赖包(2分钟),第二是构建(3分钟),第三是上传镜像(3分钟),第四是部署(3分钟)。

  除了构建之外,其他都可以靠运维来优化。

  依赖包可以开启缓存,镜像原先要1.4G了,所以上传才要几分钟,主要是因为将 node_modules 目录中的文件也打包了,这部分其实在网页运行时,并不需要,所以要去除。

  部署也在优化后,总共的发布时间控制在5分30秒左右,未来如果将构建也进一步优化的话,那发布速度还能往上提。

 

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

相关文章
纯JavaScript实现页面行为的录制
纯JavaScript实现页面行为的录制
97 0
Node.js躬行记(15)——活动规则引擎
  在日常的业务开发中,会包含许多的业务规则,一般就是用if-else硬编码的方式实现,这样就会增加逻辑的维护成本,若无注释,可能都无法理解规则意图。   因为一旦规则有所改变,那么就需要修改代码再发布代码,而在日常的开发中唯一不变的就是变化,修改规则是很常见的。   规则引擎的作用就是将决策逻辑从业务逻辑中抽离出来,使得两者可以独立于彼此,便于集中管理,减少硬编码的成本和风险,在不重启服务的情况下快速响应需求的变化。
69 0
数据结构与算法之美(二)——数据结构
 《数据结构与算法之美》是极客时间上的一个算法学习系列,在学习之后特在此做记录和总结。
41 0
跳槽一年后的回顾
  去年的9月底,我离开呆了5年之久的老东家,撤离舒适区,进入一个全新的环境。到今年的这个时候,已经差不多是一周年了。   这一年过的非常快,与之前很不同,每天都在忙碌着,都会遇到新的状况,想不同的应对策略,不像以前早上倒杯水,坐会儿,然后按部就班的工作。   每周的感觉是周一上班,明天就是周五,每日的感觉是早上上班,一眨眼就是晚上18点30了,又快要下班了。
23 0
带团队后的日常思考(七)
  最近被插入了一个需求,我们组经常会被插入各式各样的需求,因为之前负责的范围非常广。   这次的需求就和一个陈年接口有关,其实要修改的地方并不多,就是为一个请求多加一个参数。   但是比较麻烦的地方就是验证阶段,就是我在加上这个字段后,我得知道发请求的时候真的带上了。   根据URL地址反查到了页面代码,在本地启动项目,访问页面,直接报错。   调试陈年项目,这种情况是经常发生的,涉及的问题很多,例如内部接口不通了,数据库表结构变了,需要的数据记录本地没有等等。
22 0
从零开始搞监控系统(5)——小程序监控
  公司目前在线上运行着一款小程序,为了能监控小程序的运行情况,自行开发了一个参数搜集的SDK,名称为 shin.js,放置在 utils 目录中。
148 0
从零开始搞监控系统(6)——较长的白屏时间
  在直播间有一个小时榜的Web页面,经常有用户反映点击小时榜,弹出的页面会有蛮长的一段(3秒上下)时间白屏。
35 0
带团队后的日常思考(六)
  当前我们组管理着一套审核系统,除了数据源是服务端提供的,其余后台管理都是由我们组在维护。   这个系统就是将APP中的各类社交信息送到后台,然后有专门的审核人员来判断信息是否合规,当然在送到后台之前已经让机器审核了一遍。
28 0
带团队后的日常思考(三)
  参与制订业务方的BUG规范,业务方最近投诉我们技术部,在飞书群中提出BUG后,技术部没有人响应,认为我们的态度太冷漠。   后面我就提出任何看到的人,只要知道是谁负责的,就@那个人,大家都不要客气,这是第一步。
28 0
带团队后的日常思考(四)
  这次公司有个五周年的庆典活动,但正好碰到两个APP的版本发布,以及三个测试老员工离职,只进来了两个新成员,其中一个恰好要休陪产假,那么测试组资源异常紧张。   虽然我们提前了整整一周提测,但一直到周五还有很多点没测到。测试组甚至想到了阶段测试,因为多个活动的上线时间不同,所以可以先测最先上线的活动,后面的再往后推,延迟测试,这是他们组的一个对策。
25 0
+关注
咖啡机(K.F.J)
每天进步一点点 研磨生活的香甜
350
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载