开发人员都知道开发和维护代码注释是多么重要。这样做不仅使代码更容易浏览和理解，同事和自己在几个月以后再回朔代码的时候，也可以轻松测试和修改它。

举一个例子，在应用程序数据库中记录数据结构（表和列）会更加重要，但它比代码文档更容易被忽视。以下是我认为的一些原因。

数据库超出了项目的执行

从组织的角度来看，应用程序代码只是在项目执行和团队中考虑的。而另一方面，数据库会被用于多个团队活动和项目中，它的组织范围更广。

更多的访问点

应用程序代码主要会被开发人员和编译人员“访问”。然而，数据库不仅会被应用程序访问，而且会被更多的其他程序，报表，电子制表软件，ETLs（数据抽取、转换、装载），即席查询，商业智能系统等等访问。

更多的用户

你想想看，代码和代码文档几乎全由开发者使用。他们是需要了解它的人。对于大多数其它应用程序的相关人员，你的开发是一个黑盒。如果出了问题，用户，测试人员，项目经理或者其他人，不是查看代码找原因，而是电话开发、维护人员。

在数据案例中情况略有不同。有更多的人和应用程序需要在数据库中直接访问它。有支持顾问，j2直播，业务分析师，数据分析师，其他团队（数据仓库/商业智能）的开发人员等等。

用户更分散：组织上或地理上

一个开发团队是一小群人坐在一个房间里每天喝着咖啡聊天，那自然是很好的。但是你想想看，所有人访问数据时，atv，他们可能甚至不知道他们自己的存在。这些人在各个IT、业务部门、供应商和顾问之间横跨整个组织，这也是完全真实的，这些人可能在不同的洲。

在某个时刻

数据用户在空间和时间上都是分散的。许多应用程序需要几个月（有时是几年）来实现，一旦部署好了代码，功能就被限定死了。虽然有一些可扩展的特性（报表等等），但是核心代码已经改不了了。团队也是如此。但与数据库不同的是，报告和分析的开发将很有可能会贯穿整个应用程序的生命周期，甚至更长时间。在应用程序已停止应用后，一些数据库依然保持在线供报表和参考应用。

应用程序的结束不代表数据的结束

当你的应用程序面临它生命的终结时，你会迁移到新的应用平台，你可能会把你旧的应用程序和它的代码一起放到垃圾箱。对数据，你不能这么做。不仅数据所有者需要在应用程序停用以后还要继续长久的访问它，而且他们很有可能还需要把数据迁移到新系统。这需要对数据模型有很好的理解。

总结

我希望这篇文章能引你深思。思考并检查你是否有数据库文档。如果没有，那么开始编制文档永远不晚。Dataedo-这是一个轻量级的工具，会让你在几分钟内上手。

另外，如果你的代码中没有注释，那也是一个令人担心的事。