经历过学生时代，我们知道 “年级” 能在一定程度上能反映知识的多少，
教材是按照年级来编写的，
要想学二年级的课程，必须先学会一年级的内容。
小学、初中、高中，都是如此。
可是到了大学，课程安排就变得不一样了。
每个学期，都会开设好几门课，
各个学期课程之间的依赖关系，并不明显。
似乎每门课我们都只学了一年级的内容。
因此，到了大学，并不是门门课都学好就够了，
还应该选择感兴趣的领域，深入系统的学习下去。
在进行软件开发的时候，我们经常会听到 “层” 的说法。
比如，上层应用，底层原理，
仿佛是越底层，对人的要求越高似的。
其实并非如此。
因为，软件分层并不划分 “年级”，
每一层更像一门新的课程，
每一层都有自己要解决的问题，是一个全新的领域。
盲目的追求更底层，
就像大学期间一口气学了数十门课程，每门课都浅尝辄止。
分层架构
“分层架构”（layered architecture）是软件架构模式architectural pattern中的一种。
在《Software Architecture Patterns》一书中，对 “分层架构模式” 是这样描述的，
Components within the layered architecture pattern are organized into horizontal layers, each layer performing a specific role within the application.
可见，“分层” 是针对于某一特定的应用而言的，
是各组成部分（components）之间的一种组织形式（organized），
当然还有其他的组织形式。
“分层” 有利于层次间的 “职责分离”，也有利于管控层次间的 “信息” 交互方式。
每一层只需了解下层，并为上层提供服务即可，不需要了解其他层次的更多信息。
这样就减少了这些层次的开发和维护成本，也更有利于划分问题的责任边界。
《Clean Architecture》中提到，
Software architecture is the art of drawing lines that I call boundaries. Those boundaries separate software elements from one another, and restrict those on one side from knowing about those on the other.
每个层次，都有自己的调用方和服务方，
所考虑的都是，如何在现有条件下，满足上层的需要。
并没有谁更难、谁更重要这么一说。
间接性
计算机科学领域的任何问题，都可以通过增加一个间接的中间层来解决。
这句话称为 “软件工程基本定理”（Fundamental theorem of software engineering），
最先是由 Andrew Koenig 提出来的，原话是，
We can solve any problem by introducing an extra level of indirection.
我们看到，原文中并没有提到 “中间层”，而是说 “indirection” —— 间接性。
如果直接处理问题比较困难，
那么可以考虑先处理另外一个有帮助的问题，以降低难度。
这也是解决问题的一种办法，磨刀不误砍柴工。
《计算机程序的构造与解释》中的一段文字，能引起我们的反思，
计算过程是存在于计算机里的一类抽象事物，在其演化进程中，这些过程会去操作一些被称为数据的抽象事物。人们创建出一些称为程序的规则模式，以指导这类过程的进行。从作用上看，就像是我们在通过自己的写作魔力去控制计算机里的精灵似的。
那么是否提供间接手段的人，比利用间接手段解决问题的人更强呢？
这也不一定。
磨刀工人，是不是比砍柴工人，要求更高？
提供间接手段的人，也不是从零开始的工作的。
他们的工作也是在别人的工作之上完成的。
每个层次都有自己的工具箱，并不需要自己造这些工具。
底层原理
还有一个人们经常提及的概念，就是 “上层” 和 “底层”。
In object-oriented design, a layer is a group of classes that have the same set of link-time module dependencies to other modules. —— layer
所以，“上层” 和 “底层” 其实是在说依赖关系。
链接依赖体现了当前文件，用到了哪些其他文件提供的功能。
如果某个文件被层层依赖，位于依赖树的最末端，那么它就更 “底层” 了。
那么，写 “底层” 依赖的人，水平就更高吗？
诚然 “底层” 的功能失效之后，影响范围更大，
但是 “上层” 也有责任对依赖方进行管理。
各自都有不同的职责范围，关注点不同罢了。
结语
功能被如何 “使用”，与功能是怎样 “实现” 的，是两种不同的知识。
两者没有必然的关系。
了不了解 “实现”，跟会不会 “使用”，是两码事。
前者可以是一种手段，但不是必需的。
我们始终应该考虑的是，用什么工具，解决什么问题。
而不是总好奇工具是怎么造出来的。
工具，是工具制造者，用其他工具制造出来的。
追求底层，还会有更底层的知识要去学习，
然而，这些知识对于当前领域，帮助其实没有那么大。
按照这种习惯，即使真的投入到下一层次的工作之中，
又会被更下一层次的 “实现” 所吸引了。
仍然疲于奔命。
所以，渴了喝水就好了，别管水的化学成分了。