作者：森与淵
链接：https://zhuanlan.zhihu.com/p/23984086
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
最少的代码，是易读的
神话传说中，人类集全族之力，欲修建一座巴别之塔，与天齐高，上帝畏惧，便乱了人们的语言，使人们无法互相沟通、通力合作，终是四散流去，唯留一座废墟在大地上。
可见语言对于合作的意义重大，而所谓工程，正是人与人之间协力完成目的的指称。
但作为软件工程，人们却往往忽略了合作的基础，语言，亦既是代码的可读性。
从常见的mv*系列，到新颖的flux架构，用意之一都是更好的组织代码，对代码进行分类，提高其可读性。它们各有各的思路和理念，但唯一颠扑不破、用之四方而皆准的道理就是：越少的代码，越好理解。
当一句很冗长很冗长的英文长句放在面前，你需要消化一会。
当一段很冗长很冗长的代码放在面前，你很可能就无法理解了！
最少的代码，是易维护的
维护一段代码，尤其是别人的代码时，大脑是需要对其最表层的抽象代码进行缓存的，而无需时刻谨记其底层的琐碎细节。这也就意味着，对于一个应用完善框架的程序，至少框架内的代码我们无需理会，从而能够掌握更多的产品机能。
但同时也意味着，即使是最优秀的程序员，所能维护的代码数量也是有限的。
因此更少的代码，更多的语义，更多的机能，才是正确的出路。
你说四个字“天狗食日”，就远远胜过“神异的猛犬飞跃过天际，将火红的太阳一口一口地吃掉……”等废话无数。
最少的代码，是稳健的
富有经验的程序员比新人写出来的代码要少很多bug，除却技能的不足之外，更多的是逻辑性的、没想到的、思虑不周的错误。
难道老程序员的逻辑能力就比新程序员要好吗？
其实是个熟练度的问题，因为其中种种陷阱，都有对应的“较正确的”、“不成文”的代码模式或是习惯，可以避免问题的发生。这些并非语言自身特性所赋予的技巧，更类似于最佳实践之类的经验之谈，是不成体系和琐碎的，自然也是难以面面俱到的。
更何况，要知道，凡是系统，必有bug。越是精密的系统，也越是会有漏洞存在，只是潜藏的和显露的区分罢了。
用那么多技巧去避免bug的产生，远远不如简单粗暴的只用少量代码实现功能来得好，就像是最简单的陈述句一样，主谓宾三个词，一眼看过去就明白意义，出错的可能性自然很少很少。
最少的代码，是灵活的
实现起来容易，对于需求的更改自然也就容易接受。
复杂度隐于不可见的背面
二人持斧，于林伐木，长者教导青年说：力发乎脚，提于腰身，终于手腕，落于树木，寻其纹路，不深不浅，端正不斜……洋洋洒洒千言，其技巧非三年不可得，长者伐二木，而青年一木未毕。
但若是手提电锯，技巧自然也是有的，但即使是一窍不通者，也可于疏忽间伐数木。长者不屑，愤愤然。
那么，作为斧头帮伐木者的我们，就该对“毫无技巧”的电锯工作者表示不屑吗？
其实不然。我们看见的只是最终的结果，而在此之前，为了制造好用的电锯，其背后的整个产业链，所需的技术含量不知超过用斧技巧多少。
业务的复杂度并没有消失，而是转移到事物不可见的暗面，我们用精心设计工具这一行为，取代了同样精心却大量重复地直接生产产品的行为。
——这亦是一种抽象。
概念自身只是一个节点，当我们提起这个节点的时候，带动地是背后一整张意义网络。类比于编程，具体琐碎的代码本身是一个混沌的整体，而提供给我们人类的API才是节点所在，亦是抽象的最终产物和应用的直接物。
API就是概念。
从某种角度说，设计语言就是设计API；设计框架亦如是。
零碎的小概念，交织成宽泛的、更高层次的概念；琐碎的、细节的代码，暴露为意义明确的API。
工欲善其事，必先利其器
所以我说，最好的框架，用起来一定是最少的代码。
至于你问怎样才能写最少的代码呢？我想，
DSL（领域特定语言）是目前不错的道路。
详情请期待《领域特定语言·DSL概述》吧。
