前端开发到底需要掌握哪些知识?
1..实现效果图是最基本的工作
把视觉稿通过页面代码的方式表现出来包含了两个基本诉求:1.能够真实反映视觉稿;2.能够通 过浏览器的兼容。这两个诉求的达成需要我们有追求细节的态度和一定的页面功底,能完成这两个内容就可以初步进入页面前端的从业者行列了,但这就代表着我们 可以胜任页面开发的工作了?不,才刚刚开始!
2.与设计师的沟通和项目的参与
沟通很重要。先抛出几个问题:我们有没有和设计师探讨过某些效果对低端浏览器渲染效率影响比较大?有没有探讨过部分效果可以用 CSS3 实现从而使得结构更加简洁清晰?有没有在代码和视觉中寻追求过平衡?页面前端的开发向基本用户,编写的代码也直接作用在浏览器上,我们有义务对页面的稳定性和渲染效率负责。我们也经常碰到项目在总体进度压力下导致的设计与页面前端开发同步进行,这时更有必要尽量多地获取项目信息,了解我们还要做些什么,这些可以帮助我们充分考虑重用和框架拓展。
3.良好的页面结构
页面结构的编写好比盖房的地基建设,其好坏会直接影响到 CSS 代码的质量、js 开发、后台开发还会影响到以后的页面拓展、迭代和页面调整。拿到视觉稿后,不要忙着动手开始,多观察思考。先分析布局,划分框架,然后规划结构,编写代 码。特别在大型项目中,合理使用模块化的开发不论从整体进行还是拓展维护都有相当大的好处。
4.关于 hack
很多同学在页面开发时上网搜索最多的就是 hack 了,是否我们完全要依赖 hack 来实现页面兼容性,答案是否定的。大家经常比喻 IE6 向我们撒了一个谎,结果我们要再撒一百个谎来圆这个谎。不否认 IE6 经常让我们口吐鲜血,但不代表我们用更多的“谎言”来弥补就可以心安理得。大部分情况下可以通过变换思路调整 HTML 结构,或使用一些虽然无法解释但相对安全的 css 来干掉 hack。谁都无法预计使用 hack 什么时候会让我们栽一个大跟头。比如触发 layout 或 position:relative 就可以帮助解决很多 IE6 的问题。
5.优美的代码
现在很多 web 项目功能复杂,代码规模也会变得很庞大,如何更好地进行协同开发和维护是我们面临的一个问题。需要考虑完善统一的规划,还有要养成良好的代码开发习惯才会在面临各种情况时游刃有余。翻阅页面代码,看到合理的标签使用、良好的注释、清晰的代码结构、用意准确的 css 不仅犹如欣赏一个艺术品,更为下游开发和协同开发降低了不小的沟通成本,我们有什么理由不去这么做呢?举个反面例子:div 滥用是现在比较典型的一个问题。数数看自己使用的标签有多少个呢?不同的语义都该使用对应的标签代码,特别是 HTML5 提供了更丰富的语义化标签,它们都苦苦地在等待战场上的冲锋号,让我们去解放它们吧!
6、具有企业家的精神
最优秀的开发人员不会是游手好闲者。对他们来讲,产品的成功不仅仅意味着他们的薪水有着落了。因为他们在工作中热情饱满,他们是为了项目有更好的发展而工作,而且会一往无前。
7、测量两次,下刀一次。。。但测量不要多于三次
开发人员可能会犯的最糟糕的错误之一就是还不知道要干什么呢,就一猛子扎到代码里去了。(当他们把这种做法称作敏捷开发时情况更为糟糕,好像用敏捷两字就 能让情况好转似的)。当伟大的开发人员跳进代码里去的时候,那是因为需求规格说明同他们以前实现过的某种做法十分相似。伟大的程序员在面临新问题时,他们 会进行思考、计划和研究。
开发人员当中最最优秀的不会堕入“分析瘫痪者(analysis paralysis)”陷阱。他们懂得要对某些事情小心谨慎(比如涉及钱或个人数据 时),只有这些特殊领域才适合我所说的“要测量三次”。任何超过三次的情况发生就意味着你在浪费你的时间(除非在鲜有的特例中,比如核反应堆、宇宙飞船、 对冲基金会计系统)。
在某个特定的时间点就要停止计划,开始编码,然后再看看你的计划在哪些方面需要进行相应的调整,这一点非常重要。顺便说一下,这就是我为什么成为敏捷方法拥趸的原因之一。我所知道的最优秀的开发人员在计划不再合适或者发现计划有缺陷时,都会愿意将计划放弃掉。
更多web前端技术,加群434623999
页面结构的编写好比盖房的地基建设,其好坏会直接影响到 CSS 代码的质量、js 开发、后台开发还会影响到以后的页面拓展、迭代和页面调整。拿到视觉稿后,不要忙着动手开始,多观察思考。先分析布局,划分框架,然后规划结构,编写代 码。特别在大型项目中,合理使用模块化的开发不论从整体进行还是拓展维护都有相当大的好处。
4.关于 hack
很多同学在页面开发时上网搜索最多的就是 hack 了,是否我们完全要依赖 hack 来实现页面兼容性,答案是否定的。大家经常比喻 IE6 向我们撒了一个谎,结果我们要再撒一百个谎来圆这个谎。不否认 IE6 经常让我们口吐鲜血,但不代表我们用更多的“谎言”来弥补就可以心安理得。大部分情况下可以通过变换思路调整 HTML 结构,或使用一些虽然无法解释但相对安全的 css 来干掉 hack。谁都无法预计使用 hack 什么时候会让我们栽一个大跟头。比如触发 layout 或 position:relative 就可以帮助解决很多 IE6 的问题。
5.优美的代码
现在很多 web 项目功能复杂,代码规模也会变得很庞大,如何更好地进行协同开发和维护是我们面临的一个问题。需要考虑完善统一的规划,还有要养成良好的代码开发习惯才会在面临各种情况时游刃有余。翻阅页面代码,看到合理的标签使用、良好的注释、清晰的代码结构、用意准确的 css 不仅犹如欣赏一个艺术品,更为下游开发和协同开发降低了不小的沟通成本,我们有什么理由不去这么做呢?举个反面例子:div 滥用是现在比较典型的一个问题。数数看自己使用的标签有多少个呢?不同的语义都该使用对应的标签代码,特别是 HTML5 提供了更丰富的语义化标签,它们都苦苦地在等待战场上的冲锋号,让我们去解放它们吧!
6、具有企业家的精神
最优秀的开发人员不会是游手好闲者。对他们来讲,产品的成功不仅仅意味着他们的薪水有着落了。因为他们在工作中热情饱满,他们是为了项目有更好的发展而工作,而且会一往无前。
7、测量两次,下刀一次。。。但测量不要多于三次
开发人员可能会犯的最糟糕的错误之一就是还不知道要干什么呢,就一猛子扎到代码里去了。(当他们把这种做法称作敏捷开发时情况更为糟糕,好像用敏捷两字就 能让情况好转似的)。当伟大的开发人员跳进代码里去的时候,那是因为需求规格说明同他们以前实现过的某种做法十分相似。伟大的程序员在面临新问题时,他们 会进行思考、计划和研究。
开发人员当中最最优秀的不会堕入“分析瘫痪者(analysis paralysis)”陷阱。他们懂得要对某些事情小心谨慎(比如涉及钱或个人数据 时),只有这些特殊领域才适合我所说的“要测量三次”。任何超过三次的情况发生就意味着你在浪费你的时间(除非在鲜有的特例中,比如核反应堆、宇宙飞船、 对冲基金会计系统)。
在某个特定的时间点就要停止计划,开始编码,然后再看看你的计划在哪些方面需要进行相应的调整,这一点非常重要。顺便说一下,这就是我为什么成为敏捷方法拥趸的原因之一。我所知道的最优秀的开发人员在计划不再合适或者发现计划有缺陷时,都会愿意将计划放弃掉。
更多web前端技术,加群434623999