←首页

好久没更博,看了上一篇时间是两个月前,吓我一跳。
换了工作以后,经常晚上11点多,12点回到家,确实有点忙,但没时间总结是自己的借口。

工作到今天正好一年,待过两家公司,做过面向用户的前端,也做过管理系统的前端,现在主要的还是移动端的活动页。每天都在写业务相关的代码,怕久而久之沦落为廉价劳动力,所以最近在想如何能提升自己的价值。

学会砍需求

第一课是拿着菜刀砍你的需求方

不做,老子不做

举个栗子,上周接了个需求,要做个合作商的推广活动,用户通过我们的 h5 去购买合作商的产品可以拿到优惠券。开评审会的时候,产品经理噼里啪啦说了一堆,管理后台可以配置活动城市,产品名称,价格,介绍等等之类一系列的内容。粗略排了一下时间,完成他说描绘的宏图霸业,前端至少需要三周的工作量。加上后台测试,就是月为单位的活动了。

然而,这个活动报名时间只有三天,三天后活动下线,再也找不到入口,并且展示的商品只有十五个。

**产品经理!!!

需求评审会上各种砍需求,把与活动参与逻辑与页面展示内容分隔开,前端通过 JSON 配置页面展示内容,JSON 直接在运营后台配置。把乱七八糟的配置直接写在 JSON 里面,后端提供另提供接口返回给前端,实现了同样可配置的活动页面,最终前端花了四天,提测。

学会砍需求并不是为了让自己偷懒,而是思考把时间花在更有价值的地方。花了一个月的时间去实现了一个只使用三四天,并且内容与团队主要目标不符的活动页,简直浪费生命。程序员有权利对不合理的需求 say no!

主动思考开发的目的

明确你在做的页面最终是面向什么用户,用户通过你的页面需要完成什么目的,比方说做公司内部管理页面,以运营管理系统为例,主动思考运营同事通过这个页面需要达到什么目的,以及如何提高他们的工作效率。

考虑这个的原因主要有两个,提需求的人不懂代码,或者他们认为更好的方式会带来更大的开发成本,而你是了解需求,并且知道开发成本的人。

上篇文章说到的,前端实现脸萌,其实一开始我拿到的交互稿是这样的

初

运营同事通过手动填对应组件的 id 还组装头像,实现起来只需要半天。但是有个严重问题,配的人并不知道他配出来的东西长什么样,无法预览,填太多东西容易混淆。配 1个头像需要填 12 个 id, 填 100 个头像需要 100 * 12 次查找组件。

思考一番,我决定不采用这种实现方式,宁愿多花些开发时间做一个更合理的脸萌。最终实现方式是跟客户端一模一样的。

脸萌

点点点…
Done!

开发时间多了 3 天,但是这种实现减少了运营人员配置的时间、沟通成本,犯错概率。

了解需求,执行更人性化,更合理的实现方式。

代码复用、脚手架

砍完需求进入开发阶段。

脚手架

做多几个活动页之后,你会发现其实同一个 UI 设计师提供的稿子大同小异,很多公用的样式,比如页面上的弹窗,在上一个活动用过的东西,设计师直接搬过来改几个文字继续使用。(保持 UI 的统一性)

再抽象一点,弹窗这个行为几乎是每个活动都有的,抽成一个通用组件,使用的时候进行才内容填充以及特异行为的事件绑定,这样,下个活动页就可以直接复用这个通用组件。

页面稍微庞大一点,就可以考虑写个脚手架,所谓脚手架就是一些 template ,通过配置不同的信息拉取不同的 template ,快速搭建出页面的雏形。

template

页面雏形

在熟悉页面常用的模式之后,代码模块化,模块抽象化,多写些通用组件,并且减少组件之间的耦合。使用通用组件应该像排插一样,插上即用,用完就撤。

说到代码复用,顺带提一下最近发现 vscode 的代码片段特别好用,配置你常用的代码片段,设置插槽,那么在对应格式文件编辑时,输入关键字即可输出代码片段。

vscode 代码片段

这类代码很简单,但是几乎每个页面都需要一样的。简单配置一下可以节省不少复制粘贴修改的时间。

代码片段演示

工作流

开发过程中会遇上各种需要优化的问题,这些问题产品经理,设计师可能并不关心,但是作为有点情怀的程序员都应该关注的点。

比如展示相同内容的图片,使用不同格式可能体积会差十倍。裁切合适尺寸的图片,选择合理的图片格式,采用可接受的压缩算法,最终每个用户节省几兆的流量。

手动执行上面的操作,一轮下来一个小时就不翼而飞。重复劳动应该交给机器来实现,使用

轻松搞定,再也不用在笨拙的一个个优化了。

1
2
3
4
5
6
// 批量设置图片大小
sips -Z 320 640 *.jpg
// 批量转 jpeg
sips -s format jpeg *.* --out jpegs
// 批量转 png
sips -s format png *.* --out pngs

现在的前端开发基本都会用上 webpack,gulp 之类的工具。这类工具提供接口,插件,我们只需要写少量的配置代码就能执行。把那些重复的任务写成代码交给机器执行,可以节省我们很多重复操作的时间。不使用工具,那你就得手动处理,可能注释一行代码就得花你两分钟。

可以用代码解决的问题,尽量不要人工拼体力。

小工具

除了业务开发之后,还遇上些其他让你不爽的事,比如后端团队使用 apidoc 自动生成接口文档。可以正常使用,但是我嫌 apidoc 页面写得不好,每次复制接口都很容易复制到其他内容,忍无可忍手动写个页面插件吧。

结合 tampermonkeyclipboard.js,实现几个常用的复制操作。想要复制什么内容,点一下即可。

页面插件

小结

说到最后,提高开发效率就是时间成本问题,投入少量的的时间能够完成同样的效果,或者是稍微多投入点是时间,节省自己和别人大量的时间,这样我们就都有了更多灵活的时间去改变世界了。

如需转载,请注明出处: http://w3ctrain.com/2017/07/01/effective-work/