开发
记录UI错误日志
JavaScript 允许捕获异常。这些异常需要通过Ajax请求提交到日志服务,否则很难截获Web环境中的错误。
可交换的数据层
数据层可分离,也可以与另一个遵从规范的数据层互换。
部署过程自动化
部署过程应自动化。生产环境所用的项目文件应由部署服务器生成,并在无人工干预的情况下自动完成。
使用版本控制系统
版本控制系统保存代码更改的历史,防止现有代码的丢失。同时,它还有助于协同开发。GitHub是这项服务最流行的提供商。除此以外,还有BitBucket。微软也有提供了额外协作特性的Team Foundation。
代码审阅
人总会有写错代码的时候,而代码审阅系统能保证开发者的高质量产出。同时,该系统还能让不止一位开发者熟悉代码。在某段代码的作者不在的时候,其他开发者可以顺利地做出修改。GitHub和Team Foundation都提供了相应的代码审阅功能。
权限与角色系统
每个应用都需要设计实现权限和角色系统。设立系统管理员,用户管理员等角色需要一个灵活的全局角色系统。
记录所有未处理的错误
所有错误应当记录下来,并用于未来的全面检查。也就是所有错误都应当提交给全局错误记录机制。
测试过程自动化
每次部署前,测试服务器应当运行所有测试。代码测试通过时部署应用,没能通过时报告给系统管理员。
业务层可以在不同环境上使用
业务层中的代码必须通用。即使代码本身面向Web环境,它也应当能在不要求改变代码的情况下使用于桌面环境,服务器环境,移动设备环境的不同用户界面,不同数据层上。
制定编码规范
一份规定明确的编码规范在未来项目开发的过程中起到重要作用。方法前需要写上注释吗?命名规范是什么?示例代码应放置何处?
开发者机器配置的指导方案
开发时最耗时的问题是不同的开发者之间的开发环境不同。需要让人们知道的是,他们应当安装什么软件,使用的是什么版本,同时需要安装什么组件,以及怎样安装这些组件。
性能
使用CDN
Content Delivery Networks(内容分发网络)通过离访客最近的服务器,为你的服务提供图片,JS和CSS等静态文件来提高访问速度,同时削减了带宽的用量。CloudFlare是CDN服务的绝佳示例。
压缩所有的JS和CSS文件
JS和CSS文件应当使用YUI compressor这样的压缩器来减少文件体积,并且使用gzip传输。把JS代码的引用放到最后也是不错的做法。
记录加载较慢的页面
Web应用程序应当响应迅速。分析页面加载的系统有责任识别加载较慢的页面。运行迅速的页面可能会遇到一些用户读取特定数据时加载时间过长的问题。
非关键数据使用NoSQL存储
NoSQL数据库(文档型数据库)在接收数据和存储数据时的速度很快,并且可以大规模扩展。由于这类数据库不能确保关系的完整性,所以应当为关键数据使用关系型数据库。在诸如用户通知和聊天记录等场合,NoSQL可以节约成本,安全地使用。
选择附近的数据中心
数据中心的位址应当靠近绝大多数用户。处在与用户同一个国家的数据中心对页面访问速度大有影响。有必要的情况下,还可以建立多个数据中心。
允许数据多来源
存储数据的成倍增加,带来的是应用程序性能降低。程序架构应做好处理多来源的大规模数据的准备。
安全
隔离数据库中的关键信息
数据库用户在访问关键信息时应受到限制,比如取得哪怕是已经Hash过了的密码和所有用户的Email地址等信息。应当使用存储过程和视图作验证,或者作自定义数据。
防止远程执行代码
应用程序包含了对安全性较差代码的依赖时,会使攻击者在远程执行相应的攻击代码。
防止洪水攻击和垃圾邮件攻击
认证用户发起的洪水攻击和垃圾邮件攻击都是可能的。要注意随时跟踪他们最后发起的不明操作,避免制造大量请求。
对密码散列处理时使用唯一salt值
所有密码都应当使用salt值散列处理,并且每个用户的salt值都是唯一的。人们容易在不同的服务上使用相同的密码,应用程序有责任保护用户的密码。
全局的跨站脚本攻击(XSS)保护
XSS攻击的全称是Cross Site Scripting跨站脚本攻击,是让用户执行远程恶意脚本的Web漏洞。
防止SQL注入漏洞
SQL注入是常见的漏洞。攻击者通过构造字符串,可以执行有害的SQL命令。使用ORM是一种防范的好方法。
防止跨站请求伪造(CSRF)
Cross-Site Request Forgery跨站请求伪造是一种常见的Web漏洞,攻击者在他们的网站上放置一个iframe框架,该框架从程序中请求页面,而用户并不处于应用程序中。GET请求不应该修改数据,这是硬性要求,防止从应用程序域名之外发出POST请求,同时,也可以保护程序不受攻击。相比之下,更好的做法则是在每个表单里提供接收请求后验证的token。
修改关键信息之前验证密码
即使用户信息在电脑上有所记录,甚至用户几分钟前成功登录了系统,在访问或者修改如密码,Email或者数据备份等关键信息时总是需要验证密码。
HTTP的严格安全传输
如果用HTTPS传输数据,就应该只使用HTTPS传输。否则中间人很可能有作为HTTPS到HTTP传输的转换者,让用户使用HTTP发出请求以分析数据。
* * * * *
* * * * *
[TOC]
在所有应用中使用HTTPS
HTTPS是世界范围的加密标准,在第一次连接握手之后没有额外的开销。所有的页面和资源都应当使用HTTPS传输。使用HTTPS的时候,推荐的信息来源也要是HTTPS。否则浏览器就会以安全原因不予显示。
验证会话的浏览器和位置信息
会话和Cookies都可以被劫持。浏览器报头信息和用户最后的IP地址的位置信息都可以和原来的用户会话对比。一个积极防范的办法是将会话与用户IP绑定,但是可能会在动态地址和移动设备的情况下造成问题。
分析
尽可能保留数据
每项数据、每条请求、每个事件都应当记录在“大数据”的存储中。这些数据将来会很有用处,数据挖掘技术将会呈现出有用的分析报告。
## 观察用户意向
对于未来计划而言,找出用户使用应用程序与否背后的原因十分重要。
允许用户灵活获取分析报告
现如今数据分析非常关键。分析报告揭示了未来业务的走向何方。优秀的应用程序不仅能便利用户,而且能让用户按需生成报表。
可靠性
分发请求并做到100%上线率
应用服务器直接接受连接,不如在内部搭建一个分发请求的反向代理服务器。这样在有部分服务器当机的情况下也能由仍然运转的服务器提供服务。
自动备份数据
数据应当至少每天备份,而更多的备份任务应当取决于特定存储和应用服务器,必要时还需要做好数据中心的灾备方案。
100% 覆盖业务层和数据层的测试
测试应当覆盖业务层和数据层的所有代码。搅乱用户数据,计算出错误的结果,提供错误数据,以及存储发生错误将会造成用户流失和金钱损失。
检测服务器在线时长
目前有许多检测服务器在线时长的第三方服务。他们同时也提供按指定时间间隔,检查服务器状态的定制服务。
可用性
## 减少页面刷新
与Ajax技术相比,刷新页面更慢,同时也在页面跳转时使用户流失。单页应用(类似Gmail)用户体验良好,同时也更难开发,更容易出bug。资源(人力)足够,则可以选择开发单页应用,否则更应该采用Ajax技术。
## 隐藏生产环境中的详细错误信息
详细的错误提示页面输出了与错误有关的任何信息,是每位开发者都需要的。生产环境中的应用程序仍然能够记录这些信息日志,那么就有必要隐藏这些信息。
**简化用户界面**
“学习使用程序”的时代已经过去。在用户熟悉之前,程序要足够简单。在用户熟悉之后,高级操作就会显现出来。复杂的界面会使用户望而却步。
全局搜索系统
使用搜索的倾向已在近年来逐渐上升。Google、Facebook、Twitter都有搜索功能。所有的软件巨头都会提供能对搜索结果筛选的全局搜索系统。要让用户们在你的应用上也能有一致的功能。
发生状况时引导用户
发生错误或者输入密码之后,需要向用户指明他们的来向和去向,请记住这一点。
移动端优先的UI
UI设计的通常做法是首先考虑桌面端,然后适配移动端设备。这种做法在适配时开销巨大。UI应当首先考虑移动设备,再适配桌面端。
## 全局反馈系统
开发者和测试者不能预测问题的状况时有发生。最好的解决办法就是每个页面上都设置能让用户访问到的反馈机制。
**一致的UI行为**
用户有可能使用着Windows、Mac、Linux、移动设备或者某个不知名的设备。而在这些环境中,UI的行为必须一致。实现这一点的方法就是遵循标准,并且不使用不标准的组件。同时,使用Bootstrap或者Foundation这样的框架也有帮助。
使用友好的URL
虽然Web应用并不是针对有组织的访客(来自搜索引擎),人们在Email或者IM中分享地址的时候总是想要了解到点击以后出现的内容。人们通常对此解释较少,所以分享的时候URL本身至少能提供相关的信息。
转化策略
邀请码系统
邀请注册是获得新用户最古老也是最有效的转化策略。成功的邀请系统不仅奖励邀请人,被邀请人也会受益。
支持系统
用户总会有问题,而每个应用都需要支持系统。缺少支持系统会让用户望而却步。这里是一些外部方案:ZenDesk、Desk、Freshdesk、Zoho Support……
消息通知和定时发送Email
让用户回头使用软件很重要。用户常常不记得软件,遗忘了便不再回来。定时发送带有消息通知的Email能留住用户。不要忘了保留这类选项的开关,不然那将会成为垃圾邮件。
总做得更好
不论拥有多少用户,哪怕1个,甚至成千上万,总是要做得更好。这么做将会掩盖每个软件都会有的瑕疵。
整合社交+激励
访客,哪怕是付费用户,都很难有机会在社交网络上分享你的应用。应该为此设立相应的激励机制。这要求使用Facebook、Twitter等社交网络API散播相关信息。
邮件列表
让用户保持更新十分重要。用户使用软件时,他们会很高兴地得知你会为此做出支持,并做到更好。创建邮件列表,让用户知道每月的改进是负责任的态度。
了解潜在的客户
不要指望用户自然而来,你得为之奋斗。虽然有很多优质的广告方案,更好的做法是在互联网上花少量钱甚至免费提供相应的价值,然后将其引导到相应的产品上来。
**不要让用户流走**
知道用户离开的原因十分重要。好的系统会在用户离开的时候发出一封邮件,提供优惠折扣,并且征求反馈。
竞争策略
研究用户产品需求
软件产品的需求从来就不是凭空产生的。需求分析让开发者与产品经理有据可依。尝试着通过分析用户最常使用的部分来理解客户的真实需求。
了解竞争对手
没有产品是生来完美的。一家公司开发,其他公司改进;最初的那一家因而得到进步。这是每个行业都会有的开发流程。每项产品都会有其竞争对手。
- PHP技术文章
- PHP中session和cookie的区别
- php设计模式(一):简介及创建型模式
- php设计模式结构型模式
- Php设计模式(三):行为型模式
- 十款最出色的 PHP 安全开发库中文详细介绍
- 12个提问频率最高的PHP面试题
- PHP 语言需要避免的 10 大误区
- PHP 死锁问题分析
- 致PHP路上的“年轻人”
- PHP网站常见安全漏洞,及相应防范措施总结
- 各开源框架使用与设计总结(一)
- 数据库的本质、概念及其应用实践(二)
- PHP导出MySQL数据到Excel文件(fputcsv)
- PHP中14种排序算法评测
- 深入理解PHP原理之--echo的实现
- PHP性能分析相关的函数
- PHP 性能分析10则
- 10 位顶级 PHP 大师的开发原则
- 30条爆笑的程序员梗 PHP是最好的语言
- PHP底层的运行机制与原理
- PHP 性能分析与实验——性能的宏观分析
- PHP7 性能翻倍关键大揭露
- 鸟哥:写在PHP7发布之际一些话
- PHP与MySQL通讯那点事
- Php session内部执行流程的再次剖析
- 关于 PHP 中的 Class 的几点个人看法
- PHP Socket 编程过程详解
- PHP过往及现在及变革
- PHP吉祥物大象的由来
- PHP生成静态页面的方法
- 吊炸天的 PHP 7 ,你值得拥有!
- PHP开发中文件操作疑难问答
- MongoDB PHP Driver的连接处理解析
- PHP 杂谈《重构-改善既有代码的设计》之二 对象
- 在php中判断一个请求是ajax请求还是普通请求的方法
- 使用HAProxy、PHP、Redis和MySQL支撑10亿请求每周架构细节
- HTML、HTML5、XHTML、CSS、SQL、JavaScript、PHP、Web Services 是什么?
- 重构-改善既有代码的设计
- PHP场景中getshell防御思路分享
- 移动互联时代,你看看除了PHP你还会些什么
- 安卓系统上搭建本地php服务器环境
- PHP中常见的缓存技术!
- PHP里10个鲜为人知但却非常有用的函数
- 成为一名PHP专家其实并不难
- PHP 命令行?是的,您可以!
- PHP开发提高效率技巧
- PHP八大安全函数解析
- PHP实现四种基本排序算法
- PHP开发中的中文编码问题
- php.get.post
- php发送get、post请求的6种方法简明总结
- 中高级PHP开发者应该掌握哪些技术?
- 前端开发
- web前端知识体系大全
- 前端工程与性能优化(下)
- 前端工程与性能优化(上)
- 2016 年技术发展方向
- Web应用检查清单
- 如何成为一名优秀的web前端工程师
- 前端组件化开发实践
- 移动端H5页面高清多屏适配方案
- 2015前端框架何去何从
- 从前端看“百度迁徙”的技术实现(一)
- 从前端看“百度迁徙”的技术实现(二)
- 前端路上的旅行
- 大公司里怎样开发和部署前端代码?
- 5个经典的前端面试问题
- 前端工程师新手必读
- 手机淘宝前端的图片相关工作流程梳理
- 一个自动化的前端项目实现(附源码)
- 前端代码异常日志收集与监控
- 15年双11手淘前端技术总结 - H5性能最佳实践
- 深入理解javascript原型和闭包系列
- 一切都是对象
- 函数和对象的关系
- prototype原型
- 隐式原型
- instanceof
- 继承
- 原型的灵活性
- 简述【执行上下文】上
- 简述【执行上下文】下
- this
- 执行上下文栈
- 简介【作用域】
- 【作用域】和【上下文环境】
- 从【自由变量】到【作用域链】
- 闭包
- 完结
- 补充:上下文环境和作用域的关系
- Linux私房菜