💼 工作记录

    💼 工作记录 今天要修复一个之前写业务代码模块时候的一个bug,已经好几个月没写太多业务代码了。这让我回想起写业务代码有写业务的挣扎。新增或者修改一个接口经常要想很久,尤其设计了很多业务特化点的时候,减少特化和最小改动之间不断进行权衡。

    💼 工作记录 最近整理之前最早工作时候调研的一些关于进程、内存指标概念的文章。

    刚开始工作有很多时间用来调研和学习,mentor也很支持我,所以当时想猛攻这部分然后能写出一篇非常专业、完善、严谨的文章来。但是因为内存指标涉及到的内容很广,比如系统物理内存管理方式,虚拟内存技术中的概念,内存申请方式,不同操作系统中术语看似相似实际差别巨大,导致这篇文章一直没有写完。

    这次重新整理内容发现,像这种复杂的话题的写作,如果是专注于全就不用太深(配合更多的图表来梳理概念之间的关系),同时尽量避免知识性错误;如果专注于深,就不能太广泛,否则就会让自己陷入一个短时间难以完成的境地(比如内存这个话题可能需要很年的排查经验、源码研究等才能又全又深入,到足以出书的程度)。这个方式适合很多复杂话题的写作,比如耗时问题优化、性能品质、某个工具的使用等等。

    💼 工作记录

        std::string origin_response_body = "test_content";
        const int body_len = origin_response_body.length();
        std::unique_ptr<char[]> response_body(new char[body_len]);
        memcpy(response_body.get(), origin_response_body.c_str(), body_len);
        std::string body = response_body.get(); 

    这段代码是有隐患的,但是却比较难发现。因为如果这个数组中最后一位不是\0 结束符,构造string的过程中就会一直按照地址递增访问内存直到找到结束符为止,这个过程会导致内存异常访问等问题

    但在真实环境中,可能不一定会导致崩溃,因为当我们new[body_len] 申请一段内存的时候,由于内存对齐以及操作系统的差异性,分配的大小会大于申请的大小,因此在body_len 位置的内存很可能就是结束符。 C++Tips

    💼 工作记录

    最近的两个需求尝试以 “面向测试开发”来开发。所谓“面向测试开发”,或者“测试驱动开发”,我理解就是先去写UT,先去在UT里面写好调用的函数和预期的接口。每写一个EXPECT,对应去实现类的功能,这样写完UT,功能也开发完成了,保证了模块的质量。

    通过这种方式发现写代码的阻力更小一些。之前写代码脑子里可能混杂多个接口的设计想法,通过UT,每次只增加一个新的case,实现该case,能够“小步快走”,会更不容易出错。

    这对项目代码质量是有比较大的要求的,如果是一个新的独立模块,还好一些,可以从零开始写UT,如果这个模块有依赖外部模块,需要mock或者外部模块也具有可测性。

    如果是在已有的功能模块里新增新的功能,这就要求已有模块可测性非常强才行。历史的很多代码都没有UT,这也是困难之一吧。

    💼 工作记录

    “当你排除一切不可能的情况,剩下的,不管多难以置信,那都是事实。”

    工作中排查bug的时候很像是侦探🕵️寻找真相。简单的bug可能很快从代码review就能发现,比如空指针等。这周遇到了一个bug ,简单来说,

    • 正常情况下是先执行B操作,再执行 C操作。
    • 执行A 操作后,预期就不可能有B操作或者C操作了,但是A操作它是跨线程异步过程(一般时间很短几毫秒或者几十毫秒之内)。

    线上的问题是在A操作过程中,出现了B操作,导致后续C操作的时候直接崩溃。所以线上会有概率非常小的情况下崩溃。

    这里写代码的时候没有考虑到这个异步过程,同时B操作或者C操作中应该增加判断,如果A操作后,就是空操作。

    💼 工作记录 对于客户端开发来说,crash是性能/稳定性中最重要的指标之一,因为crash意味着功能不可用。

    最近工作上引入了两个功能crash,被折腾了一番,有一个感想:“对任何改动的上线一定要测试”。这里“测试”根据不同情况有不同程度测试,其中最基本的测试是确认功能是否能跑起来,而不仅仅是编译通过即可。

    可能你会说,提代码肯定需要测试啊。但是有些场景,可能就会偷懒,比如加一行日志,或者简单增加一个指针判空,或者简单调整了两行代码的位置,就因为“匆忙”,并且过度自信,就没有测试,甚至基本测试都没有!

    上述的场景可能是本地的分支开发别的功能,突然反馈过来的一个bugfix,为了本地不切分支,而选择在网页端简单提交bugfix的代码

    这些看上去“人畜无害”的代码,其实往往暗藏“玄机”。比如日志打印调用了一个指针的函数,却没有检查指针是否为空,误以为指针一定不为空,尤其是在编写宏的情况,更容易忽视。

    除了这些改动极小的代码,一些不是特别大的改动也可能引入意想不到的问题。举个例子,移动了某一个observer 事件发送的位置,在模块owner看来可能没什么关系,但可能外部利用了这个observer,并且依赖了某种时序,一旦某两行代码调整了顺序就可能导致异常。

    这里有一个调整两行代码顺序导致问题的例子:

    ....
    std::string str = "1234";
    SomeStrToInt(str);
    SomeClassConstruct class (std::move(str));

    其中第3行和第4行的位置调整就会导致异常,而这个问题非常难以发现,因为最开始的这段代码可能比较久远,甚至不是自己写的,因此就会忽视后面对string move的调用。


    有经验的程序员是否可以避免上述问题,足够细心的条件下一些简单的错误可以被避免,比如上面的std::move 顺序问题。但是对于更复杂的场景忽略掉也是可以被理解的,更不用说,粗心是一种很容易犯的问题

    因此黑盒测试的必要性是无法被白盒测试替代,白盒测试100%覆盖是一个理想而不及的目标,受限于代码可测性、ut质量等等因素。意味着一定有不少场景是UT无法覆盖的部分,对于大型项目尤其如此。(尽管如此,UT重要性仍然是不言而喻)


    我个人的一点想法是对任何提交MR做以下两点检查:

    • 做了哪些测试来减少问题发生 (至少要测试功能是否可以跑起来,而不是过度自信)
    • 是否对该处改动的所有外部依赖都清楚,如果不清楚则优先考虑使用灰度验证的方式上线(比如修改某个对外的接口返回值,不要过度自信!)

    上面的两点check不能避免所有的问题,但可以拦截大部分很低级的问题(事实很问题都来自低级的错误),除此之外,成熟的工程会一般会有完备的稳定性流程来拦截更复杂的问题。

    💼 工作记录 下班后如非必要,最好是不要打开与工作相关的任何网站、软件。只是简单的看看消息也会很快的让人感觉到“班味”。这对于放松心情是非常有害的,同时也不利于第二天更有精神的工作,长此以往会导致越来越强的厌倦。

    字节中有「字节圈」,类似内网的“微博”程序。之前很长一段时间会经常的刷,虽然这些内容都是素不相识,但也是打发时间了,不仅如此我还会频繁的去看飞书上一些免打扰群的消息,即使那些消息和我并没什么关系。后来我发现这种状态是非常有害的。即,我已经下班了,但是我的状态并没有完全下班,是祈求用忙碌、麻木的工作错觉来填补自己无事可做而已。这就是为什么上述说的如非必要,一定不要查看任何与工作相关的任何信息。

    平均来说,越少的工作时间确实是可以有更好的效率的。尝试了一段时间强制自己更早下班,会发现为了要更早下班,自己会强迫自己提高效率完成今天的事情。就好似是一种dealline。(当然特殊情况除外,但要尽量的少)。

    所以,如果一个公司强制员工更早的下班,同时以工作成果为绩效导向,我觉得是会让员工自发的寻找效率更高的方式的。

    此条为私密说说,仅发布者可见

    💼 工作记录 职场中应该会有很多时候会受到挑战。比如工作流程(开发/需求流程等等)是否合规,技术方案是否合理,考虑全面,代码是否严谨等。要学会受到挑战的时候不要急的把自己择出去,这样的心态会让自己会急躁的为自己辩解。但事实上很多时候不需要辩解,只需要解释,所以要缓一缓,如果是通讯工具沟通,不要急于回复,理清思路再回。面对面沟通,也可以停顿、思考片刻后给出回答,切勿自乱阵脚,有理也说不清。

    📝 每日记录 今天北京下大雪了,这可真算得上是鹅毛大雪!下班的时候,走在路上,雪特别的厚,踩在上面还有咯吱咯吱的声音,非常治愈

    补充一则记录:春节前,第一次点这家的烤串,点了一个烤猪蹄,特别好吃,送过来的时候温度也不错,猪蹄也挺嫩的。复工回来的时候,又点了一次烤串,发现很一般了。相似的经历是之前的一家炸鸡店,第一次点手枪腿,真的是太好吃了,手枪腿里还有汁水,第二次点怎么这么一般。不太清楚是丧失了新鲜感,还是确实餐品质变差了!

    PS:已经高强度上班三天了!
    PSS:明早还要早起赶文档!!

    此条为私密说说,仅发布者可见
联系方式

关于我

  • 来自南部的一个小城市,个性不张扬,讨厌随波逐流。

那年今日

🥳 周末 [WEEK-10] 周六看完了《太白金星有点烦》这本书 📖 读书 非常有趣,而且也不是特别长的一部轻小说,非常有趣,好久没有读到这么有意思的书了。周日看了三个房 ,现在房子要下下周到...

🥳 周末 [WEEK-02] 📖 读书 这周看完了《早安,怪物》。比较喜欢这种讲述别人故事的心理咨询类的书籍。这本书有一个观点觉得很受用。“人们确立这样的界限,好让他人以安全合理的方式与自己打...

我还没有在两个平台买过同一个东西对比过

10.0版本会支持,还在开发中

💼 工作记录 “当你排除一切不可能的情况,剩下的,不管多难以置信,那都是事实。”工作中排查bug的时候很像是侦探🕵️寻找真相。简单的bug可能很快从代码review就能发现,比如空指针等。这...