【UI开发大观】挑战的出现——从项目到自我

前段时间,我参与组织了一次分享会,谈论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,且只做一种类型的企业站,常用组件还不用自己写,长期如此,就算做几十上百个站,我也只是个能使用几种有限布局方法的切图工人,故而革了自己的命,决然离去。相信不少人有过跟我类似的经历,只做一种终端,或只做某一类业务(邮件、后台系统、官网)等等,长期没有机会涉足其他,这不是其他东西难不难的问题,它再容易,你不去接触也是无法学会的,除了种类,还有量级,一直做着一个个小项目,文件怎么组织,代码怎么写,都不会出问题,没有遇到问题,就不会锻造出解决问题的能力。

所以,鼓励大家踏实学习基础知识的前提下,乐于尝试新事物,乐于接受新挑战,才能把自己的能力和思维水平提升到一个新的台阶,过程可能比较煎熬,但结果终归是甜的。

就絮叨这么多吧,下篇见~

灵感_idea wechat
欢迎关注我的公众号“灵感周末”,每个周末推送优质好文!
给加个蛋呗