如何在云端记录

没有人有时间记录系统。在云中,人们不再需要记录文档,但是这样做变得越来越重要。输入天空写作:利用云解决这个永恒的问题。

没有注释或编码系统从来没有一个很好的借口,即使这些做法对降低成本同样有帮助 和质量作为测试驱动的开发。但是,让我们面对现实吧,记录系统并不完全是男子气概,而且,它也不会给您带来丑陋的工作- 不可维护代码的安全性(看一下 这一页 对于一些 糟糕的最佳实践建议)。

不幸的是,在云中工作可以为开发人员提供新的借口:“我没有对该公共云服务的访问或控制权,所以我 无法记录任何相关内容。”

嗯。因此,这样称呼他们的虚张声势:全部 消费者 (公共或私有)云服务需要记录该服务的功能, 用法,使用方依赖于什么行为(包括错误和错误情况)。立刻,呜呜呜呜呜呜呜呜 来:“但这意味着我们必须在使用它的每个模块中记录相同的云服务。”您的回应应该是,“将您的 整个开发和集成团队都可以访问的Wiki,Google文档或其他协作系统中的文档信息。”

这将使每个人都朝着外部接口以及模块和服务的依赖关系的最佳实践:集中式存储库 其内容由开发团队的每个成员创建和维护-尽可能按其分布。以我的经验, 可以选择由一个集中的团队负责创建和维护数据字典,实体关系模型,业务流程 描述或接口文档仅产生两件事:不做文档的借口,或者充其量是过时或经常不正确的借口 tomes.

但是Wiki是记录模块内部或变量管理信息的最佳场所吗?这不是一个坏主意,但大多数时候 开发人员在入侵代码或调整应用程序内的变量时不会只是在文档领域。当他们在工作时 代码,内联注释不能仅仅被鼓励:它必须被度量。对于我们开发的代码,我们不允许签入任何模块 除非至少有10%的行是显式注释,另外10%的行具有行内注释。内联代码要求 对于测试模块而言,它的性能提高了一倍,因为很难猜测要测试的特定路由的内容,以及何时在测试模块中查找什么位置 有一个失败。您的代码集成系统可能已经具有用于此目的的计数器和执行机制,但是如果没有,则通常可以 script it to do so.

在某些Cloud应用程序和框架中,脚本,工作流和公式语言本身不支持注释,但是有 总是一种通过包含文档消息的无效代码片段来添加注释的方法(例如,IF 0 = 1,“注释在此处 —可能长达80个字符”)。

因此,我们删除了所有不注释代码的借口。但是,在现代的基于云的应用程序中,很多动作不是在代码中进行的:它是 声明式编程和自定义字段/对象/关系。同样,在这里,随行文件也必须明确地衡量两者的动机 开发人员和管理员。在Salesforce.com这样的系统中,每个新字段都有两次自我记录的机会:描述区域, 和帮助气泡信息区域。我鼓励两者都使用,每个信息中都有不同的信息。如果云系统没有此功能,我们将使用 虚拟字段的名称会遮盖实际字段,并以易于理解的方式添加元数据信息。例如,对于数字字段 在“ salesteam”中,我们将添加一个文本字段“♦salesteam”,并将默认值设置为描述性文本。如果您的系统不支持扩展ASCII 字段名称,请使用{或¡这样的标点符号来强制变量名出现在任何字母顺序列表的末尾。如果您的系统没有 由于支持文本字段的默认值,因此您必须在虚拟字段名称中嵌入尽可能多的信息。

如何自我记录模块之间的消息?使用WSDL或其他XML方言,您可以将大量元数据放入 XML本身,或纳入支持的DTD。尽管这些操作可能很冗长且可能会延缓系统响应时间,但在大多数情况下,额外的开销是 几乎没有引起注意。当您直接从您的代码调用Cloud时,实际上构成REST或SOAP消息的库 通常不会让您控制太多的事情。在这种情况下,在出站中发送一个或多个额外的仅用于信息的文本变量 从长远来看,该请求将使故障排除和学习曲线变得容易得多。

底线:即使云不会强制执行任何文档或使其变得更易于执行,但仍有使用云的巧妙方法 应用程序功能和Web服务协议,使现代系统更具自记录性。称其为天空书写,并在下一个云中实施 project.

有关的:

版权© 2011 IDG通讯,Inc.