近期，技术界围绕“代码认知负荷的降低”展开了热烈讨论，这一讨论源自一篇题为《认知负荷才是关键》的文章。该文章迅速在Hacker News上走红，引起了技术社区的广泛关注。
文章的作者Artem Zakirullin，是一位拥有超过13年软件开发和工程经验的资深软件架构师，目前担任Inktech公司的CTO。文中，他从一个开发者“脑容量”的角度，深入探讨了写代码过程中认知负荷的重要性，指出编写易于理解的代码比追求高级架构或酷炫技术更为重要。
认知负荷，指的是开发人员为完成任务所需承担的思考量。它关乎于完成任务时所需动用的脑力及注意力。尤其是阅读代码时，需要将变量值、控制流逻辑和调用序列等内容装入脑中。普通人的记忆力大约能容纳4个这样的构建块，一旦超过这个阈值，理解难度便会急剧上升。
设想一下，接手一个完全陌生的项目并进行修复。面对前任开发者留下的复杂架构设计、花哨的库和流行技术方案，不仅要理解项目逻辑，还要消化这些复杂的设计决策，这就是典型的高认知负荷。
Zakirullin将认知负荷分为内在负荷和外在负荷。内在负荷源自任务固有的难度，无法避免；外在负荷则由信息的呈现方式导致，与任务本身无关，是可以降低的。
为了减少外在认知负荷，Zakirullin结合开发中常见的“认知雷区”，给出了实用的建议：
1. 避免复杂的条件语句。复杂的条件语句会让代码难以阅读和理解，可以通过引入清晰的中间变量来简化条件判断。
2. 少用继承，多用组合。继承链会增加认知负荷，一处改动可能引发蝴蝶效应。组合则能更好地控制代码的复杂性和依赖性。
3. 设计深模块。浅模块虽然接口简单，但功能复杂，且接口相对复杂。深模块则隐藏内部复杂性，只暴露简单接口，便于理解和维护。
4. 限制语言功能的使用。丰富的语言功能虽然强大，但也会增加认知负荷。通过限制选项的数量，可以降低认知负荷。
5. 别滥用分层架构。分层架构的初衷是隐藏复杂性，但过度的分层会增加认知负荷。分层架构只有在需要明确扩展点时才有意义。
6. 正确使用领域驱动设计（DDD）。DDD本质是关于问题空间的思考，而非解决方案空间的代码设计。实践中应避免将其变成固定的文件夹结构、服务命名规则等。
7. 关注新人的认知负荷。当新人加入项目时，应衡量他们对项目的熟悉程度。如果他们在短时间内无法理解代码，说明代码中存在需要改进的地方。
降低认知负荷，不仅能让开发者更轻松地理解和维护代码，还能提高新人的工作效率，使项目更加友好和可持续。
