想做一个高质量的Web应用，前前后后要做的事情非常多。国外开发者 Ata Sasmaz 为 Web 开发者制作分享了一份检查清单，包括应用开发、性能、安全、分析、可用性、可靠性、转换策略、竞争策略这些方面需要注意的事项。清单内容可能不全面，欢迎大家在评论中补充。 开发
JavaScript 允许捕获异常。这些异常需要通过Ajax请求提交到日志服务，否则很难截获Web环境中的错误。
数据层可分离，也可以与另一个遵从规范的数据层互换。
部署过程应自动化。生产环境所用的项目文件应由部署服务器生成，并在无人工干预的情况下自动完成。
版本控制系统保存代码更改的历史，防止现有代码的丢失。同时，它还有助于协同开发。GitHub是这项服务最流行的提供商。除此以外，还有BitBucket。微软也有提供了额外协作特性的Team Foundation。
人总会有写错代码的时候，而代码审阅系统能保证开发者的高质量产出。同时，该系统还能让不止一位开发者熟悉代码。在某段代码的作者不在的时候，其他开发者可以顺利地做出修改。GitHub和Team Foundation都提供了相应的代码审阅功能。
每个应用都需要设计实现权限和角色系统。设立系统管理员，用户管理员等角色需要一个灵活的全局角色系统。
所有错误应当记录下来，并用于未来的全面检查。也就是所有错误都应当提交给全局错误记录机制。
每次部署前，测试服务器应当运行所有测试。代码测试通过时部署应用，没能通过时报告给系统管理员。
业务层中的代码必须通用。即使代码本身面向Web环境，它也应当能在不要求改变代码的情况下使用于桌面环境，服务器环境，移动设备环境的不同用户界面，不同数据层上。
一份规定明确的编码规范在未来项目开发的过程中起到重要作用。方法前需要写上注释吗？命名规范是什么？示例代码应放置何处？
开发时最耗时的问题是不同的开发者之间的开发环境不同。需要让人们知道的是，他们应当安装什么软件，使用的是什么版本，同时需要安装什么组件，以及怎样安装这些组件。 性能
Content Delivery Networks（内容分发网络）通过离访客最近的服务器，为你的服务提供图片，JS和CSS等静态文件来提高访问速度，同时削减了带宽的用量。CloudFlare是CDN服务的绝佳示例。
JS和CSS文件应当使用YUI compressor这样的压缩器来减少文件体积，并且使用gzip传输。把JS代码的引用放到最后也是不错的做法。
Web应用程序应当响应迅速。分析页面加载的系统有责任识别加载较慢的页面。运行迅速的页面可能会遇到一些用户读取特定数据时加载时间过长的问题。
NoSQL数据库（文档型数据库）在接收数据和存储数据时的速度很快，并且可以大规模扩展。由于这类数据库不能确保关系的完整性，所以应当为关键数据使用关系型数据库。在诸如用户通知和聊天记录等场合，NoSQL可以节约成本，安全地使用。
数据中心的位址应当靠近绝大多数用户。处在与用户同一个国家的数据中心对页面访问速度大有影响。有必要的情况下，还可以建立多个数据中心。
存储数据的成倍增加，带来的是应用程序性能降低。程序架构应做好处理多来源的大规模数据的准备。 安全
数据库用户在访问关键信息时应受到限制，比如取得哪怕是已经Hash过了的密码和所有用户的Email地址等信息。应当使用存储过程和视图作验证，或者作自定义数据。
应用程序包含了对安全性较差代码的依赖时，会使攻击者在远程执行相应的攻击代码。
认证用户发起的洪水攻击和垃圾邮件攻击都是可能的。要注意随时跟踪他们最后发起的不明操作，避免制造大量请求。
所有密码都应当使用salt值散列处理，并且每个用户的salt值都是唯一的。人们容易在不同的服务上使用相同的密码，应用程序有责任保护用户的密码。
XSS攻击的全称是Cross Site Scripting跨站脚本攻击，是让用户执行远程恶意脚本的Web漏洞。
SQL注入是常见的漏洞。攻击者通过构造字符串，可以执行有害的SQL命令。使用ORM是一种防范的好方法。
Cross-Site Request Forgery跨站请求伪造是一种常见的Web漏洞，攻击者在他们的网站上放置一个iframe框架，该框架从程序中请求页面，而用户并不处于应用程序中。对GET请求不会强制性的作出修改，防止从应用程序域名之外发出的POST请求可以受到保护，而更好的做法，则是在每个表单里提供接收请求后验证的token。
即使用户信息在电脑上有所记录，甚至用户几分钟前成功登录了系统，在访问或者修改如密码，Email或者数据备份等关键信息时总是需要验证密码。
如果用HTTPS传输数据，就应该只使用HTTPS传输。否则中间人很可能有作为HTTPS到HTTP传输的转换者，让用户使用HTTP发出请求以分析数据。
HTTPS是世界范围的加密标准，在第一次连接握手之后没有额外的开销。所有的页面和资源都应当使用HTTPS传输。使用HTTPS的时候，推荐的信息来源也要是HTTPS。否则浏览器就会以安全原因不予显示。
会话和Cookies都可以被劫持。浏览器报头信息和用户最后的IP地址的位置信息都可以和原来的用户会话对比。一个积极防范的办法是将会话与用户IP绑定，但是可能会在动态地址和移动设备的情况下造成问题。 分析
每项数据、每条请求、每个事件都应当记录在“大数据”的存储中。这些数据将来会很有用处，数据挖掘技术将会呈现出有用的分析报告。
对于未来计划而言，找出用户使用应用程序与否背后的原因十分重要。
现如今数据分析非常关键。分析报告揭示了未来业务的走向何方。优秀的应用程序不仅能便利用户，而且能让用户按需生成报表。 可靠性
应用服务器直接接受连接，不如在内部搭建一个分发请求的反向代理服务器。这样在有部分服务器当机的情况下也能由仍然运转的服务器提供服务。
数据应当至少每天备份，而更多的备份任务应当取决于特定存储和应用服务器，必要时还需要做好数据中心的灾备方案。
测试应当覆盖业务层和数据层的所有代码。搅乱用户数据，计算出错误的结果，提供错误数据，以及存储发生错误将会造成用户流失和金钱损失。
目前有许多检测服务器在线时长的第三方服务。他们同时也提供按指定时间间隔，检查服务器状态的定制服务。 可用性
与Ajax技术相比，刷新页面更慢，同时也在页面跳转时使用户流失。单页应用（类似Gmail）用户体验良好，同时也更难开发，更容易出bug。资源（人力）足够，则可以选择开发单页应用，否则更应该采用Ajax技术。
详细的错误提示页面输出了与错误有关的任何信息，是每位开发者都需要的。生产环境中的应用程序仍然能够记录这些信息日志，那么就有必要隐藏这些信息。
“学习使用程序”的时代已经过去。在用户熟悉之前，程序要足够简单。在用户熟悉之后，高级操作就会显现出来。复杂的界面会使用户望而却步。
使用搜索的倾向已在近年来逐渐上升。Google、Facebook、Twitter都有搜索功能。所有的软件巨头都会提供能对搜索结果筛选的全局搜索系统。要让用户们在你的应用上也能有一致的功能。
发生错误或者输入密码之后，需要向用户指明他们的来向和去向，请记住这一点。
UI设计的通常做法是首先考虑桌面端，然后适配移动端设备。这种做法在适配时开销巨大。UI应当首先考虑移动设备，再适配桌面端。
开发者和测试者不能预测问题的状况时有发生。最好的解决办法就是每个页面上都设置能让用户访问到的反馈机制。
用户有可能使用着Windows、Mac、Linux、移动设备或者某个不知名的设备。而在这些环境中，UI的行为必须一致。实现这一点的方法就是遵循标准，并且不使用不标准的组件。同时，使用Bootstrap或者Foundation这样的框架也有帮助。
虽然Web应用并不是针对有组织的访客（来自搜索引擎），人们在Email或者IM中分享地址的时候总是想要了解到点击以后出现的内容。人们通常对此解释较少，所以分享的时候URL本身至少能提供相关的信息。 转化策略
邀请注册是获得新用户最古老也是最有效的转化策略。成功的邀请系统不仅奖励邀请人，被邀请人也会受益。
用户总会有问题，而每个应用都需要支持系统。缺少支持系统会让用户望而却步。这里是一些外部方案：ZenDesk、Desk、Freshdesk、Zoho Support……
让用户回头使用软件很重要。用户常常不记得软件，遗忘了便不再回来。定时发送带有消息通知的Email能留住用户。不要忘了保留这类选项的开关，不然那将会成为垃圾邮件。
不论拥有多少用户，哪怕1个，甚至成千上万，总是要做得更好。这么做将会掩盖每个软件都会有的瑕疵。
访客，哪怕是付费用户，都很难有机会在社交网络上分享你的应用。应该为此设立相应的激励机制。这要求使用Facebook、Twitter等社交网络API散播相关信息。
让用户保持更新十分重要。用户使用软件时，他们会很高兴地得知你会为此做出支持，并做到更好。创建邮件列表，让用户知道每月的改进是负责任的态度。
不要指望用户自然而来，你得为之奋斗。虽然有很多优质的广告方案，更好的做法是在互联网上花少量钱甚至免费提供相应的价值，然后将其引导到相应的产品上来。
知道用户离开的原因十分重要。好的系统会在用户离开的时候发出一封邮件，提供优惠折扣，并且征求反馈。 竞争策略
软件产品的需求从来就不是凭空产生的。需求分析让开发者与产品经理有据可依。尝试着通过分析用户最常使用的部分来理解客户的真实需求。
没有产品是生来完美的。一家公司开发，其他公司改进；最初的那一家因而得到进步。这是每个行业都会有的开发流程。每项产品都会有其竞争对手。 原文链接： Ata Sasmaz 翻译： 伯乐在线 - 埃姆杰 译文链接： http://blog.jobbole.com/55582/ |
