从毕业到现在也工作了一年多了，在这一年多里面，我感觉我是很幸运的，有和谐的团队氛围、哲学的leader和开放的环境。在这样的环境中，我的成长不仅仅局限于技术栈的积累，更重要的是收获了一个清晰的发展方向，让自己在前端的道路上看的更远，更清晰。这里主要分享下我在成长道路上一点收获和想法，主要讲述了一些前端领域需要注意的地方，希望可以带给新人一些启发，让他们在前端的道路上走的顺畅点。
一、可用
有多少人是和我一样，因为简单的几行HTML+CSS，花费极短的时间就可以看到一个酷炫的页面而爱上前端的？正因为在大学期间有幸接触到html让我爱上了前端的及时性，远远比枯燥的C/C++/Java有趣多了，动动手指就可以看到效果，难道不是一件让人很兴奋的事情吗？
言归正传，初入前端，自以为能写几行html+css构建一个页面就是已经很有成就感了，在加上JS/JQ做点动效就天下我有的感觉。在这个阶段我们想的很简单，这段代码能用就行。
我们看到写出来代码能够在浏览器上跑起来，这已经是成功了。这个阶段我们不奢求什么，也没有想多复杂，只要能看到效果就是成功了。
此阶段，拥有舍我其谁的傲气，觉得自己无所不能（说笑哈）。
下面随便写个例子，看看你们能分析出什么问题来(随便写的代码，不确保可运行哈！)。
好好看看哦，据说可圈可点的问题很多哈，下面会有解释的。
二、 优雅
经历过一段前端生涯后，回头看看自己写的代码，你会发现真的是不堪入目，暗自耻笑自己当初坐井观天（我当初还在想其他人看到我这么糟糕的代码会怎么吐槽我）！
这个时候，你会开始思考如何写一段优雅代码，一段不会让自己都觉得恶心的代码。这个阶段其实很重要，因为这可能会决定你很久一段时间的代码风格。
为什么这么说呢，因为这是第一次思考该如何写一段优雅的代码，也许你会在网上找教程或者review大神的代码，一旦这些决定了你的思想，这就会跟随你很长一段时间，甚至一辈子！
所以，在这个时候你应该慎重思考并总结。最好能找一个有经验的前辈来review你的代码，让他给提点意见。
何为优雅的代码，这是仁者见，仁智者见智了，但我觉得基本的要求应该是简单有效、逻辑清晰、可维护。
何为优雅，我给不了你答案，但我可以分享下自己的做法：
理解需求：你需要清除的明白这个需求要求有什么效果、实现什么功能、解决什么问题。
这时候最忌讳的是拿到需求，简单了解了一下就开发敲代码的坏习惯，因为很多问题都是从此开始的。思考逻辑：最好可以在草纸上画出整个需求的流程图，明确到每一个操作的步骤，每一个分支。
技术选型（可行性分析）：明确用户定位，选择相应的技术方案。最简单的例子就是你的用户用的是什么浏览器，你需要兼容到IE几。深层次来讲就是分析哪种前端技术适合这个项目，既能保证项目质量和性能，又能提高开发效率。
愉快的搬砖…………
你要相信，这一切都不会浪费的时间，反而可以大大提高你的开发效率，同时保证项目质量。
三、 性能
在你能编写一手优雅的代码之后，你就必须关注性能方面了。如何提高性能是区别技术水平的一个重要指标。
也许你会想性能怎么体现，现在的浏览器那么高级，哪里会有什么性能瓶颈。如果你这样想就是你还没有意识到性能的重要性。
性能是微妙的，不易察觉，但是却实实在在存在的。性能的差异在平时可能看不出来，但是在达到某一个临界点，就会很明显的体现出来，甚至会让你的项目崩溃。让我们来看一个小小的例子：
var testArr = [1,2,3,4,5,6,7,8,9,10];
for(var idx = 0; idx < testArr.length; idx++){
// TODO
}
for(var idx = 0, length = testArr.length; idx < length; idx++){
// TODO
}
这是一段很简单的循环代码，他们实现的功能一样，但是他们性能却有差异。第一个循环，每次做判断的时候都会去计算testArr的长度，而第二个循环却把testArr的长度赋值给了length，所以只需要计算一次就可以。
其实想要提高性能，并没有多大的门槛，很多小的细节都可以优化性能，这些都需要大家平时去积累去探索，久而久之，你会发现自己并不需要刻意去优化什么，但是写出来的代码性能却比别人要好。
说了这么多屁话，其实也就是想提醒大家有空可以关注下性能方面的知识，这对成长和发展有很大的帮助。
性能可大可小，小到代码的优化，大到架构的调整，但是无论大小，都必须从基础做起，如果你连随手可以拿来优化代码的小技巧都不愿当成习惯，那还拿什么来谈性能。
用户体验
用户体验这已经不是关系代码层面了，而是在一个思想领域的提升。这种思想应该从一而终的贯彻到我们的生涯中，必须时刻在我们的开发中体现。
用户体验是前端开发开发者必须承担的职责，我们是最接近用户的开发者，用户体验的细节最直接的是从我们这里体现。所以这就要求我们必须站在用户角度的思考问题，在工作中，我们不能够拿到需求就直接进行开发，而是需要对用户体验进行深入思考，如果存在交互或者设计问题我们应该及时提出，向设计和产品反馈。
用户体验是什么？
用户体验（User Experience，简称UE/UX）是一种纯主观在用户使用产品过程中建立起来的感受。但是对于一个界定明确的用户群体来讲，其用户体验的共性是能够经由良好设计实验来认识到。计算机技术和互联网的发展，使技术创新形态正在发生转变，以用户为中心、以人为本越来越得到重视，用户体验也因此被称做创新2.0模式的精髓。
简单的例子来说，用户在视觉和交互式直接影响着用户的体验，界面的颜色、操作流程、响应速度、学习成本等等都属于用户体验的一部分。
用户体验是一种妙不可言的，不像视觉，架构，交互那样是可以事先假设和设计，一百个人就有一百种用户体验，我们能做的就是根据用户操作习惯和反馈进行模拟优化，做出最能让用户感到满意的产品。
如何打造用户体验？
用户体验主要体现在五个层次：
- 战略层——目标、群体、需求
- 范围层——功能和内容，我们想要什么和用户需要什么
- 结构层——交互信息与信息架构，如何将产品的功能连接成一个完整的产品
- 框架层——主要体现在视觉、界面设计等方面，如何让用户感到愉悦
- 表现层——最接近用户的体验，确保设计、交互、信息等展示给用户
有需要了解用户体验的可以前往这里了解漫谈用户体验五要素
具体实施有已下几个要点：
- 有用——确保该功能是对用户有用，如果一个功能在用户群体中只用5%的人会使用，那么这个功能是否可以隐藏或者削减；
- 易用——这关系到交互流程，用最少的流程，最小的学习成本去设计交互。
- 友好——从视觉和文案让用户感到愉悦，比如一个很常见的菊花（loading）就可以让用户感觉等待时间的减少，还有最近很多产品都在做的情感化体验。
- 视觉——视觉是用户第一时间能感受到，视觉方面不仅仅需要美感，还需要起到引导作用。
- 品牌——iPhone就是一个奇迹般的品牌设计，用户对品牌的认可会增进用户对产品的认可和增加用户的体验好感。
那么，作为前端我们能做什么？上面说的不应该都是产品和设计师去考虑的吗？不，这些同样也是我们的职责，我们作为最接近的用户的群体，我们应该比设计和产品拥有更多用户体验思维。
产品也许不熟知技术，可能在思考的功能的时候并不能把握功能易用性，设计注重的设计美学，在完成设计稿的时候可以忽略了交互的一致性，而我们作为最熟悉产品的人，难道我们不应该在这些方面提出我们的建议。
举个栗子：
1、产品说要增加一个查询功能，要非常详细，一行显示；
2、后端拿到需求，需要查找N个数据库，N格表，平均耗时5秒才能返回数据
3、设计按照产品的需求，弄了一个设计稿，一行需要展示20个字段信息；
最终到我们手里了，怎么办？我们是直接按照需求将这个功能开发出来吗？我想任何有经验的前端开发者都不会立即按照这些进行开发。
我们需要思考，一行显示那么数据，布局应该如何划分，小屏该如何展示，是否可以将一些不必要的信息隐藏，怎么样才能降低用户的等待时间…………
我们思考过后，最终方案可能就是：
1、后端只需返回必要信息，尽量减少查询时间；
2、一行显示合适的数据量；
3、点击详细情况再进行异步获取数据；
前端是贯穿整个产品的关键点，我们是最能发现问题的群体，所以这些都是需要我们去推动，只要有不合理的地方我们都应该提出质疑，去向产品、技术、设计去反馈，去推动用户体验的改善，而不是仅仅关心我们代码。
前端开发者需要把控的用户体验细节应该体现在方方面面，无论是字号、颜色、行距、交互等等都需要进行思考这些设计是否有利于提升用户体验。
推荐大家读一篇文章一个页面重构工程师眼中的“用户体验”，里面讲述了大部分前端必须关注的用户体验细节。
吐槽一下
之前我在一家快递公司的公众号进行了投诉，我能感觉到他们的交互设计师一定是一个“大牛”，一个交互至少可以“减少”70%的投诉率。他们是这样做的，当你进入投诉页面，输入完投诉内容点击确定按钮，它会弹窗让你确定是否输入完成（蓝色确定按钮在右边），确定后弹出是否确定投诉（蓝色确定按钮在右边），最后弹出一个是否提交投诉内容，关键点来了，蓝色的按钮竟然是取消按钮，确定按钮是灰色的放在了左边。根据用户的操作的惯性，70%的用户都会直接点击取消！
这家快递公司的交互真是用心良苦，完全颠覆了交互设计的理念。
后记
这篇文章讲了那么多的废话，却没有将一些实质性的内容，因为写那么多废话只是想让初入前端的新人在这方面有一些意识。引导一些新人能多关注下代码的其他方面，帮助他们在前端的道路走得更加顺畅一些。
代码解读
回到最开始举例的那个代码，我给大家解说下在我眼中的不足：
也许我发现的问题也不是很多，但是可以看出，就这简简单单的几句代码也是拥有很大的优化空间，一入前端深似海，我们都需要好好努力啊！
参考资料
- 漫谈用户体验五要素
- 一个页面重构工程师眼中的“用户体验”
转载自疯子的博客