还未发布过话题
  • 现状和道理很多人都或多或少有感触,关键还是要如何去破局,转行转岗就不说了,就说说怎么在这条路坚持下去。
    职业发展往上走,都是需要综合素质和影响力的,看似瓶颈,但实际上能做的还有很多。测开和开发、产品等岗位本质上都是一样的,运用自己的知识、经验,提供交付能力,只是侧重点略微不同而已。

    说点实际的吧,我个人的话是预期在未来往两个方向努力:

    1. 个人能力,提升开发、产品体系、测试经验总结、沉淀
    2. 建立体系的能力,包括业务测试、自动化、效能

    瓶颈归瓶颈,真正遇到瓶颈的人,哪怕晋升再难,实际过得也已经很不错了,慢慢沉淀呗,总是有各个方面需要提升的。另外真有其他打算,也可以换条赛道。

  • 这道题只是一道简单的字符串题,一个遍历就搞定,不涉及动态规划。具体的动态规划可以搜一下动态规划标签的题

  • 我看了下内存占用,开 IJ WS PC DG 四个 IDE+chrome 几个网页 + 一个通讯软件的情况下就占用 16G 了,8G 不够用的

  • 我每天正事不干,光琢磨着怎么炫技去了😂
    正常项目里面我可能会分成两个装饰器去写,尽量避免不同类型的入参和出参

  • 看见 python 代码,手痒,用类的实现方式也写了一个玩玩

    class loop:
    
        def __init__(self, times):
            self.func = times if callable(times) else None
            self.times = times if isinstance(times, int) else 5
    
        def __call__(self, *args, **kwargs):
            if self.func is None:
                self.func = args[0]
                return self.__call__
            for i in range(self.times):
                self.func(*args, **kwargs)
                print(f"运行的第{i + 1}次")
    
  • 这种情况我个人能想到的就还是多模板匹配了,个人比较擅长用图像识别的方式做 UI 自动化。

    1. 把不同座位的图截下来
    2. 遍历座位模板,多模板匹配,找出图中不同座位的分布信息
    3. 组合不同座位的分布信息,就可以得到上面我说的整体座位信息矩阵。分类的话就是按模板来的,匹配什么模板,就对应什么分类信息

    4. 涉及坐标变化,通常坐标变化都是有规律的,操作完之后记录整体的坐标变化量或者复位之后再继续操作也行。

    5. 可能还涉及不同设备的兼容性问题 (用图像识别都会遇到这个问题),先搞定上面的问题再看吧

    这个方案能解决问题,就是需要对图像处理和识别比较熟练。

  • 突然想到自绘的话也是从后端接口拿的数据,可以先请求后端座次信息接口,再计算对应坐标点,通过坐标的方式操作控件。

  • 问题的核心还是在于拿不到控件信息吧,用图像识别的多模板匹配是可以做到获取控件信息的。
    只要实现这样一个函数,就可以解决问题,
    输入:座位截图
    输出:座位信息矩阵
    [
    [Seat(), Seat(), Seat(), Seat(), Seat()],
    [Seat(), Seat(), Seat(), Seat(), Seat()],
    [Seat(), Seat(), Seat(), Seat(), Seat()],
    [Seat(), Seat(), Seat(), Seat(), Seat()],
    ]
    Seat 类里面包含了座位的是否可选、价格、类型等信息

  • 资源池的创建和销毁主要是靠框架维护,按任务隔离,每个任务都给一个 id,在任务执行完 (或执行异常) 时清掉该任务创建的资源。

    我的场景还不太一样,最初的痛点是经常会按不同的维度去划分服务,有时按系统分,有时按场景分,有时又按业务领域分,但是他们的一些基础依赖 (例如各个系统的登录、数据库连接等等) 又是会有重叠的,每个服务都自己创建一遍资源太浪费,每个资源都自己维持一个单例或者资源池又可能会受不同任务的并发影响,索性建立了一个按任务隔离的上下文 + 资源管理池。

    接口间这个数据传参我倒没有像楼主这样按 key、value 去划分,通常粒度控制在 DTO(对象,字典) 范围,我司的跨接口或跨系统传参经常都是按对象去传,比如一个订单要填地址信息,这个地址信息通常不是单个字段,而是包含姓名、电话、地址等多个字段的集合,我从获取地址信息的接口拿到这个集合,更改一下不同的 key 或者类型,多出来的不管,把它传递到下一个下单的接口。

  • 挺不错的实践,我最近在解决类似依赖问题的时候也是采用了同样的方案,用资源池解决上下游的耦合以及避免资源的重复创建,用依赖注入来减少主动去资源池拉资源的代码。
    主要的思想来源是 spring 和recoil