本页会存放一些琐碎个人思考记录
- 2022.11.12
将更多的业务逻辑变成纯函数：
最近在重构某一个业务逻辑，之前的问题主要是状态转换混乱到难以维护，大几千行的代码，各类数据处理逻辑讲状态转换逻辑杂糅在一起，出了问题不好处理不说，性能也比较差。
重构的思路，就是抽离工具代码和状态转换函数，并且使用全局唯一的状态，这次直接把工具函数全都放在独立的文件夹下了，剩余只有 10% 的代码涉及到状态转换，这样之后修改代码的心智负担便非常小：
- 如果修改状态转换，只需要组装无副作用的工具函数生成状态，然后写入唯一状态，利用单向数据流驱动渲染。
- 如果只是调整逻辑，大部分时候只需要关注一个或者几个工具函数，完全不需要担心其他逻辑。
我认为，这个思想其实并不新，只不过我们在日常开发中，出于开发习惯不好等原因，时常写写就写复杂了。
- 2022.08.24
为了破局，焦虑的开发者渐渐成为“短期速成知识”的收藏者。你以为收藏的是知识，其实收藏的是“知道”，你以为掌握了知识，其实知识囤积了一堆“知道”。
- 2022.06.05
不要忽略哪怕一个微小的不符合预期的细节。
有的时候，当你编写程序的时候，可能会偶尔遇到一些和当前主要专注的事情无关的，或者影响不大的有问题的细节，这个时候一定不要忽略它，深入下去，把它解决，因为它后面很可能会意味着一个更大的问题或者隐患。
- 2022.02.14
当你发现有些事情不对的时候，沉下心来思考一分钟，做出最正确的选择，无论是及时止损还是坚持下去，但一定要记住，理性分析，长期主义。
- 2022.02.06
最近在给一个自己的小开源项目加新功能和单测。发现写单测真的很有用，经常我加完一个功能之后，某个单测就挂了，然后仔细调查发现是一个边界问题。如果没有单元测试，这些问题恐怕需要很久之后才能暴露出来。
TDD 是否有用呢？虽然它已经被证实确实有用，但我实际上还是没有彻底实行过一次，希望下个项目可以尝试一下。
- 2022.01.26
人生在世，不能决定的事情比自己能决定的事情要多得多。在自己的能力范围内做正确的决定，然后足够努力，足够坦然就可以了。
- 2021.09.20
我认为，一个比较好的团队文档协作工具，应该能满足以下几个要求：
- 在线化：随时随地编辑，虽然现在 web 被国内各个大平台割裂了，但仍然是最有效的方式。
- 实时协同：如果做的足够到位，甚至可以省略掉很多会议。
- 注重内容而非形式：满足基本需求后，本身不提供特别过度的定制，防止出现 ppt 工程师。
在此基础上，每一个规模化发展的团队也许都应该有这样的平台，从而沉淀出一个领域知识库。
- 2021.08.03
关于鼓励上升：在一个层级比较多的团队中，高层管理者通常会表示我们鼓励上升，不过具体到实际的工作场景中我们需要注意，即使上升，也优先上升到自己的 leader，特别是在跨团队沟通中，遇到矛盾的时候，直接拉对方的 leader 这种行为可以理解为职场禁忌之一。
- 2021.03.22
感觉有的时候，员工打破边界对于公司来书并不是一个好事情，比如一个客户端的同学，去做 c++ 了，这个时候应该鼓励还是反对呢？实际上这个时候，他除了仅存的业务熟悉度和一些通用的编程能力，c++ 的能力也许就只有应届生的水平，如果从新招聘可能连初试都过不了。公司就必须要承担因为他的编程能力不熟练带来的效率损失，甚至因为更容易引发问题造成更大的损失。
- 2021.01.06
分享在一个工作环境（特别是比较内卷的环境）下工作的两条原则：
- 事不关己原则：除非有 100% 的把握和你有关或者问题能够在你这里得到解决，否则没有 @ 到你的 OnCall 不要回复，因为如果你回复了大概率这个事情就会由你继续跟进下去，而且我通过近两年的经验发现这些事情都几乎不会让你有所成长，也不会有所产出（当然如果是开放环境下的技术讨论，不在此范畴）。
- 肯定别人原则：对于大多数而言，被否定、被质疑、被秀优越（这点很重要）通常都是很难受的，比如：当某个同学分享他裸写算法实现的图像处理 Chrome 插件，你立刻打断说可以更快有更好的方法，提及一些更加“高大上”的名词，而且还可以更简单，这个时候可能就不是十分恰当，更恰当的做法我认为是在 QA 环节中做一点进一步的引申，并且先对分享者表示肯定。
- 2020.06.01
延迟反馈：通常，当我们收到一个用户反馈一个问题的时候，已经有很多用户遇到这个问题了，他们通常默默忍受，或者默默走掉，不做声。并且很可能包括反馈问题的人在内，都已经尝试了很多次，在他们有限的认知下实在没有办法了，才来进行反馈。我们感谢这些发声的用户的同时，也应该审视，自己是否可以更早地发现这些问题。