为了快一点，我们却要慢一点。

    ​爱因斯坦说，教育就是“把学校里学到的东西忘了后”剩下的东西。那么，如果真的习得了教育，那么，从科班到丛林，只差一个隐藏信息积累的过程，这是可以通过大量实践来达到的。头脑的灵活是不会因为环境的变化而改变的。而如果在教育中得到的只是信息，而没有磨练出能力，那么在丛林中，将举步维艰。

    ​​将代码分层，是为了控制复杂度，让你的管理更加有条理。那为什么非得要建立多个不同的独立文件夹，再创建不同的文件呢？

     ​一个直接的考虑是，在同一个文件下，也就是同一个文本环境之下，当然会有非常大的自由度去增添代码，没有任何的条款限制。但同样是因为这样的“自由”，它会让管理处于失控。因为控制复杂度，就意味着将多个不确定性的东西固定下来，就需要有强制性的限制，而不是自由。有了更多的限制条件，才能让你控制的主体按照你的思路去发展，去向同一个方向用力，而不是散沙一团。这是一个经典的因为有了更多的局限性，反而让系统发挥出更强大的力量的例子。正如山路赛车，为了更快一点，就必须要用更小的马力。

     ​所以，为了让你的“UI部分的代码成一堆”，“数据连接的代码成一堆”，“业务逻辑的代码成一堆”，你必须给予这些部分强硬的限制，让它们只能在特定的范围内出现。这就需要创建不同的文件夹，以及不同的源代码文件。其背后的思维方式是：要用制度去控制组织，而不是依赖组织中每个成员的自身素质；要用代码去控制流程，而不是依靠脑海中的行为规范。

    ​ 另一个需要提到的优势是，通过不同的文件创建以及不同文件夹的划分，可以很好地解决名字冲突。每一个模块都可能提供一些相同的功能，但却需要不同的实现。如果你将所有这些“具备相同功能但需要不同实现”的函数放在同一个文本环境下，你将难以区分这些函数，并且会造成冲突。你当然可以通过增添前缀的方式来解决冲突，但这样会造成函数名的臃肿。但更为关键的是：如果你真的写过稍微复杂一点的系统，你会发现在“数量庞大的一堆没有分类”的文本中寻找一个代码片段是件多么让人焦躁的事情！你完全无法在一堆字符中自然地观察到内在的一致性和规律性。而这种“混乱”以及由此产生的焦虑，正是你控制复复杂度的原因。

     ​同样的现象还可以在数据处理中发现。如果你是通过Excel去处理简单的数据，你会发现它非常灵敏好用。可是，一旦数据之间的相互依赖关系有所增加，并且还有其他合作者的参与，崩溃的事情就会发生。你会发现，正是因为它的类似于一张白纸的高度灵活性，你发现你竟然难以将你们商讨的“规则”强制性地实施在表格之中。为什么？因为你缺乏限制，缺乏代码为你勾勒出的硬性框架。你可以任意地修改一个单元格的内容，也可以轻易地增添一些附加信息作为旁边的备注。假以时日，你会发现你的表格中的信息混乱不清。虽然你已经早已向你的同事、你的朋友说明了该做的事情和不该做的事情，可是，这毕竟是软性的东西。违反这些规定，并不会给予违反者以压力或惩戒。同时，它灵活的增添功能，让很多数据依赖关系成为了一纸空文。

     ​Programming，如同任何的实务实践领域，一个首要的基础是大量地建立你的工程实践经历，这是一切的前提。如果没有真正的实践经历，很多业界的行为规范和行为准则是无法被正确理解的。如同上面所举的例子，如果你的代码复杂度不能跨过一定的基准线，你是无法真正体会到“创建不同文件夹和不同文件”的强烈需求的。对于toy program来说，增添不同文件行为方式，反而会减少代码的可读性，让代码晦涩难懂。从入门者的内心来说，在这个层面的是无法理解它的好处的，因而也就无法知晓它在何种情况下才能被称之为好。并且，一个附带的坏处是，你往往不敢或者难以承认你无法理解“将代码分裂在不同文件的好处”。因为几乎所有有经验的从业者都会告诉你，这样做是好的。一旦应该被提出的问题被忽略，那么你将再也无继续深入，真正去理解背后的“所以然”。

     ​另一个容易让你停留于表面无法做出真正评判的要点是，你会片面地去理解一些术语，如刚才提到的“灵活性”或“局限性”。就字面意思来看，当然是越灵活越好啊。可事实是，如同上面的论述，“灵活”与“局限”从来不是孤立存在的，也不是被孤立地评判的，它是需要有“语境”的，是由你的实际问题的规模和目标所决定的。如果你的任务不是太复杂，或者仅仅是停留于头脑风暴的设计阶段，上帝视角的灵活性（也就是白纸式的灵活性）会给你带来巨大的优势。另一方面，如果你需要建立某些规则，那么你应当建立一些框架去做限制，让“局限性”成为你控制复杂度的强大工具。

    ​ 更进一步，如果你讨论的“语境”是代码重构，或者集中于框架建立，“灵活”与“局限”的意思或者效果又会颠倒一转。在你的框架构建中，你需要找到的是一种合理的组织方式，使你的系统能够灵活地增添新的代码。而不至于被“糟糕设计”绊住：难以找到一个合适的位置去增加代码，因为似乎每一个代码片段都有着特定的限制性，一旦增加新的片段，就会破坏原有组织。在这种情形之下，“灵活”就成了值得追求的目标。

    ​ 那么，有了以上两段讨论后，一个直接的问题是：那我如何知道何时该追求“灵活”，何时该追求“限制”呢？或者更一般地说，如同生活中的矛盾说法“胆大/鲁莽，严密谨慎/畏首畏尾，多才多艺/三心二意”如何知道该追求什么？又该如何知晓在什么情况下、运用什么样的特性或品质呢？答案即是：大量的实践！如果考察丛林生活与科班环境，它们最大的分界点便是对于这些潜在规则的判断。无论你是学富五车或者具备多深厚的理论建树，如果你没有在特定的领域中积累足够多的实践经历，你将无法去获得潜藏在背后的规则信息，或者真正明白术语背后的具体所指、业界规则的前提条件、看似简单的业务逻辑背后所隐藏的坑。而这些潜在的东西，才是在丛林或者社会生活中生存的重要资本。