Web前端应该有什么好习惯

Web前端应该有什么好习惯

 

前端是面向用户的，同时前端是面向设计师的。与设计师默契的相互配合，能最大限度的展现设计的水准，让用户满意，同时体现前端的价值。

好的工作习惯是对工作的体会，从一系列发生过的事情中抽出来的。能够帮助前端在工作时有预兆的发现可能重演的麻烦，避免问题，促成事情顺利完成。

一．工作中的习惯

简言之就是经常性地小结，与同事良性沟通。适用于所有工作，前端有前端的独特之处。

 

Web前端的小结很具体化，也是有依据的

比如：收到一张宽高比1:2的效果图。自行按照该比例完成了页面的制作，自己觉得做的不错。但是结果可能是，设计师拿着自己2:3的苹果手机，质问“怎么不能一屏显示完。我不想要旁边的滚动条，别人的都是一屏显示的”。

事发之后看待这种情况，首先可以肯定不完全算是设计的问题，当然程序员也很无辜。

反正程序员和前端要协助，保证要在不影响项目进度的情况，重新把事情做好，尽可能满足项目需求。程序员或者可以考虑适当调整布局（比如隐藏次要内容，或者修改一些组件的外观形状），注意，一定是在设计师允许的情况下进行。

Web前端做完的东西一定要让设计师挑毛病

一张简单的页面，可能不会出什么大的技术问题。自己也仔细在多个浏览器下测试过，确实都正常。但这种时候，问题往往存在着，而且这些问题都是非技术的。自己很难发现，但设计师一眼就能查出。设计师会告诉你，你的红色色值不对，她要的是#ff0033。你的字体和她要的不一样，或许设计师会考虑给你这几个字的图片（如果前端程序员解释说额外的字体库体积太大，会延长页面加载时间）。设计师会说还有很多很多地方，必须修改。等过了设计师这关，设计勉强点头认可，这才告一段落。或许几天后设计师还会告诉前端，希望把哪里再调整一下，效果会更好。不要埋怨，这是前端份内的职责。这样的过程最终能让你的工作更出色，做出来的东西更完美。

Web前端要正视自身的不足

设计师想让程序员做出呼吸的动画效果（因为她无意中点开了一个网站，看见屏幕中一个巨大的椭圆形，不规则的“蠕动”，新鲜感冲昏了头脑）。没经验的程序员会紧张，甚至尴尬。怎么好意思说自己不会呢。事实上，不坦白又怎样。再说，这种特效根本就是鸡肋，实现了意义也不大。至于用户会有多喜欢，还不确定呢。前端可以笨拙地模拟出类似效果，但设计师的标准是不能接受很山寨的模仿的，并视之为完全不同的东西。所以前端一开始就不该硬撑，这能避免麻烦。

 

Web前端的“妥协”

当冲突发生，为做成事情做出自己的努力，这不是妥协，没有人应该妥协

设计师想让按钮在被点击后，触发很有爱的弹动特效。前端程序员让设计师提供一组图片，设计师说代码很好做的。设计师坚持，于是程序员就开始堆代码。看到生硬的弹动效果后，设计师很失望。追求完美的设计师还是决定亲力做一组图。

前端用自己的努力换来了——以后设计师会静下心来做组图，必要时，删掉动画效果。

一些网页或者app界面中都会出现很生动有趣的画面，简洁的图形元素，精准复杂的运动轨迹，碰撞或者很Q的弹动。有的设计师会毫不犹豫的认为，这些美妙的过程是代码控制实现的。不曾想过代码也有软弱无力的时候，这种情况就是最典型的。所以，看到这里，设计师们就该明确意识到，下次的高表现力动画一定要通过自己一张张图绘制了。其实，十几张就够了。设计师的十几张图，绝对胜过程序员一大堆没用的代码。

Web前端应该认真处理后台的反馈，并反馈意见

前端与后台程序员的关系也很奇妙。就像很多时候设计师做完效果图扔给前端一样，前端也会不自主的把写好的静态页面扔给后台。问题来了，后台程序员不喜欢看到大堆的样式属性，他需要的是页面清晰的结构，方便找到准确位置以插入一串字符。后台不开心了会抱怨。

前端要不定时的查看，当静态页面被后台改成动态页面后的模样。有时候后台人员会不小心的改变页面的内容，并且自己没有发现，还觉得动态页面和静态页面保持一致。不一样的地方前端一眼就能看出来。

Web前端要进行新技能储备，但应该是与自身工作独立开的

不要刻意追求新的技术，但是可以关注一下，增长见识。

新特性可以很方便的实现一些效果，但是当布局混乱不堪的呈现在一部老旧的设备上时。前端会忍不住埋怨——干嘛不换新的设备。但最后还是妥协了，放弃新特性的使用，换回使用了很久的那一套东西。或许，再等几年才合适用当下的新技术。新技术，新特性更像是一种长期的投资，或者是一种谈资。

 

 

二．编码习惯

不得承认良好的编码习惯非常难形成。或者前端可以这样做，编码过程中随心所欲的写——不让自己难受，但是编码完成之后对代码重新进行整理——方便项目中的其他人。

 

Web前端工程师的开发基于html/css/javaScript,参考了他人的编码习惯，归纳如下

css习惯

1、检查HTML元素是否有拼写错误、是否忘记结束标记，是否弄错DIV嵌套关系等等，这是最低级的错误，但往往是很多百思不得其解之后恍然大悟的东西。建议用专业的代码编写工具来检查代码错误

2、检查CSS是否正确，类同第一条，都是最容易犯的低级错误。注意拼写是否错误以及是否忘记}等等。是否重设了默认的样式。
3、某些属性如margin、padding等，不同浏览器会有不同的解释。因此最好在开发前首先将全体的margin、padding设置为0、列表样式设置为none等

4、确定错误发生的位置，用注释来排除错误。
如果错误影响了整体布局，则可以逐个注释div块，直到注释掉某个div块后显示恢复正常，即可确定错误发生的位置

5、利用border属性确定出错元素的布局特性。
　　使用float属性布局一不小心就会出错。这时为元素添加border属性确定元素边界，错误原因即水落石出

6、float元素的父元素不能指定clear属性。
　　这是Mac IE的的bug，MacIE下如果对float的元素的父元素使用clear属性，周围的float元素布局就会混乱

7、float元素务必指定width属性。
　　很多浏览器在显示未指定width的float元素时会有bug。所以不管float元素的内容如何，一定要为其指定width属性。切记，否则会麻烦狠得多

8、float元素的宽度之和要小于100%。
　　如果float元素的宽度之和正好是100%，某些老的浏览器将显示不正常。因此请保证宽度之和最好小于99%

9、float元素谨慎指定margin和padding等属性
　　IE在显示指定了margin和padding的float元素时有bug。因此谨慎对float元素指定margin和padding属性。也可以使用hack方法为IE指定特别的值

10、是否忘记了写DTD
　　如果无论怎样调整不同浏览器显示结果还是不一样，那么可以检查一下页面开头是不是忘了写DTD

11、因为要兼容各大浏览器，页面编写完成后记得在不同IE版本下和其他常用的浏览器如FireFox、Opera、Safari...中进行确认测试

Javascript编程风格

程序员固然可以自由选择编程风格，但是好的编程风格有助于写出质量更高、错误更少、更易于维护的程序。

所以，有一点应该明确，"编程风格"的选择不应该基于个人爱好、熟悉程度、打字工作量等因素，而要考虑如何尽量使代码清晰易读、减少出错。你选择的，不是你喜欢的风格，而是一种能够清晰表达你的意图的风格。这一点，对于Javascript这种语法自由度很高、设计不完全成熟的语言尤其重要。

最流行的有两种。一种是起首的大括号另起一行：

　　block

　　{

　　　　...

　　}

另一种是起首的大括号跟在关键字的后面：

　　block {

　　　　...

　　}

一般来说，这两种写法都可以接受。但是，Javascript要使用后一种，因为Javascript会自动添加句末的分号，导致一些难以察觉的错误。

　　return

　　{

　　　　key:value;

　　};

上面的代码的原意，是要返回一个对象，但实际上返回的是undefined，因为Javascript自动在return语句后面添加了分号。为了避免这一类错误，需要写成下面这样：

　return {

　　　　key : value;

　　};

因此，

规则：表示区块起首的大括号，不要另起一行。

、with语句

with可以减少代码的书写，但是会造成混淆。

　　with (o) {

　　　　foo = bar;

　　}

上面的代码，可以有四种运行结果：

　　o.foo = bar;

　　o.foo = o.bar;

　　foo = bar;

　　foo = o.bar;

这四种结果都可能发生，取决于不同的变量是否有定义。因此，

规则：不要使用with语句。

、相等和严格相等

Javascript有两个表示"相等"的运算符："相等"（==）和"严格相等"（===）。

因为"相等"运算符会自动转换变量类型，造成很多意想不到的情况：

　　0 == ''// true

　　1 == true // true

　　2 == true // false

　　0 == '0' // true

　　false == 'false' // false

　　false == '0' // true

　　" \t\r\n " == 0 // true

因此，

　　规则：不要使用"相等"（==）运算符，只使用"严格相等"（===）运算符。

、变量声明

Javascript会自动将变量声明"提升"（hoist）到代码块（block）的头部。

　　if (!o) {

　　　　var o = {};

　　}

等同于

　　var o;

　　if (!o) {

　　　　o = {};

　　}

为了避免可能出现的问题，不如把变量声明都放在代码块的头部。

　　for (var i ...) {...}

最好写成：

　　var i;

　　for (i ...) {...,}

　　规则：所有变量声明都放在函数的头部。

、new命令

Javascript使用new命令，从建构函数生成一个新对象。

　　var o = new myObject();

这种做法的问题是，一旦你忘了加上new，myObject()内部的this关键字就会指向全局对象，导致所有绑定在this上面的变量，都变成全部变量。

　　规则：不要使用new命令，改用Object.create()命令。

、始终保持代码优化

经常思考以什么样的方法去优化你的应用程序是非常重要的。下面我分享一下我的示例——三个步骤让你成功完成最终开发。

 

1、让你的程序能够运行。

2、让你的程序能够正确/完美的运行。

3、让你的程序能够快速的运行。

 

保持上面列出的顺序你将会得到一个可观的结果.另外：你必须确保你的优化是建立在能够正常运行并且是正确的代码基础上的，而不是工作进程中的代码堆。

 

三．小结

 

不要把习惯看成是约束，好的习惯能让你受益非浅。