摘要：尽管云不强迫任何文件或使其更容易执行，也有聪明的方式使用云的应用程序的功能和Web服务协议，使更多的现代系统自我记录，称为空中书写，并在您未来的云项目中执行。

　　从未有过关于不评论代码或记录系统的好借口，尽管这样做其实有利于压缩成本以及提高测试驱动开发的质量。但是让我们正视它吧，记录系统是并非完全一无是处，它不会甩给你不可维护的安全代码。
　　
　　不幸的是，在云计算中的工作又给了开发者们一个新的借口：“我没有权限访问或控制（公共云）服务，所以我不能记录任何东西。”
　　
　　所以，您可以用这种方式来揭穿他们：所有（公共或私营）云服务的消费者都需要文件服务，他们如何使用，使用者需要使用或依赖哪些行为方式（包括bug和错误条件）。随即，他们就会声称：“但这样就意味着必须在我们使用的每个模块都使用相同的云服务文件。”你的反应是什么？“把你的文件信息放在维基、谷歌文档、抑或是其他协作系统，使得整个开发团队可以访问。”
　　
　　这将推动大家都来使用外部接口并依赖模块和服务最佳实践方案：一款集中的数据库，其内容需要创建和开发团队的每个成员都来维护——采取分布式。根据我的经验，只有两点可以替代一个集中的团队负责创建和维护数据库，实体关系模型，业务流程的描述，或接口文档：一个是不需要存储的文件；过时的或经常出错误的文件。
　　
　　但维基是否是存储内部模块或变量文案最好的地方呢？尽管这不是个坏主意，但大多数时候，开发商不在文件存储区域的时候，就会成为黑客代码或在一款应用程序中调整变量。当他们进行代码工作时，在线评论必须不仅仅被鼓励：其必须进行测量。对于我们开发的代码，我们不允许任何模块被登记到系统中，除非至少有10%的线路是明确的意见，另外10%的属于在线评论。内联代码要求双倍于测试模块，因为很难猜测其测试的是什么特定的路由，以及出现故障时，到哪里寻找被测试的模块。你的代码集成系统可能已经有计数器和执法机制，但是如果他们没有，通常您可以使用脚本来做。
　　
　　在一些云应用程序和框架内，有一些脚本、工作流程和公式语言不支持评论，但总有一种方式通过不起作用的包含文件信息的代码片段植入评论（例如，如果0=1，评论发布在此——也许只要80字节）。
　　
　　因此我们删除了所有不评论代码的借口。不过，以现代云为基础的应用程序，大部分的运行动作不在代码：其声明式编程和定制领域/对象/关系。在此，您存储的文件必须经过开发人员和管理员明确的测量。在如Salesforce.com的系统中，每一个新的领域都有两个机会进行自我文件描述：描述区域，和信息帮助区。我鼓励对每种信息均使用这两种不同的自我文件描述。如果一个云系统不具备这一点，我们使用虚拟领域隐藏真实领域的名称，以可读的方式添加元数据信息。例如，对于数值域“salesteam”我们添加一个文本字段“♦salesteam”并设置默认值的描述文本。如果您的系统不支持扩展ASCII中的字段名称，使用一个标点符号，如{或¡来使得变量按字母顺序排列。如果您的系统不支持文本域的默认值，你必须嵌入尽可能多的情报到您的虚拟领域。
　　
　　那自我记录模块之间的信息呢？利用WSDL或其他XML语言，你可以把大量的元数据放入到XML本身，或支持DTD。虽然这些语言冗长而详细，并会减缓系统的响应时间，但其实大部分额外时间几乎并不明显。当你直接从您的代码库打个电话给云，实际上形成冗余或泡沫信息通常不会让你控制的太多电线。在这种情况下，发送一个额外的信息只有文本在出站请求或两个变量将故障排除，在长期学习曲线运行要容易得多。
　　
　　底线：尽管云不强迫任何文件或使其更容易执行，也有聪明的方式使用云的应用程序的功能和Web服务协议，使更多的现代系统自我记录。称为空中书写，并在您未来的云项目中执行。
　　
　　责任编辑：kelly