还未发布过话题
  • 放心,日常的业务开发也就是 CRUD 哈哈,关键的架构设计,整体的业务结构方向上,不会砸到新人头上的。刚转的第一年线上 bug 爆多,看同组谁都是大神,现在两年了,感觉大家好像都差不多,谁还不是个 crud 仔呢。

  • 我在做测试第三年的时候,也是一样的想法,开始考虑回老家的问题。我的选择是去了一个体量中等的公司(一千人左右,研发团队技术还算行的公司,架构不是太老太烂,贴合互联网主流技术栈,可以参考对应公司后端招聘的 jd 做分析)做测试,个人觉得中小公司里测试转开发更容易一些。在那里做了半年测试,写个平台,熟悉相关业务了,这时候跟后端 leader 和总监聊的想转,简单面了一下没啥大问题就过去了,现在 java 也做了一年半了,也开始做一面,感觉很多初中级后端的八股和算法真没比大厂校招测开强多少,主要还是在架构体系,方案设计,框架应用这些经验上。所以还想转 java 的话,不妨试一下业务门槛高(区块链、云、金融啥的)的中厂测试,在转岗的时候对业务的熟悉,勉强能抵消一点工程经验上的不足,然后再内部转

  • 老哥你这顾虑的第一点和第三点,个人觉得还好,感觉还得是从转岗的成本和收益上考虑。从一个过来人的角度讲,不需要太担心技术和学习成本,我转之前也贼担心,但业务开发的要求其实不高。我之前转过来之后,总监要求我三个月内把高性能 mysql、spring 实战、阿里代码规范,这三个东西熟读两遍,建议也看下。前三个月有点手足无措,这三个东西看完之后,感觉也还好了,至于微服务,中间件之类的知识,刚转过去,也不会负责架构、搭建的工作,用的时候查一查对应的八股,不要违反明显的常见的规范就好,ide 可以再安个静态代码检查插件啥的,日常工作基本也不会出现坑同事的操作。。在一个技术还算可以的 java 团队里,新人捅篓子的概率还是比较低的。
    不过有一说一,七八年的测试经验,估计主流测试技术和对应的工程经验也都差不多了,如果不走岗位很稀缺的测试架构啥的,技术储备应该都差不多足够了吧,后面就剩舔领导熬资历等机会了,测试经验对于研发岗的增益几乎是零,这经验有点浪费。。

  • 转 go 他不香么铁汁

  • 面试 XX 前,我要读的书 at January 25, 2022

    这些全看完之后:
    研发你给我跪着听,我来教你怎么优雅的写代码!
    你这什么烂设计,快去给爷重构!功能实现我不管,像诗一样的代码得这么写!
    你这么实现,虽然性能和安全上没毛病,但可读性太差!能不能为后面的接手的人想想!

  • 写单元测试的公司多吗? at January 12, 2022

    感觉大多数公司,业务部门的节奏应该都很难维护一套稳定的单测,很多业务部门的专业测试团队连自己本身,都因为维护成本大、日常测试任务排期紧等原因,连最粗粒度的接口测试集合都维护不好,场景维护不全。这种的让研发团队在每个需求工期里排时间设计测试用例,维护粒度更细的单元测试就更不可能了。
    工作中遇到的单测覆盖全面且稳定的项目,大多是没有专职测试的开源工程或者内部非业务服务。

  • 同问

  • 在相对稳定的供需环境内,实用价值和产品质量相差不大的情况下,不吹牛逼造概念炒品牌,搞不出商品溢价啊 [手动狗头]

  • 同 M1 Pro 16G+512,至少 java 后端日常工作开发完全没问题,至于是 16G 还是 8G。。。。。。

  • 如果已经掌握 python web 开发能力的话,简单熟悉 java 语法,花几天看一看 spring 的课程应该就可以看懂。
    如果仅仅是告诉后端,代码那里错了其实是很容易的,有了上述的前置,要来项目权限,本地起来服务(大多数基础稍差的测试走到这一步,就不好意思弄了,因为发现自己前置知识严重不足,一步一坎,都得问后端)。通了之后,拉对应分支,哪个接口报错了,本地起服务,请求一下,堆栈信息一截图,贴到 jira 里就完了。