最少的代码，最好的框架

最少的代码，易于阅读

在神话和传说中，人类聚集了整个家庭的力量，建造了一座高耸入云的巴别塔. 上帝害怕它，它使人们的语言混乱，使人们无法相互交流和合作. 走，只在地上留下一片废墟.

可以看出语言对于合作具有重要意义，所谓的工程学就是人们之间为实现目标而进行合作的参考.

但是作为软件工程，人们常常忽略了合作，语言和代码可读性的基础.

从常见的mv *系列到新颖的flux体系结构，其目的之一是更好地组织代码，对代码进行分类并提高其可读性. 他们每个人都有自己的想法和概念，但是唯一可以普遍使用的真理是: 代码越少，理解就越好.

当一长串英语句子摆在您面前时，您需要消化一会儿.

在您面前摆着非常冗长和冗长的代码时，您可能无法理解！

最少的代码，易于维护

在维护一段代码（尤其是其他人的代码）时，大脑需要缓存最肤浅的抽象代码，而不必记住底层的琐碎细节. 这也意味着对于使用完美框架的程序，至少我们不需要关心框架中的代码，因此我们可以掌握更多产品功能. 但这也意味着即使是最好的程序员也可以维护数量有限的代码.

因此，更少的代码，更多的语义和更多的功能才是正确的出路.

如果说四个字“天狗日食”，那比“神奇的狗飞过天空，点点吃着烈日……”要好得多.

最小代码是可靠的

由经验丰富的程序员编写的代码比新手有更少的错误. 除了缺乏技能外，还有更多的逻辑错误，意外错误和深思熟虑的错误.

在逻辑技能上老程序员比新程序员好吗？

实际上，这是一个熟练程度的问题，因为各种陷阱都有相应的“正确”和“未编写”代码模式或习惯，可以避免出现问题.

这些技能不是语言本身的特征所赋予的，而是与诸如最佳实践之类的经验性演讲更为相似. 它们分散且琐碎，自然很难覆盖所有内容.

此外，您必须知道所有系统都必须存在错误. 该系统越复杂，漏洞就越多，仅是隐藏和公开之间的区别.

使用许多技术来避免错误的发生远胜于仅使用少量代码的简单，粗鲁的功能实现. 就像最简单的陈述一样，主语，谓语和宾语这三个词一目了然. ，错误的可能性自然很小.

最少的代码，灵活的

易于实现左右框架代码，需求的变化自然容易接受.

复杂性隐藏在看不见的背后

两个人抓住了斧头，砍伐了森林中的树木. 老人教年轻人: 力量在脚上，抬到腰部，最后在手腕上，落在树上，寻找其线条，而不是深或浅，笔直和笔直……，其技巧不可可以使用三年了，长者砍了两棵树，而年轻的还没有砍掉一棵.

但是，如果是手持电锯，技能自然就存在了，但是即使是那些一无所知的人也可以忽略砍伐树木. 那个老人轻蔑而愤怒.

因此，作为斧头伐木工人，我们应该对“非熟练”电锯工人表示不屑吗？

不是真的.

我们看到的只是最终结果，在此之前左右框架代码，为了制造出有用的链锯，其背后的整个产业链需要比使用斧头技能更多的技术.

业务的复杂性并没有消失，而是转移到了看不见的事物的阴暗面. 我们使用精心设计的工具来代替同样细致但大量重复的直接生产产品.

-这也是一个抽象.

概念本身只是一个节点. 当我们提到这个节点时，它驱动着整个意义背后的网络. 类似于编程，特定而琐碎的代码本身是一个混乱的整体，提供给人类的API是节点，它也是抽象的最终产品和应用程序的直接对象.

API是概念.

从某种角度讲，设计语言是设计API；设计框架是相同的.

小型零碎的概念交织在一起，形成了广泛的更高层次的概念；琐碎而详细的代码作为清晰的API公开.

工人要想做得好，必须首先完善他们的工具.

所以我说，最好的框架必须是最少使用的代码.

至于如何编写最少的代码？我认为，

DSL（特定域语言）目前是一种好方法.

有关详细信息，请期待“域特定语言·DSL概述”.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-289386-1.html