在我加入Ruxit作为一名技术推广之前更早期时是一名软件开发人员，我们以一种错误的方式在两个项目之间共享一个数据库。这篇文章就是关于一个糟糕的决定教给我们的两个重要教训。
几年前我作为团队的开发主管为客户开发一个JAVA web应用。我们叫它“项目A”。我们在客户现场构建这个web应用，除我们之外还有其它几个团队在做相关的项目。因为在更早的项目上我们在合作中彼此熟悉，我们会在一个常用的基本信息方面交流软件架构方面的想法。
一天一个新项目（项目B)启动了。这个项目由其他团队中的一个来实施。在我的脑海里我仍能看到我们站在那的样子，我们完全了解这个项目并计划在项目B上共享项目A的关于用户，角色和权限的数据库架构。毕竟，两个项目都是服务于相同用户的内部web项目。哦，对了，我忘了说明所有这些项目没有一个中心用户数据库——每一个新项目需要从开头开始。我们认为通过共享已经存在的基础架构和实践不仅节约了开发时间也节约了令人头疼的用户支持方面的人力,因为他们不需处理独立的用户目录。
我们通过配置使项目B可以通过一个数据库账户访问我们的数据库表，因为你知道我们不想产生混乱的局面。
一切正常运行一段时间...
毕竟存储用户，角色和权限并不是火箭科学那样难。一年之后，项目A的新版本计划开始。我们很激动因为我们有机会在维护现有好的部分的同时改进我们认为不好的部分。我们甚至改进一些原本就工作很好的部分——这其中就包括用户，角色和权限的数据库表结构。说实话，我们并没有考虑到项目B。当然，项目B很快就停止工作了。我们的错误决定就是允许项目B直接访问我们的数据库。不仅仅准对现在的标准，甚至对于以前的标准，正确的决定应该是创建一个独立的认证服务，然后通过共享API而不是直接访问数据库。
但是，还有更多的...
是的，我们犯了一个严重的架构错误，但是有另一个问题出现。有点讽刺意味的是项目B是一个完全没有人使用的产品。尽管已经根据产品经理实现了，也有非常好的测试覆盖率和代码质量，但是项目B并没有被需要它的部门使用。项目B卡在了”友好的用户”的炼狱阶段，准备发布，但有没有正式发布。所以知道两周后才有人发现它不能正常工作。
直到第一个不幸的用户报告了问题，我们的开发人员已经正在另一个项目上工作。作为分析根本原因的第一步，我们试图通过检查错误日志文件来发现问题在哪里。从事后诸葛亮的角度来看，在本应该有自动探测应用问题的地方没有一个复杂的监控解决方案同样是一个糟糕的决定。
尽管这可能是一个有趣的轶事，但是我真的希望你能从中学到些东西。确保你通过一个稳定的API访问数据库，因为它把简单的数据库变成一个服务并且使它在以后更容易使用。此外一定确保你已经适当地监控你的应用和服务。通过API构建的环境将使你的基础架构在很长一段时间保持灵活性。监控能够确保复杂性的增加在可控的范围内。
我希望你喜欢这个小小的推荐在未来某一天当你打开Eclipse选择文件菜单，然后选择“导出为war...”的时候。
