代码思考

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

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

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

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

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

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

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

    参考文章:

联系方式

关于我

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

那年今日
1 月前

习惯了就不晕了

2 月前

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

4 月前

疫情什么时候结束呀!啊!

6 月前

垂直标签栏用起来真的很有新鲜感,搭配设置里面隐藏标题栏变得很简洁。除此之外cmd+shift+A 设计的搜索标签页的样式比chrome好用

8 月前

9 月前

又跳票了

10 月前

今天早上做的梦:在一辆车上,本来是从北京一个地方开往另一个比较偏的地方,突然开到了福建... 然后一车人的健康码都变红了,因为出了北京,都是质问司机怎么回事,司机说不知道怎么回事转错了弯就开过去了.....