美好的一天，我从事编程已经有8年了，并且以各种形式进行编程：以不同的编程语言开发服务器端，开发客户端，对网络编程，管理linux以及优化性能。 当您忙于长期从事业务，真诚地热爱自己并努力发展自己时，不可避免地出现了相应领域中的各种因果关系，您会开始发现那些您以前根本不了解的关系，或者只是认为它们无关紧要，这就是人们所说的体验。
在本文中，我想与您分享这些因果关系中的一种。 我想写这是最重要的因果关系之一，以便不那么激进，但仍然不是，这种因果关系是编程中最重要的因果关系。 它几乎在所有编程领域中都像线程一样运行：编写代码，设计界面，部署应用程序，组织团队，维护错误跟踪器等等。 我把这种神圣的因果关系称为
变量的
最小化 。
变量一词不仅是指普通变量（通过
var ，
let ，
function关键字声明），而且还具有更抽象的含义：在项目树中创建的文件夹，连接的库，对服务器的Ajax调用次数，数量接口中的组件，程序员在提交代码时应遵循的协议数（例如，代码审查，每个单独的早午餐中的每个功能）等等。
实际上，整个编程过程是在如何使用尽可能少的变量（至少从这个角度来看编程）的情况下实现该功能或功能的方向上的各种枚举。 实现具有较少依赖项/文件/代码行的功能的代码比实现具有大量变量的相同功能的代码更好。 如果某个实用程序类仅包含一个函数-如果该函数仅包含一行，则需要摆脱该实用程序类；如果该组件中只有10行代码，则需要摆脱该函数-如果文件夹中只有一个文件，则需要删除此组件-您需要删除该文件夹，依此类推。 当将数千个看似微不足道的更改加在一起时，结果就是美观，简洁和简约的代码，非常易于阅读。 他们说的是细节。
这是基于最小化变量原理开始编程时会出现的积极影响的列表：
- 更少的错误。 由于编写的代码更少，因此可以减少出错的地方数量也相应减少。
- 向项目介绍新人会更容易。 项目的复杂性与该项目中变量的数量成正比，变量越少，介绍新人就越容易。
- 易于添加新功能。 由于有必要研究少量的代码，因此将功能“加载”到头部变得更加容易，结果添加了新功能或修改了现有代码。
- 可预测性。 编程过程变得更加可预测，由于“堵嘴”的数量减少，您可以更轻松地预测开发一个或另一个功能所需的时间。 通常，是由插头引起最多的问题，并导致截止日期的延迟。
但是通常情况恰恰相反，程序员开始通过引入新变量来主张自己。 我们引入20种不同的库，CSS框架，创建大量的多层抽象（例如
UserFactoryManager） （尤其是Java程序员出于某种原因而犯罪），创建太多目录，引入更多高级开发方法，在提交文件之前添加更多协议，等等。 这样的决定背后的动机可以理解，因为它造成了专业精神的幻觉，他们说要看我知道多少，以及我可以处理哪些复杂的抽象。 但这通常会对项目造成严重的伤害。
不要误会我的意思，我不反对使用更高级的方法，框架和技术，我只是说，引入它们的原因仅仅是因为大肆宣传，而不是因为这项技术解决了项目中的任何紧急问题。
解决变量过多的问题的方法可以称为“
过度设计” 。 但是您必须承认，如果将这种情况描述为好像问题通过过多的变量来解决，则这是对该现象的更准确的描述。
通常，新变量的引入是出于可伸缩性的考虑，他们说，如果您
在此处创建
UserManagerFactory ，那么我们可以在必要时随时采用并添加一个函数。 但实际上，可伸缩性不是在引入多个变量时而是在变量很少时。 考虑一下您在哪里更容易编写新功能：在chrome浏览器引擎中还是在从头开始编写的全新项目中？
引入新变量不会导致体系结构的可伸缩性。 真正提高项目可伸缩性的是删除不必要的变量并简化现有代码。
大量不必要的变量-这正是我讨厌具有强烈仇恨的Scala编程语言的原因，也是我喜欢JavaScript的原因。 Scala只是一个过于复杂，非常令人困惑的类型系统的精髓，许多概念彼此重复，隐式转换以及执行相同操作的大量方法。 当我使用这种编程语言时，我不是在考虑需要做什么，而是在考虑
如何做。 我现在经常发现自己，我的目标只是关闭编译器。 另一方面，JavaScript与Scala恰好相反，它在简约性上提高了一个数量级，使用它我花费了大量的精力来表达一个或另一个概念。 当然，这种简单性也有其缺点，例如，在Scala中，编译器会在编译阶段报告错误，而在JavaScript中，您只能在运行时识别错误，并且从根本上来说，JavaScript不能像编写强类型代码那样编写相同的功能性IDE。语言，但这是我准备和解的受害者。
设计界面时需要应用最小化变量的原理，例如，让我们比较两个竞争性社交网络的Web界面，以便约会
Tinder和
Badoo 。 实际上，在Tinder Web界面中只有一页，用户个人资料，活动聊天和对新朋友的搜索显示在一页上，无需切换到其他页面，在此界面中，所有用户需求都可以通过最少的组件来满足。 在Badoo上，切换到用户配置文件，消息界面和用于查找对的页面的功能被实现为单独的页面，而用户需要执行更多操作来满足需要，因此该界面的效率较低。 当然，这只是一个很小的例子，但是当有成百上千个这样的例子时，它们共同决定了接口是否被考虑了。
在设计界面时，有必要创建最少数量的组件以满足用户的需求。出于同样的原因，我绝对不喜欢将逻辑，数据和表示法分开的方法，因为在这种情况下，编写一种功能需要创建三个文件，然后组件的数量开始增加，并且当项目已经变大时，然后文件数量开始超过所有合理的限制。 例如，编写Web界面时，通常在单独的文件中描述样式，而将这些样式附加到的节点在另一个文件中。 看起来很奇怪，这种分离的主要动机是缩放，因此，如果将节点本身及其样式分离，则在项目中导航将变得更加容易，并且有可能独立开发功能的这两部分。 但是，让我们看看用这种方法添加了哪些变量：具有每个组件样式的新文件，选择器（它们描述了样式附加到的节点），级联规则（如果多个选择器指向同一个节点）。 虽然如果您直接在应将这些样式连接到的节点中编写样式（例如，通过style属性），则将不再需要所有这些其他变量，从而极大地简化了代码。 最近，这种方法变得越来越流行，有许多库可让您直接在style属性中编写样式。
应始终将新变量逐步引入项目。 例如，在一开始编写项目时，我将所有文件都放在根目录中，根本没有任何子目录，这仅仅是因为它很容易，并且只有当文件数增加到40-60个文件时，某些文件才被分组到目录中。 从一开始，就不需要开发方法论，只需将所有程序员扔进一堆，给他们任务，然后他们就会自己弄清楚，如果过早引入开发方法论，那会感觉像是一种替代概念。 在需要变量之前引入变量时，这称为过早优化。
同样，在编写文档/文章时，有必要使变量最小化，而在编写文档时，我总是在思考传达我的想法所需的最小句子数。 我逐字地分析每个句子，如果在我看来这句话不是必需的，它不承担任何额外的语义负担，则将其删除，结果获得了一个非常压缩的带有文档的页面，该页面在最小数量的文本中包含最大数量的必要信息。
实际上，总的来说，任何变量都有罪责感，除非证明相反，否则不需要任何变量。
您可以反对我，他们对我也说相同，发现了美国，这一点由来已久，并被诸如
Okaka razor ，
SOLID等原则描述。 但是我更喜欢将这个概念称为“变量的最小化”，只是因为这种解释在头脑中非常简洁，因此在实践中更容易坚持。 你们当中有多少人可以吹牛记住SOLID原理的每一点？
初学者编写简单代码是因为他们不知道如何编写复杂代码，普通程序员则只是因为可以编写复杂代码而已，因此专业人员可以编写简单代码，因为他们不想编写复杂代码。
应该记住，任何极端都是不好的：如果将变量最小化到原子级是狂热的，那么这种方法以及引入太多的变量都是极端的。 如您所知，任何极端情况都是不好的，事实总是介于两者之间。