文档即编码(四)：编码的实质-表述与合作

   本章为对之前的章节进行一个小结，并对后续展开进行一个铺垫。   

   在平时的编码中，都要求按照所谓的代码规范、开发规范、代码提交规范，并会编写相应的手册以及通过代码扫描等手段防止有违规的现象出现，并且有些公司还会通过测试用例、代码Review等手段，保证其编码的质量。

    当然，以上所述的方式、方法，都是通过长年的经验积累而成，并且根据各个公司不同的情况而有所调整。为达到代码质量的保证，需持续进行以上的工作，并投入大量的人力，且需时时改进。

    我们为何需要花费如此的人力、无力、时间在保障代码质量这件事情上？教科书式的答案告诉我们是：可维护、可扩展、可复用等，而且可以列举出一系列的理论与案例。但我个人认为，理由只有一个，就是能够让大规模的技术人员进行灵活的合作。

  在《未来简史》中，作者认为人类只所以能够与别的生物与众不同，且如此特殊，是因为人类能够进行灵活的合作，往往能够高效合作的组织能够胜出。

  如Linux内核，至今有许多不同的组织或是技术人员，为其贡献了大量的源码，而且这些技术人员可能互相不认知，能够基于这样大规模、长时间的源源不断的开发方式的基础，就在于其内核本身的设计为技术人员提供了这种合作方式。

   对于其它项目或系统来说，则希望通过制定一系列的标准、规范、流程，甚至还需对参与的人进行相应的培训工作，来获得如此的效果。然而以上种种的方式，经过长期的经验证明，多数最终的效果不算理想。如果“灵活的合作”为“道”的方面，则上述所说的方式则为“体”或是“术”。现问题是我们认为的那些“体”、“术”随着时代的变化，是否已经和“道”渐行渐远，或是一开始就错了？

    经过不同时代的发展，其管理方式在不断的演进，而个人认为编码与管理有相同之处，其相应的理念和技术也在不断改进。对于编码来说，所谓的管理就是系统、模块、功能、代码的组织、划分，就如同企业的组织划分。其目的就是为了保持灵活性，以及快速响应。而如何使其达到灵活性、快速响应，则需大量的技术人员能够高效的合作。

    我们知道，在开发一个系统或某个功能时，大部分的时间都花在沟通上，敏捷管理中的很多方式、方法就是为了加强沟通。之前文章中提到的信息树就是为了解决沟通问题，其提供了一种统一的业务描述方式(如领域驱动设计的统一语音)，而且不是仅仅技术人员间的沟通，而是在业务、产品、技术、测试中进行沟通，这样为不同的人员提供了高效的沟通方式，而且其屏蔽了自然语言不精确的问题。

   由于信息树是树的的结构，其可转变为森林，或是把森林变为树，当然这是从业务角度，而不是算法角度。其提供了一种高效的模块划分，或是功能划分的方式，且信息树关注的是有哪些逻辑点，而不是逻辑的具体实现，这便于技术人员进行大规模开发。这就如同把大象放进冰箱，其关注的是有哪几个步骤(打开冰箱门、放进冰箱、关上冰箱门)，而不是每个步骤的具体实现方式。（具体的实现方式，可参考https://www.jetbrains.com/mps/）

   当然其相应的具体技术实现方式，还需不断的摸索，在之前的文章中，给出了关于数据读写的案例，此也是基于领域驱动设计的思想。其实编写代码与编写文章类似，如需要划分章节，各章节如何承上其下，而且代码本身就是最佳的文档，其代码规范也是为了提高其可读性，但其无法体现其具体的业务逻辑，这还需要技术人员花大量的时间了解业务逻辑，而且由于技术人员经验、认知的不同，即使相应的业务逻辑，也有多种实现方式。

    信息树的目的，其实就在于对业务的沟通、设计标准化、规范化，这就如同逻辑符号，各种语言的规范，其本身既是文档又是编码，达到灵活、高效的目的。