前段时间，我参与组织了一次分享会，谈论UI开发，主题是“革新”。
近两年，已经很少有纯讨论UI开发的话题，都时兴“全栈”或“全端”，从招聘，到应聘，各种分享会，整个行业趋之若鹜。一时间，只懂UI开发或者只懂前端的人，都多少有些紧张和焦虑，特别是前者，不知哪天就可能要“拥抱变化”。
有人说，要“一专多长”，也有人说，不要让职位成为束缚，艺多不压身。所以，没有去阻挡这个趋势的正确性和必要性。那我们到底要怎样？
这次的话题并不是突然有感而发，而是思考良久，但会后我们在讨论问题的时候又引发了新的思考：
每个任务之于我们的意义是什么，每个种类的页面会带给我们怎样的开发体验？每个工作阶段，我们有着怎样的经历和成长？
所以，就此开题。
做成，还是做好？
有一件事我印象很深，在第一家公司的时候，缺人，经理让我到网上去找，碰到一个简历看起来还不错的。
他很自信，说自己一般的页面都没问题，我问他，如果给他一个页面，他会怎么做，他说：
用div，里面套个列表，加个浮动，下面一个边栏可以设置左浮动，右边来个有浮动，加个margin……
寥寥数语，一个页面被他“做”完。
我当时也是如此，设计师把稿子给过来，我就用我犀利的眼神，娴熟的技术，把页面的结构一一拆解，然后噼里啪啦地敲起来，要不了多久，框架就搭出来，再开始调细节，背景、边距、边框、字号、字体颜色之类，一个页面很快做出来，再拿下一个，如此重复。
看似没什么问题，但问题往往是未知的，也是积累出来的。
前阵子，朋友换工作，去面试，也考到一个类似的问题，他问我应该怎样答，我简单给出如下几点：
– 首先，跟设计师确认，提供的稿子是否完整，是否有遗漏和错误
– 再者，问询一下页面之间的逻辑关系，是否要根据不同用户或场景，有不同状态
– 然后，更具体的交互行为是怎样的
– 如果出现异常，比如页面打不开、列表为空、404、过期、作废等，要怎样处理
– 列实现优先级和整体项目规划、规范
– 代码的扩展性、复用性和灵活性
– 图片和代码的优化，以提高性能
– 充分的体验和测试，把bug风险降至最低
两者的区别在哪里？
两者的目的相同，输出页面，制作产品，但区别是：
第一种，经不起挑战和推敲，稍有改动，可能就会破坏原有代码的结构和之前的规划；
第二种，既能做到代码的健壮性和可维护性，又尽可能地从各种方面照顾用户体验。
那么，怎样从只会写效果、做布局的简单人工，到达能够输出优秀作品的程度呢？
从小到大
可读性、可维护性
从我工作当中的一次事故说起，那时刚毕业没多久，在一家创业公司做企业站，企业站的模式都是类似的，“头部、banner、产品列表、行业新闻、关于我们”，稿子拿来之后，一边切，一边敲，敲了半天，基本完成，满满的成就感，准备伸个懒腰下班吃饭，突然发现电脑右下角提示我“系统错误，文件被破坏”，从来没见过那样的提示，慌了，经理正好从我身边经过，他帮我把文件另存，然后关闭，后来发现另存一份也没有用了，大部分的代码都丢了，真心悲剧。
我既不甘心又懊恼，只能再来一遍，但我并不想简单地重复之前的过程，毕竟已经做过一遍，就一边写一边想，怎样更清晰，更有条理，更便捷。（其实是为了早点下班~）
功夫不负有心人，原先写了大半天的页面，几乎从零开始只写了一个多小时就让它回到原样。
这个原样，只是看起来的原样，页面还是那个页面，代码却是不同的代码，模块更清晰，注释更详细易读，简单来说，就是“可读性和可维护性都更好”。
引起我更多思考的是，之前我为什么不那样写？为什么要拿来急着做，从头到尾的简单堆砌，而不是稍加审视和规划？
如果是小项目，这个问题还不明显，稍具规模的项目，它的必要性就显示出来，因为页面繁多，模块繁多，必须有组织和条理，并且，这种整理不是一蹴而就的，而是需要动态的，不定期的检查和整理。
适应性、可扩展性
第一次注意到这个问题时，我还不在腾讯，是一位腾讯的前辈想做个私人项目，项目需要做展示页面，他找到了我，我当然没怎么考虑就很荣幸地接受（就像现在的很多人看到大神就兴冲冲往上凑一个样~）。
我十分认真且谨慎地做完，发给他，等他夸我，他的确夸了我两句，怕是出于客套，然后就跟我说，哪里使用的某个方法不够好，不够灵活之类，其中就提出，页面底部的容器最好不要定高，而是使用padding把整个区域撑起来，这样的话，就算需要改变里面的内容，或增、或减，也不会对布局的视觉效果产生破坏性影响。
看似很简单且随意的一句话，在当时却像一根针一样刺破了我的固有思维——原来不是严格按照设计稿去精准实现才是最好。
以上只是举个简单的例子，真实的情形远不止于此，在大型项目里，甚至是某些小型项目，需求产生变动的可能性以及使用场景的不确定性，都会给我们造成一次次“打击”，比如说：
1、一个容器，你做的是容纳3个字或者5个字的情况，真正拉取数据的时候，它可能是10个字，结果是怎样，溢出？换行？还是截断处理？
2、一个tab结构，设计的时候是有两项，做着做着，突然说要再加一项或者两项，如果你当时严格按照两项去做了，这个时候不仅要改结构，还要改样式。
3、两个水平的元素需要垂直居中，你会用什么方法？position？vertical-align？margin？还是…如果有好几个元素大小不一怎么办？如果容器高度改变了怎么办？
暂举以上三例，有经验或者勤于总结思考的人，能够轻松应对以上三个问题，情况怎么变，代码都不需要改动，或者仅仅少量改动。
模块化
这要从一次项目沟通说起，当时我还是一名外包，我们三个外包和其他人在不同的地方办公（这是想说明，团队对个人的影响），有一次，我需要和那边的同事合作项目，同事看了我的代码之后，又是一顿挑毛病，当然，挑得我心服口服。
其中一个就是，我在模块里面命名的类，太过通用，比如：info、txt，这样以来，就很容易跟外面更大作用域或者通用样式相冲突，也容易被另外的样式覆盖，命名一时爽，随时就掉坑。
换种做法就会更好，比如：intro-txt或者 intro txt，这两种做法的目的也是不同的，intro-txt是个全新的类，样式要重新定义（标签定义的样式和可继承的除外），而intro txt，可能是对原有txt样式进行修改或者补充，比如，改大小、改颜色等。
BEM不就是为此类问题而生？
弱耦合
这是另一个注意点，还是举我跟同事的例子，有一次，一个项目涉及几个页面，页面中有几个数字，代表用户的收益，可能涨，可能跌，涨是红色，跌是绿色，在写第一个模块的时候，我把它定义在了模块内，后来写到第二个，依然没问题，等我把做完的页面给到同事之后，他就跟我说，你能不能把颜色的样式抽出来？因为总共好几个地方用到，抽出来的话，绿色我都加“green”，红色我都加“red”，这样就方便很多了。
相信大家都遇到过类似情况，拿到页面就开始写，数量少的时候还不明显，当项目越来越大就会发现，某些模块的某些属性是一样的，比如：标题、背景、边框、字体的颜色和大小，甚至是间距，相当多的重复，那么这些东西，就不适合被定义在任何一个具体的模块里，会造成代码的重复书写以至大量冗余，维护起来也是相当困难，适当地提取出来，不仅更清晰，还利于维护和复用。
OOCSS和Meta CSS不正是为此而生？
组件化
前面几点，似乎都是在样式层面对怎样编码更好进行讨论，实际上，每种思想都不能适用所有情况，因地制宜才是正解。
当我们把页面从大看小，分成模块，甚至细化到颗粒之后，似乎，还面临着别的问题，可以走一些回头路。
前面说了，不要太固化，要灵活，那么，是否有些模块它就是十分固化，特点鲜明，变动概率极小，又极具复用性？
答案是肯定的，比如：标题、按钮、表单、弹窗等等，这些东西，在大项目中一般都会有着一致性的设计，被复用的几率非常高，它们可以不属于任何页面和模块，而是单独抽离出来，每次使用，只需要直接引用，对其内容进行微调即可，比如，文案、宽高、颜色等，这样以来，再有相同的东西，就不需要走UI开发阶段，直接进入下一阶段了。
上面这些名词，你可能都听过，但如果没有足够的经验和思考，就会被自己暂时学到或做过的东西给局限住，产生一种“这样比较好么？可是为什么？”的想法，这里跟大家简要分析一下“为什么”。
当然，任何一种方法或者方式都被人推崇过，也被人吐槽过，我认为，站在任何单一立场去反对另一立场都是在耍流氓~
它们到底好不好，优势在哪里，劣势又在哪里，我们都可以客观看待，针对选用即可。
工程化——贯穿始终，相得益彰
一个怎样的项目，可以将其称为工程？一间房不算，一个石柱更不算，但一个建筑群，就可以。——量大
如果它不只是房子，旁边还有道路、停车场、花园等等，就不能按照一个方法去对待所有事情——多样化
这么多事情，不事先做评估和规划，材料不够了，房子把路占了，房子盖歪了，怎么办？——全局规划
一个人干吗，要么累到吐血也搞不定，要么等到猴年马月。——团队
都手动去做，砖一块块搬，楼爬上去？——工具
每栋楼占地多少，每种户型房子面积多大，怎么布局，甚至细化到每扇门的宽高。——规范化
厨卫用品、客厅用品、卧室用品，需要重新再造么？不需要。——组件化
别人，或者我们自己，有没有过类似的经验和成熟方案，可以拿来借鉴，能适用于现在的项目，能避免问题和提高效率的？——设计模式
以上几点，应该能够囊括一个项目需要考虑的大部分层面，也是多数人的学习和实践历程，每一个词汇你可能都熟悉，也都认为是合理的，但有没有过一个系统性认识？
小结
很多人认为前端门槛低，薪水高，就越来越多的人涌入，也看到很多人问“怎么学前端，才能跟某人一样厉害，一个怎样水平的前端能够拿高薪”等，个人认为，作为一项事业，需要长期从事且不断进步，才能有所建树，所以，首先应出于兴趣，而不是利益驱使，它能给自己带来成就感和愉悦感，能让自己不断精进去把产品做得更好，才是好的。
再谈“瓶颈”，每个人都会碰到这个问题，它可能出现在人身上，可能是技术，可能是业务，多数人离技术层面的瓶颈还有距离，大部分是在人，如若浅尝辄止，略有所成，便觉足够，则难有更多进步，再就是业务，这是多数人认为自己被束缚的原因。
怎样突破“瓶颈”，便是这篇文的论点—“挑战”—的来由。拿我自己举例，刚开始只做PC，且只做一种类型的企业站，常用组件还不用自己写，长期如此，就算做几十上百个站，我也只是个能使用几种有限布局方法的切图工人，故而革了自己的命，决然离去。相信不少人有过跟我类似的经历，只做一种终端，或只做某一类业务（邮件、后台系统、官网）等等，长期没有机会涉足其他，这不是其他东西难不难的问题，它再容易，你不去接触也是无法学会的，除了种类，还有量级，一直做着一个个小项目，文件怎么组织，代码怎么写，都不会出问题，没有遇到问题，就不会锻造出解决问题的能力。
所以，鼓励大家踏实学习基础知识的前提下，乐于尝试新事物，乐于接受新挑战，才能把自己的能力和思维水平提升到一个新的台阶，过程可能比较煎熬，但结果终归是甜的。
就絮叨这么多吧，下篇见~
