2023 关键词：做减法

Posted 2023-01-26 dotNET跨平台

今天是 2023 年 1 月 21 日，农历癸卯年正月初一，新的一年开始了，祝大家：兔年大吉、大展宏兔、兔然暴富。

很多人都有一个惯性思维就是做加法，这样会比较“心安”，比如：看更多的书、学习更多的课程、让小孩刷更多的题、产品上添加更多的功能，似乎，多就是好。

为什么都爱做加法呢？

在少楠的知识资产中看到，人们爱做加法的原因多半是出于：

首先，我们默认在日常的事物中一切都是「合理」的，不需要减少。比如我们很少会怀疑教科书上有「冗余」的内容，或者使用的工具有什么「多余」的部分。

再次，损失厌恶。毕竟做加法没有什么损失，但是如果要做减法，就得做出断舍离的决策。所以人们默认会倾向于获得更多，而不是舍弃一些。

最后，做加法的效果容易感知，比如多读了一本书，多记了一条笔记，那么很容易感觉到「积累」。但如果少看了一本烂书，删掉了一些无用的东西，这种「减法」的好处很难直观地感受到。

而我决定在 2023 年要做减法，做减法可比做加法难多了，意味着要有更多的思考、更多的断舍离。

这个减法可以体现在很多方面，比如：个人成长、产品功能、代码架构。

个人成长

现在信息摄入的途径和内容都非常多，眼花缭乱。要很笃定的知道自己需要什么，然后把信息消化吸收后变成自己的养分。

所以，这里的减法是指内容的处理和消化。只吸收不消化，跟捡垃圾没什么区别。

枝叶需要进行修剪才能长得茂盛、铁路线越来越多，也需要合理规划、并站才能高效地进行调度，所以信息的获取不能一味的进行增加，还需要我们抽出来时间进行修剪，把核心的部分加强连接，把无用的节点删除或合并，才能让我们信息慢慢转化为知识。

我现在的信息摄入途径有：

• 书籍：纸质书、电子书、樊登读书、读库；

• 社交媒体：即刻、知乎、豆瓣、B 站、小宇宙；

• 专业 APP：极客时间、得到；

• 其他：公众号文章、订阅的 RSS 和 Newsletter 。

2023 我想这样来做减法：

• 不设置读书目标，养成每天都看半个小时或一个小时的习惯；

• 看过的内容要思考做笔记和回顾；

• 尽可能地多输出、多和不同的人交流；

• 定期梳理笔记、抽取主题、形成文章。

个人成长的减法并不是说减少输入的途径，而是增加中间的处理和思考的过程，让积累的东西慢慢变少，沉淀出来自己的东西慢慢变多。

产品功能

做产品也是一样，要做减法，很多时候冷静思考，沉寂一段时间后，发现很多原先紧急的需求都可以不用做了。

为产品做减法，首先就是要搞清楚产品的定位。

定位不准确，就很容易什么功能都想加，加到最后就变成四不像了，看着什么功能都有，但又都没有做到极致，甚至互相之间还是矛盾的。

假如产品的定位是做一个给开发人员提升效率的低代码平台，明确了这个目标，就很容易知道哪些是可以不做的，比如：

• 完全配置化，不考虑二开；

• 按业务人员使用的视角去设计产品功能。

哪些是需要做的也很清晰：

• 能减轻开发的、重复性的操作，实现配置化；

• 提供各种批量操作，比如批量修改表单控件的属性；

• 提供二开的辅助调试工具，自定义组件、在线脚本能够更好地进行对接和排错。

产品功能的减法不是说啥功能也不做了，而是搞清楚哪些是可以不做的，该做的还是要按照正常的节奏去迭代。

代码架构

在产品的代码构架上会存在两个问题：

• 初学者使用复杂的架构解决简单的问题，而出现学以致用的幻觉；

• 因为各种「紧急」，而在项目中添加各种临时补丁或重复代码，通常被称为「技术债」，这些「技术债」会在以后有时间就处理，正常情况以后都不会有时间。

越简单的东西越容易理解，越不容易出错，所以在产品架构中要避免出现过度设计，架构方案需要进行评审。

上面提到的技术债，其实也是有时间处理的，比如，你们采用的是敏捷开发模式，在一个迭代周期内，所有人都是为这个迭代目标而冲刺，那么在迭代版本发布前，某些开发人员的开发任务已经完成，除了可以参与测试之外，还可以处理这些「技术债」。

代码架构的减法是通过这个减法让产品代码始终保持在一种合理的状态，毕竟，合适的才是最好的。

最后

加法容易，减法难，那么选择难的这条路，必然会结出更艳丽的果实。而你也会因为走了这条难的路而更加光彩夺目。