文章深入探讨了开发者在编写代码时面临的“认知负荷”问题。认知负荷，简单来说，就是完成一项任务所需承担的思考量，即需要动用多少脑力、占用多少注意力。尤其是当阅读代码时，开发者需要将变量值、控制流逻辑、调用序列等内容全部装进脑袋里。普通人能够支配的记忆力大约只能容纳4个这样的构建块，一旦认知负荷超过这个阈值，理解难度就会陡增。
Zakirullin将认知负荷分为内在负荷和外在负荷两种。内在负荷源自任务固有的难度，是软件开发工作的核心所在，难以避免。而外在负荷则由信息的呈现方式导致，与任务本身无关，如个人编程习惯等，这部分负荷是可以大幅降低的。
Zakirullin主张，应尽量减少项目中的外在认知负荷。他结合开发中常见的“认知雷区”，给出了一系列实用的建议。
首先，针对复杂条件语句，他建议避免使用令人费解的脑筋急转弯式代码。例如，对于一连串的条件判断，可以通过引入清晰的中间变量来简化逻辑，使代码更加易于理解。
其次，对于继承链导致的认知负荷问题，他建议少用继承，多用组合。继承链往往会让代码变得错综复杂，一处改动可能引发连锁反应。而组合则可以让代码更加灵活、易于维护。
他还指出，开发界流传的一些常规习惯，如“方法应该少于15行代码”或“类不能太大”等，实际上并不总是正确的。他强调，浅模块（接口复杂但功能简单）比深模块（接口简单但功能复杂）更难维护。因此，他建议设计深模块，隐藏内部复杂性，只暴露一个简单的接口。
在编程语言的选择上，Zakirullin也给出了提醒。虽然丰富的语言功能令人兴奋，但过多的选项也会增加认知负荷。他引用Go语言主要设计者Rob Pike的话：“要通过限制选项的数量来降低认知负荷。”他建议开发者在选择语言功能时要谨慎，确保这些功能彼此关联、易于理解。
同时，他还对分层架构和领域驱动设计（DDD）提出了自己的见解。他认为，分层架构只有在需要明确扩展点时才有意义，否则只会增加额外的认知负荷。而对于DDD，他强调其本质是关于问题空间的思考，而不是解决方案空间的代码设计。许多团队在实践中误解了DDD，将其变成了固定的文件夹结构、服务命名规则或对“Repository模式”的机械化崇拜，从而增加了不必要的认知负荷。
最后，Zakirullin建议，每当有新人加入项目时，应尝试衡量他们的认知负荷程度。如果新人花了很长时间还是一头雾水，那么肯定意味着代码中存在需要改进的地方。他强调，保持较低的认知负荷水平对于新人的快速成长和项目的顺利推进至关重要。
