• 测试的出路在哪里? at 2022年04月24日

    因果倒置了。
    最初之所以有测试,其实就是因为你说的这种完美的情况无法普及。
    如果真的这么好普及,测试也不会出现并发展成行业很重要的一环。

  • 学了几个新名词 at 2022年03月07日

    以前打 dota 的时候有一句话很经典:看了等于会了,玩了一把等于精通,赢了一把等于绝活。
    好好的词,就被绝活哥们搞臭了。

  • 这里只是举了一个简单场景,实际业务会远比登录复杂,所以在设计时进行了业务逻辑和数据处理的分层。

  • 确实是习惯问题,这次属于暴雷了,哈哈。
    帖子中的举例只是场景中的某一种,之所以要这么做,是因为想把对数据的定向修改放到统一的地方,这样在写业务逻辑时可以分层考虑问题,不会将逻辑处理和数据处理的代码混在一起。

  • 不爽就走人呗。
    不过如果真的没去一个地方都觉得主管不行,那也许可以看看是不是自己也有做的不好的地方,比如是不是想法太激进了?

  • 求数据结构 at 2021年09月11日

    加限制的话,其实也挺难的,6 个点就 800W 种排列了,100 个点加了限制局部也很容易就形成 6 个点 7 个点的情况。
    而权重只会影响某个组合出现的概率,并不会影响总数。
    如果是要做精准测试的代码函数流转关系的话,这个方式恐怕有点难,你想想 30 个类就已经这样的,正常的项目别说 30 个了,300 个类打底吧。

  • 求数据结构 at 2021年09月09日

    事实上我认为,这么大的数据,对正常的场景来说已经是没有意义的了。

  • 求数据结构 at 2021年09月09日

    按我之前回复的计算,5 个点 113400,4 个点 2520,3 个点 90,2 个点 6。这个数据,增长的太快了,别说 100 个了,30 个的数据就已经爆炸了。
    你这个求的是排列,太多了,光是 start 立刻接 end 这种,都有 A100 的排列组合,还有 start 接 start,把所有 start 接完再处理 end 的也有 A100*A100。
    不过通过上面的数据,发现一个规律,总点数每 +1,连线的总数就在前一个的基础上乘以 (总点数) * (2* 总点数-1)。
    按照这个规律计算的话
    6 个点的总点数是 7484400(事实上在回复的过程中我就在跑 6 个点的数据,跑完后的总数和预测相符)
    30 个点的总连线是 7749523141180528462190498768559996393280264554881719828070400000000000000。
    就瞅瞅吧。
    好奇是什么具体场景。

  • 只是某些利益相关的人口中被神话了吧,而老板通常更会被这部分人影响。
    其实,很多人老早就看到了你说的这些问题,而有些人只看到了问题,有些人却早就在想怎么解决这些问题了。
    我很赞同 Jerry 的观点,只看到缺点的话,视线会被影响,只有同时明确自动化的优点和缺点,做到心里有数才能因地制宜。
    生活有很多不如意,如果只看到不如意,应该不会快乐吧。
    工作也一样。

  • 求数据结构 at 2021年09月07日

    我来理解一下:我有 5 个类实例,每个实例都有两个属性:起始点和结束点。现在要求实例间的连线,要求每个实例的起始点要先用,才能用结束点。
    连线用 1++ 来表示应该可以,然后只要求实例中的起始点小于结束点就可以。