E-mail: onlythen@yeah.net
Brief:Javascript/Rust
常用网名:aircloud

除了在本网站外,我还会在知乎专栏更新一些个人内容,两者之间内容不完全重合。另外出于一些保密性原因,笔者部分文章无法展示地非常细致,不过如果你遇到了类似的问题,欢迎通过邮箱和我取得进一步的联系。

我的早期博客之一:https://blog.csdn.net/ul646691993/ (早期写的比较混乱,权当记录~)

本页会存放一些琐碎个人思考记录

  • 2022.11.12

将更多的业务逻辑变成纯函数:

最近在重构某一个业务逻辑,之前的问题主要是状态转换混乱到难以维护,大几千行的代码,各类数据处理逻辑讲状态转换逻辑杂糅在一起,出了问题不好处理不说,性能也比较差。

重构的思路,就是抽离工具代码和状态转换函数,并且使用全局唯一的状态,这次直接把工具函数全都放在独立的文件夹下了,剩余只有 10% 的代码涉及到状态转换,这样之后修改代码的心智负担便非常小:

  • 如果修改状态转换,只需要组装无副作用的工具函数生成状态,然后写入唯一状态,利用单向数据流驱动渲染。
  • 如果只是调整逻辑,大部分时候只需要关注一个或者几个工具函数,完全不需要担心其他逻辑。

我认为,这个思想其实并不新,只不过我们在日常开发中,出于开发习惯不好等原因,时常写写就写复杂了。

  • 2022.08.24

为了破局,焦虑的开发者渐渐成为“短期速成知识”的收藏者。你以为收藏的是知识,其实收藏的是“知道”,你以为掌握了知识,其实知识囤积了一堆“知道”。

  • 2022.06.05

不要忽略哪怕一个微小的不符合预期的细节。

有的时候,当你编写程序的时候,可能会偶尔遇到一些和当前主要专注的事情无关的,或者影响不大的有问题的细节,这个时候一定不要忽略它,深入下去,把它解决,因为它后面很可能会意味着一个更大的问题或者隐患。

  • 2022.02.14

当你发现有些事情不对的时候,沉下心来思考一分钟,做出最正确的选择,无论是及时止损还是坚持下去,但一定要记住,理性分析,长期主义。

  • 2022.02.06

最近在给一个自己的小开源项目加新功能和单测。发现写单测真的很有用,经常我加完一个功能之后,某个单测就挂了,然后仔细调查发现是一个边界问题。如果没有单元测试,这些问题恐怕需要很久之后才能暴露出来。

TDD 是否有用呢?虽然它已经被证实确实有用,但我实际上还是没有彻底实行过一次,希望下个项目可以尝试一下。

  • 2022.01.26

人生在世,不能决定的事情比自己能决定的事情要多得多。在自己的能力范围内做正确的决定,然后足够努力,足够坦然就可以了。

  • 2021.09.20

我认为,一个比较好的团队文档协作工具,应该能满足以下几个要求:

  1. 在线化:随时随地编辑,虽然现在 web 被国内各个大平台割裂了,但仍然是最有效的方式。
  2. 实时协同:如果做的足够到位,甚至可以省略掉很多会议。
  3. 注重内容而非形式:满足基本需求后,本身不提供特别过度的定制,防止出现 ppt 工程师。

在此基础上,每一个规模化发展的团队也许都应该有这样的平台,从而沉淀出一个领域知识库。

  • 2021.08.03

关于鼓励上升:在一个层级比较多的团队中,高层管理者通常会表示我们鼓励上升,不过具体到实际的工作场景中我们需要注意,即使上升,也优先上升到自己的 leader,特别是在跨团队沟通中,遇到矛盾的时候,直接拉对方的 leader 这种行为可以理解为职场禁忌之一。

  • 2021.03.22

感觉有的时候,员工打破边界对于公司来书并不是一个好事情,比如一个客户端的同学,去做 c++ 了,这个时候应该鼓励还是反对呢?实际上这个时候,他除了仅存的业务熟悉度和一些通用的编程能力,c++ 的能力也许就只有应届生的水平,如果从新招聘可能连初试都过不了。公司就必须要承担因为他的编程能力不熟练带来的效率损失,甚至因为更容易引发问题造成更大的损失。

  • 2021.01.06

分享在一个工作环境(特别是比较内卷的环境)下工作的两条原则:

  • 事不关己原则:除非有 100% 的把握和你有关或者问题能够在你这里得到解决,否则没有 @ 到你的 OnCall 不要回复,因为如果你回复了大概率这个事情就会由你继续跟进下去,而且我通过近两年的经验发现这些事情都几乎不会让你有所成长,也不会有所产出(当然如果是开放环境下的技术讨论,不在此范畴)。
  • 肯定别人原则:对于大多数而言,被否定、被质疑、被秀优越(这点很重要)通常都是很难受的,比如:当某个同学分享他裸写算法实现的图像处理 Chrome 插件,你立刻打断说可以更快有更好的方法,提及一些更加“高大上”的名词,而且还可以更简单,这个时候可能就不是十分恰当,更恰当的做法我认为是在 QA 环节中做一点进一步的引申,并且先对分享者表示肯定。
  • 2020.06.01

延迟反馈:通常,当我们收到一个用户反馈一个问题的时候,已经有很多用户遇到这个问题了,他们通常默默忍受,或者默默走掉,不做声。并且很可能包括反馈问题的人在内,都已经尝试了很多次,在他们有限的认知下实在没有办法了,才来进行反馈。我们感谢这些发声的用户的同时,也应该审视,自己是否可以更早地发现这些问题。