6个问题帮你构建逻辑，弄清楚如何运行代码的过程了解软件开发中的重要模式

图片来源：Aphinya Dechalert

对很多初学者来说，编码就是编写ifelse的语句，试图弄清楚如何运行代码的过程。在这一过程中，编码就变成了一个令人费解的庞然大物，其出人意料的曲折情节堪比《权力的游戏》。

代码越多并不意味着代码越好。当然，在写代码的时候还是很有意义的——直到回过头来，解开无意中创造的神秘小说，才发现不明确的方向、结构和主要情节的漏洞阻碍着线性发展。

当开发人员不了解某些知识时，就会出现错误，这些错误主要是源于不了解代码中高效的模式。哪怕生成的代码已经运行了，结构遗忘的喜悦仍在持续。但随着时间的推移，事情过于混乱带来的挫折感也就随之而来。

以下问题有助于你构建逻辑，了解软件开发中的重要模式。

函数式编程如何？

大家非常喜欢面向对象模式的理念，但函数也存在于类和方法中。函数式编程基于给定情况处理数据，强烈厌恶依赖性。

依赖关系并不是坏事，但太多的依赖关系会导致不必要的蜘蛛网。

依赖项引入所导致的连锁效应会降低代码的模块性。依赖前一项正常工作，创建一个串联电路效果。

函数式编程模式可将代码转换为独立存在的一系列并行状态，增加了模块化——这是隔离和构建清晰逻辑域的方法。代码模块化时，崩溃不会频繁出现。

依赖关系也可存在于函数本身，创建了逻辑隔离，也仍会产生冗余，通常以不同名称下的重复值、循环中的循环或嵌套逻辑的形式出现。如果出现这种情况，快的修复方法是压缩逻辑并将其抽象出来。

是否需要公开？

并不是一切都必须是全局状态或作为公共功能存在。有时，代码隐私是件好事;可以防止范围蔓延，提高变量安全。

将所有内容公之于众很容易，但这不是可访问范围的重点。

当内容都公开时，服务和工厂内部的代码很容易受到外部可变性的影响，会增加变更范围，超出潜在预期情况。

在JavaScript中，技术层面上，所有变量、函数都是全局可被访问的。但随着TypeScript的出现、增长和广泛使用，公共变量和私有变量有了明显的区别，函数使得代码能够抵抗不必要的访问和更改。

过度抽象还是不够抽象？

编写业务需求时可能会忘乎沉迷于模块化的概念或过度专注于捕捉一个复杂的想法。

试图使代码过度模块化时，就会导致过度抽象，因为我们总是被告知这就是做事的方式。面临一组复杂规则，还未能搞清楚如何进行简化时，就会导致不够抽象。练习到后，抽象实在是太耗脑力无法重构或已经没有时间了。

那么，怎么的度才是合适的呢？

抽象是为了提取出可重复代码的明确边界。度计划潜在使用，或不在不同的范围空间中反复编写相同逻辑时，抽象的度就是合适的。

通常，嵌套是不够抽象的个标志。多次注入和调用多个外部函数是过度抽象的关键标志。