前后端分离了,然后呢?(什么前后端分离)
1090
2022-07-29
对于如何完成同一项任务,摆在我们面前的方案选项似乎无穷无尽,特别是在开发一套能够运作在现代网络环境之下的网站时。Web开发人员首先需要挑选一套Web托管平台及底层数据存储机制,并利用由提供的工具编写HTML、CSS以及JavaScript代码,考虑如何实现设计效果以及哪些潜在JavaScript库/框架可能会被包含于其中。
一旦选择被细化到这一层面,我们就能在网络上找到大量相关文章、论坛以及示例,并借此了解如何打造出更为出色的Web使用体验。然而无论有多少条道路可供选择,开发人员都有可能在自己的选项当中迷失方向。虽然其中有些错误与特定方案相关,但也有一些共同的挑战横亘在每一位Web开发人员面前。
因此通过一系列研究、经验与近期观察,我整理出了下面这份十大常见错误清单——目前确实有很多Web开发人员还在饱受其困扰,而我也给出了自己的解决意见。
以下这份清单不分先后顺序。
1. 编写陈旧的HTML代码
错误: 互联网在发展早期只提供有限的几种标记选项,而如今这类选项已经变得相当丰富。然而某些陈旧的陋习当下仍然存在,而且很多从业者在编写HTML代码时好像仍然活在上个世纪。具体实例包括使用
影响: 编写上述带有浓郁上世纪风格的HTML代码可能导致标记复杂程度过高,进而在不同浏览器中出现彼此相异的运行效果。此外,我们也没有任何理由在微软Edge甚至是IE新版本(包括IE 9、10与11)当中使用此类复杂的标记方式。
如何避免: 不要再使用
2. “在我的浏览器中明明没有问题……”
错误: 开发人员可能会偏爱某款特定浏览器或者极度鄙视另一款浏览器,而且会将这种带有偏见的观点带入网页测试工作当中。在某些情况下,我们甚至有可能将来自网络的示例代码直接纳入到项目当中,而并没有测试其能够在其它浏览器中正确得以渲染。再有,某些浏览器会在样式方面拥有不同的默认值设定。
影响: 编写一个只适用于特定浏览器的站点很可能会给使用其它浏览器的用户带来非常糟糕的访问体验。
如何避免: 在开发过程中针对每一款浏览器及其版本进行网页测试显然是不现实的。不过我们可以每隔特定一段时间就利用多种浏览器来检查自己的网站是否能够正常运作,这算是种比较理想的折衷办法。目前无论大家使用哪种首选开发平台,都有大量免费工具可以帮助各位实现测试工作,具体包括免费虚拟机或者站点扫描工具。Browsershots或者BrowserStack等网站还能够提供快照,帮助我们了解特定页面在不同浏览器/版本/平台上拥有怎样的渲染效果。而Visual Studio等工具也能够利用不同浏览器显示我们目前正在开发的单一页面。当利用CSS进行设计时,请记得对所有默认值进行“重新设定”。
如果大家的站点使用了任何面向单一浏览器所创建的特殊CSS功能,那么请留心处理各类提供程序前缀,包括-webkit-、moz-或者-ms-。作为行业趋势指南,我建议大家认真查阅下面提供的各参考站点(皆为英文原文):
• 微软Edge开发博客: A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent…
• QuirksMode.org: CSS vendor prefixes considered harmful
• Bruce Lawson: On Internet Explorer supporting -webkit- vendor prefixes
虽然以上参考资料已经解释了我们该如何避免提供程序前缀及其相关理由,但大家也可以点击此处通过具体建议了解更多解决办法(英文原文)。
3. 注意调整格式
错误: 通过提示的方式向用户索取信息(特别是以输入文本字段的方式),并单纯假设该数据能够如预期般从用户处获得。
影响: 在默认信任用户输入信息时,我们有可能面临大量意料之外的麻烦。如果所要求的数据未能被正确获得,或者所获得的数据与底层数据格式不兼容,那么页面很可能发生错误。更为严重的是,某些针对网站数据库的故意违反行为甚至足以构成注入式攻击。
如何避免:第一条建议就是要确保用户能够清晰地了解到网站要求其输入哪种数据类型。就目前而言,单纯给出“请输入地址”的提示可能代表着用户需要输入公司地址、家庭住址甚至是电子邮箱地址!除了作出针对性说明之外,我们还应当充分发挥现代HTML当中所提供的数据有效性验证技术。无论数据在浏览器端是否被视为有效,我们务必要在服务器端同样对其进行验证。永远不要在未确认字段内容符合数据类型要求的情况下,允许用户所输入的多行索引T-SQL语句使用站点数据。
4. 反应速度太过缓慢
错误: 对于包含有大量高品质图像以及/或者图片的页面,我们应当利用元素对其高度及宽度属性进行调整。而来自页面中的CSS以及JavaScript等文件链接往往也体积庞大。另外,源HTML标记的存在经常会带来不必要的复杂性与加载负担。
影响: 如何某个页面的完全渲染时间过长,那么一部分用户可能会放弃访问甚至不耐烦地重新加载整个页面。在某些情况下,如果页面的处理时耗太长,甚至可能引发其它未知错误。
如何避免: 不要以为互联网的传输速度越来越快就可以毫无顾忌地设计出臃肿的页面成果。相反,将往返于浏览器与站点之间的每一点流量都视为运营成本。图片可以说是页面臃肿问题的罪魁祸首,因此为了最大限度降低图片给页面带来的加载成本,请从以下三个角度进行考量:
问问自己:“页面中所包含的所有图片都是必要的吗?”如果答案是否定的,那么去掉那些不必要的图像。大家也可以点击此处对自己的网站进行扫描,从而获取建议以了解哪些图片可以进行压缩。
利用Shrink O’Matic或者RIOT这类工具来将自己的图片尺寸控制在最低水平。
采取图片预加载方案。这虽然不会降低初始-的具体成本,但却能够让站点上其它使用相关图片的页面拥有更出色的载入速度。
另一种降低成本的方式则是压缩CSS与JavaScript链接文件的体积。目前我们可以选择大量工具来帮助自己完成这项评估工作,其中包括Minify CSS以及Minify JS。
在结束第四点错误之前,我们还得提一句,请在HTML当中使用
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~