高性能Web应用有20个“绊脚石”

11.  缺少代码仓库及版本管理

尽管现在这个问题已非常少见，但是还有有些互联网公司在没有版本控制下去建立应用程序。当然那些使用了的人，很清楚它将给团队带来的日常优势和组织控制。

如果你没有使用，随着应用程序变得更加复杂，你将被卷入技术负债的漩涡，为应用不同部分添加员工将变得异常困难。

一旦你使用版本控制，确保囊括了所有的组件，包含配置文件以及其它要素。而丢失部署时需要用到的部分，将带来额外的风险。

12.  单点故障

如果你的数据只存在一个主数据库上，这就是一个单点故障。如果你的服务器位于一个单独的磁盘上，这也是个单点故障。单点故障可以比作“阿基里斯之踵”技术用语。

不惜任何代价，单点故障都要在应用程序中移除。麻烦的是如何去认识单点故障，即使是选择单一的云供应商都可以称为单点故障，如果拥有多个供应商，或者使用Amazon不同的部分，那么AirBNB的服务将幸免Amazon 2012年10月的部分宕机。

13.  缺乏只浏览模式

如果你深夜在Yelp、Facebook或者是Tumblr上发布评论，你可能就会收到这样的信息：“该特性不可用，请稍后再试”。稍后可能是50或者60分钟，也许可能还需多试几次。对于非技术用户，他们仍然感觉网站在正常运行，只是奇怪了一点而已。

实际情况是，应用程序只允许你去浏览网站，但是不可以做任何改变。可能是主数据库或者是一些存储组件不可用了。

只浏览模式可以通过保留主数据库的多个读备份来实现，使用MySQL副本或者是Amazon读副本类似途径。这样就可以在没有主数据库情况下，保留网站全部浏览功能正常，这一点非常重要。

14.  脆弱的沟通

在扩展上谈沟通可能非常奇怪，但是应用程序技术层不可能因为团队间社交和文化上的差异分离。

强大的通信线路是必要的，队员必须要知道在错误发生时将找谁。好的交流需要自信及知识渊博的领导，广泛的听取意见并加以改善。

15.  缺少文档

当Web应用程序包含许多层时，文档至关重要。开发者需要给程序、功能、页面做文档，让后来者看代码时可以清晰的发现所需的提示及见解。当有程序发 生故障时，运营程序需要在配置文件上添加评论去表明更改历史。业务流程及关系同样应该出现在公司的wiki里，让人们发现自己问题的解决方案。

文档可以在各个层次起到帮助作用，每个人都应该拥抱这个爱好。