💻 代码思考

    💻 代码思考 存在多个指针类型 out 函数参数,特别小心的是当其中一个out参数取值错误,其他out参数的赋值情况。

    比如

    TestOutClass* out1 = nullptr;
    TestOutClass2* out2 = nullptr;
    bool Getxxx(TestOutClass** ptr, TestOutClass2** ptr2){
    xxx
    }
    auto ret = Getxxx(&out1, &out2);

    当返回值为false的时候,理论上out1 和 out1 仍然是nullptr,外部不需要释放任何资源。

    因此在 Getxxx 函数内部实现的时候,可能会出现ptr 赋值成功,ptr2 赋值失败,此时返回值为false,导致外部没有意识到需要释放out1 的空间导致内存泄露。因此在内部实现的时候,应该等ptr 和ptr2 的内容都获取到后,再给两个指针赋值。

    💻 代码思考 好的注释应该是解释性语言,而不是动作性语言。具体例子:

      // |json_file_path_| is the path of a file that will be source of the
      // deserialization. |options| is a bitmask of JSONParserOptions.
      explicit JSONFileValueDeserializer(
          const base::FilePath& json_file_path,
          int options = base::JSON_PARSE_CHROMIUM_EXTENSIONS);

    上面代码是chromium base 库中关于json 解析工具的注释,它解释了两个参数的作用。

    一个不好的写法如下,对参数的注释是这个函数在做什么,而不是参数本身的说明:

    // We parse the file with the |json_file_path| path, passing in the 
    // bitmask of  JSONParserOptionstype |options| in the process
     explicit JSONFileValueDeserializer(
          const base::FilePath& json_file_path,
          int options = base::JSON_PARSE_CHROMIUM_EXTENSIONS);

    💻 代码思考 以往工作中常用的设计模式只有代理模式、观察者两种,似乎不太需要太复杂的设计模式。这一周工作主要是重构了之前写的一部分代码来支持更通用化的需求。因为这个需求中设计到很多状态的转换,每个状态都会有几个分支,尝试了状态设计模式,设计状态,设计每个状态会执行的动作,设计每个状态执行相应动作应该转移到的下一个状态以及副作用行为。Xstate 项目的可视化非常方便提前先构建好整个状态机的模型。

    写完之后,能很明显的感觉代码思路清晰很多。之前是在很多基础模块中去判断状态,然后进行对应的行为,这次所有的状态管理全部收敛到一个controller中,状态的转移过程对外是不可见的,外部基础模块只要调用controller的对应动作方法,controller会将工作委托给对应的状态处理。不再需要像之前那样,先获取当前状态,再判断当前状态,最后执行某个行为转移到新的状态。

    同时一个独立的功能需求的代码设计是不应该嵌入到一些基础类型的模块中的,而是应该写一个controller,将需要使用的基础模块作为该controller的成员指针来使用。

    💼 从工作中学到的 💻 代码思考在正式工作之前,我没有写过单测,主要是平时自己写的代码通常耦合度较高,没有单独抽象设计模块的概念。

    最近开始写一些通用能力的基础库需要写单测。第一次单测的编写是在代码基本完成后开始写的,完成单测后会发现一些bug,于是修改bug。但这个过程中会发现代码设计的一些不合理之处,比如多个接口的返回值是否更统一,对于接口可能出现错误时的返回值,应该如何处理(这个可以多参考chromium base库中的代码实现)。如果一个模块的多个接口设计不统一、那么单测同样也会非常复杂。

    其实上面的过程就有点TDD那味了,但是测试驱动开发,需要先写一个无法通过的测试,通过修改代码来使得测试通过,再重构代码。在这个过程中不断的开发代码,而不是先写完代码,再写单测试。

    单测的重要性是毋庸置疑,因为代码复杂性总可能出现某个分支逻辑错误。因此TDD将单测与开发结合,减轻了写单测的难度和压力,同时也能通过单测进一步发现代码的设计问题。

    参考文章:

联系方式

关于我

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

那年今日
3 月前

👀 产品观察 最近 Arc 浏览器话题度较高,原因大概是最近允许教育邮箱直接内测吧。趁着这个机会,使用了一段时间。我的感受是:不习惯+不好用。这就是一个披着mac os 原生软件皮的chrome(基于chromium开发)。官网的噱头就是外观设计足够的吸引人。但是如果说只是看外观,难道Safari的外观设计不好看吗。但是safari的份额如此之低,在于Safari就是为了外观牺牲了很多易用性。当然还因为它不是chromium内核导致很多插件没有(我个人的主要原因)。看上去浏览器的外观,这十几年都没有变化,顶栏是标签列表,接着是标签列表,edge支持把标签列表放到左侧边栏是一个很大的变化,也足够的易用,因此edge的外观创新是成功的。再来看看arc的创新,官网介绍是“Arc is your space to breathe on the internet.”,啧啧啧。饼还挺大,使用arc的第一个感受:掉帧,没有chrome流畅。猜测原因是mac的透明背景、毛玻璃效果还是挺占用cpu的...再来看arc的交互设计,很多地方彻底改变人们对浏览器的习惯,这点不评价是好事还是坏事,只是这种习惯的颠覆,没有正比例带来颠覆的收益。比如地址栏放到了左侧边栏,同时左侧边栏只能彻底隐藏或者显示比较宽的一个区域,让整个网页显示区域过小,体验过差。还有标题栏也没有了,需要鼠标hover上去才能显示...难受。当然可以用快捷键,隐藏左侧边栏。左侧边栏和顶栏都消失的时候,整个浏览器只剩下网页,这种感受是从来没有过的,很奇怪。当然arc还是有一些特性不错的,比如左侧边栏支持多个space切换,这个希望edge 跟进。还有左侧边栏显示下载的内容列表也还不错。但是总体,arc对浏览器的核心工作创新太少,完全算不上所以的“新的互联网”,基本上就是UI上改改,同时打破了很多习惯,在网页滚动的流畅性也降低不少,所以根本无法“名副其实”。我会再尝试一段时间,再来写新的感受。

4 月前

📝 每日记录两个感受:思考先行,做一个功能、需求,先去思考,这个思考不是说凭空思考,而是去写一些伪代码、流程图、甚至可以是部分代码,让整个需求变得清晰,让这个需求中的每个流程的流程图清晰,并且有文档可以备份大的需求一定要分期完成,一次性考虑太多分支及其出问题,先限定条件,完成一个分支,再慢慢向外扩充,通用能力

5 月前

多谢关心:)

10 月前

笑死😆

12 月前

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

13 月前

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