Cron自动续期命令失效导致网站SSL证书到期的解决方案

27 | 10 | 2017

前面写过一篇网站部署 Let’s Encript SSL Certificate 并启用 https 的教程:WordPress建站:SSL启用HTTPS全攻略

有网友反映,之前跟着教程做一切OK,但昨天发现网站 SSL 证书到期了(3个月前部署的SSL证书),打开网站的时候显示不安全,并且 https 上有个红色的失效划线,如下图所示:

之前跟大家介绍过 Let’s Encript 这个证书,优点是免费、部署快,但每次有效期只有90天,90天到期后证书需要续期。

检查看了一下,应该是当时没有正确执行证书自动续期的命令。首先,看看 cron 的状态:

提示:crond: unrecognized service

应该是当初没有安装 cron 服务,所以之前执行自动续期的 cron 命令并未生效。

处理办法:先手动把 SSL 证书续期,再安装 cron 服务,执行自动续期命令。


一、手动 SSL 证书续期

首先先手动续期一下,SSH 工具(如 Xshell )连接 VPS,并依次输入或复制粘贴以下命令回车执行:

停止 Nginx 服务(使用续期命令中的 –standalone 方法之前必须关闭 web 对 443 端口的占用,而 https 正用着 443,所以直接关闭 nginx )

执行完之后,等待执行。如果出现下面截图中的 Important Notes:Congratulations!  字样,表示证书已重新更新续期。

此时再重启 nginx:

经过这简单的 4 步复制,回车,替换域名 的操作,只需要 1 分钟,你的网站立即一切回归正常,https 变成绿色,小绿锁又回来了!

恭喜,你的网站证书又重新延期了 90天!


二、SSL证书利用cron服务自动续期

1)安装 cron 服务

依次输入以下 2 条命令并回车执行

成功安装 Cron 之后,启动 cron 服务。

2)启动 Cron 服务

执行后会出现:Starting crond:         [  OK  ]  的提示,表明启动成功。

继续执行开机启动服务命令,把 Cron 加入开机启动的服务列表中:

3)检查 Cron 服务状态

执行后会提示:crond (pid  xxxxx) is running…  代表正常运行中

4)执行 Cron 自动续期命令

把下面命令复制到记事本或文本编辑器中,然后把命令中的域名 example.com 替换成你的域名。替换完成后,复制。

以上代码含义是:每个月的1号夜里凌晨 1点10分开始关闭 web 服务,1点11分开始执行证书自动续期的命令,1点18分重新启动 web 服务。
第1个数字是minute,第二个数字是hour, 第三个数字是 date。其他的不用管。

复制完后,先别动(切勿粘贴执行)。输入以下命令:

输入此命令后,提示如下:

no crontab for root – using an empty one

此时相当于准备创建一个 root 用户的空白 crontab 文件,同时已经进入 vi 编辑状态。

在 vi 编辑状态下,请严格跟着操作步骤来!

按键盘 Ins[Insert] 键,进入 INSERT 模式,此时点击鼠标右键,粘贴上面从文本中复制的命令行(不支持 ctrl+v 快捷键粘贴)那3行命令,然后按 ESC 退出 INSERT 模式。

接着按组合键:shift + ;(冒号),会在当前窗口最下面一行出现一个冒号,此时输入 wq 然后回车,会保存文件并退出 vi 编辑模式。

退出 vi 编辑界面之后,此时会提示: crontab: installing new crontab

这时会生成 root cron文件。如果你想修改 root cron 文件,可以通过 /var/spool/cron 这个路径下载下来修改。

说明1)具体命令中的日期时间,你可以根据你的具体情况来修改。比如我的网站 3 月 30 日证书就要到期了,那么截图中我就设置 每个月 29号 16点 55分 开始执行命令。

如果你想设置成每个月5号的12点20分开始自动续期更新证书,
那么如下图,你可以设置分钟为20,时钟为12,日期为5。

这样在5号的12点20分,服务器会自动停止 web 访问服务,并在22分开始自动更新证书有效期,在30分重新启动 web 访问服务。

说明2)关于这一步 vi 直接编辑 crontab 文件的操作,如果你实在不会操作,被弄的晕头转向,那么也可以执行 crontab -e 命令进入 VI 界面后,直接按 shift+; 出现冒号后输入 wq,回车。即先生成一个空白的 root cron 文件。

然后再通过 Xftp(mac下可用transmit)通过 /var/spool/cron 这个路径找到 root 文件,用文本编辑器打开,粘贴那三行命令,保存上传覆盖原 root 文件。再执行下面的重启命令,也可以。

5)重启 Cron 服务使得命令立即执行

重启之后,一切搞定!

本文完!

WordPress建站:SSL启用HTTPS全攻略

25 | 10 | 2017

这阵子,外贸圈子里最热的就两个事情:

  1. 从2017年1月1日起,国家税务总局开始清查境外账户(CRS 体系下的非居民账户)
  2. 从2017年1月1日起,谷歌 Chrome 浏览器将会把采用 HTTP 协议的网站标记为“不安全”网站

第1)件事情我们先不论,后面文章再说。先说说第2件事。

Google 一直在推动网站从 HTTP 切换到 HTTPS。可以说,谷歌越来越偏爱安全级别高的网站。2014 年 8 月,Google 将 HTTPS 正式作为排名因素之一。

HTTPS 网站被认为是安全的网站,将会比 HTTP 的网站在排名上获得小幅优势。而在过去的两年中,谷歌对于 HTTPS 网站的网页抓取收录也在明显上升:

google-indexed-pages-in-page1

2014年1月-2016年1月 过去2年中谷歌收录的页面中,HTTPS 网页的收录量已经超过30%

而从谷歌官方人员 John Mueller(谷歌站长趋势分析师)的话中也可以看出来,谷歌会破开一切阻挠推行 HTTPS :

john-mueller

关于更多的信息,我就不列举国外消息了。看图说话吧,从别的网站上截的:

read-this

从2017年1月1日起,谷歌 Chrome 浏览器将会把采用 HTTP 协议的网站标记为“不安全”网站

谷歌官方博客消息原文:https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html


那么问题来了:谷歌会不会也在搜索引擎结果页面中标记 HTTP 网站为不安全网站呢?

答案是:很有可能。

那么我们外贸英文网站应该怎么办呢?HTTPS 的目的是确保交易类网站的安全,保证涉及网站平台账户信息,付款信息以及信用卡等信息不泄露。在SEO方面的作用是在 seo 上获取谷歌的好感,排名能够比 HTTP 网站提升一些,但提升幅度也很小。毕竟影响谷歌排名的因素多达200多个,这并不足以对整体网站排名权重产生根本影响。总体而言,

  • 如果你是 B2C 网站,因为会涉及到商城,购物车,付款和订单信息,在线支付等方面的因素,我认为很有必要启用 HTTPS。
  • 而外贸 b2b 网站更多地只是做个公司展示,产品展示,所以 HTTPS 的意义没有 B2C 网站那么大。但加上一个是可以提升“bigger”,另一方面访客也会觉得安全。

接着来说怎么给网站从 HTTP 换用 HTTPS。总体来说分为四个步骤:安装 SSL 证书、部署 SSL 证书、修改网站配置文件conf 、网站 URL 中 HTTP 替换为 HTTPS。

一、安装 SSL 证书(Let’s Encrypt)

SSL 证书有免费的也有收费的。具体就不科普了。免费的也可以用,如大名鼎鼎的 Let’s Encrypt SSL certificates.
(2017.6月更新:Let’s Encrypt 已正式更名为 Certbot )

分两种情况吧。鉴于大多数外贸建站的朋友用虚拟主机 Bluehost,也有小部分朋友用 VPS 。那么还是分开说:

在 Bluehost 上安装 Let’s Encrypt 证书有两个小问题: 1)费用问题,看你是否能接受:你买的 Bluehost,5.45美金/月。为了安装证书,必须买独立IP,要再花 $5.99/月(以前才$3.33/月),这就11.44美金/月了。 然后呢,Bluehost 自己也卖付费的 SSL证书,$4.17/月。 你跟他说我不用你们家的付费证书,我要用第三方的免费 Let’s Encrypt 证书, BH 客服肯定不爽,极力推荐你他们自己的付费 SSL证书,在你再三要求之下,极不情愿地帮你配置了免费证书。这都 11.44美金/月了。 如果你觉得用了 BH 的主机和独立IP,也一起用 Bluehost 家的付费证书吧,一劳永逸。那么你就还要掏 $4.17/月。加一起多少了?$15.61/月! 而 Linode VPS 呢?$10/月搞定,还能自己装个FQ 的SS。所以虚拟主机 Bluehost 上用 HTTPS,那费用反而比 VPS 还高。 2017.1月更新:不需要了,感谢 WordPress。WordPress官方要求 Bluehost 尽快提供免费的SSL证书,否则从WP官方推荐的主机商名单中除名。Bluehost 迫于压力,已经推出了免费的SSL证书,无需购买独立IP即可安装(第一个网站免费SSL,第二个网站要加SSL就必须升级到独立主机才可以) 2)网站个数问题:Bluehost 要求每个要加 SSL 证书的网站都得配备独立 IP,而且每个 cPanel 账户只能加一个 IP,所以如果一个账户有几个网站那就尴尬了。

本文主要介绍 VPS 怎样安装部署 SSL 证书并启用 HTTPS。

下载和安装证书

1)先安装 git 包

连接上 VPS 后,在 Xshell 上粘贴命令(每条命令用鼠标右键复制粘贴,回车执行即可。不支持 ctrl+v 粘贴):

2)下载证书包

3)进入证书目录

二、创建并部署 Let’s Encrypt SSL 证书

继续命令行执行:

注意:

  • 上面命令中的 email 地址是方便你接收证书密钥回复以及紧急信息的,尽量填写企业邮箱或者 gmail 邮箱,QQ邮箱应该也可以,你可以填写试试。
  • 你的网站域名如果是 xyz.com,那么上面就改为:-d www.xyz.com -d xyz.com

建议先把上面命令复制粘贴到记事本里,把 www.example.com 和 example.com 先替换好,然后粘贴执行。

然后等待:

waiting

接着,会询问你是否同意的协议。agree 的话,输入 a,回车。此时就准备创建证书了。

注意:如果你之前看过我的 VPS 教程,在 VPS 上安装过 FQ 的 shadowsocks,那么这一步会提示 443 端口被占用,无法继续。由于 SS 是用服务器的 443 端口,而且目前进程默认开启,所以不能继续安装。此时中止安装,回到 Xshell 命令行界面,输入:service shadowsocks stop  然后回车。会停用 shadowsocks,把 443 端口空出来。

stop-ss

如上面截图所示,显示: INFO:loading config from /etc/shadowsocks.json stopped Stopping Shadowsocks success 这表明我们已经关闭了 SS 进程。此时重新粘贴上文蓝色粗体部分的命令(注意 example.com 替换成你的域名),然后回车执行,重新执行安装步骤。

最后成功创建证书。

一般情况下,屏幕显示创建的信息如下:

此时粘贴执行命令:

会列出该目录下,证书文件存放的网站文件夹,文件夹名就是网站域名。

cer1

注意看一下是主域名还是 www域名。这很重要!一会配置证书路径的时候需要检查一下,保证路径正确!比如,这里显示的是主域名,如图中 pxxxl.com,此时继续粘贴:

注意上面 pxxxl.com 替换成你的域名。此时会显示创建了 4 个证书。分别是:

最后两个是我们要用的,需要写到虚拟主机配置文件 conf 里面。

三、修改网站配置文件

用 XFTP 进入 /usr/local/nginx/conf/vhost/ 下的 你的网站的配置文件,通常是 www.xyz.com.conf 文件。下载下来,用 notepad++ 或 Sublime Text 之类的专业的编辑器打开编辑

注意:别用电脑系统自带的记事本,那个只是处理文字用的,会把代码编码弄乱。你可以百度搜索:notepad++,在百度的下载那里选择普通下载,然后下载安装。

CTRL+A 全选中所有代码,删除。然后复制下面我已经配置好的代码,粘贴进入。

注意检查一下,把上面所有的 xyz.com 换成你的网站主域名。然后保存。

注意:为了让过程简单一些,我们这先别急着上传覆盖源文件。先别重启 nginx。这一步我们先配置好文件,但先不上传重启 nginx。

 

四、把 WordPress 数据库中 HTTP 替换成 HTTPS

登录 WordPress 后台,然后点击插件,安装插件,搜索:Velvet Blues Update URLs  插件,启用。

启用之后,按照图中设置,

replace

点击 Update 按钮。之后在上方会显示进行了哪些替换处理的结果:

replace2

然后,检查一下:

设置(Setting)-常规(General) 那里,WordPress地址 和 网站地址(Site URL) 是不是都改成 https 了。如:https://www.xyz.com

如果还是 http,请手动修改一下。修改之后,系统会立即把你登出后台。

五、上传网站配置文件,重启 nginx

上传第三步我们保存的 www.xyz.com.conf 覆盖掉原文件,

接着 Xshell 执行:service nginx restart

OK,此时 访问你的网站,会自动跳转到 https。

OK,此时再访问首页,已经是绿色小锁加持了!

finished

 

finished-1

 

finishedp-2

 

finished-3

六、我都做了,为什么看不到小绿锁?

可能有些人完成第五步后,发现 chrome 浏览器 https 左边并没有出现绿色的小锁啊?

说说两种情况:

如果你是新装 WordPress,这一步必显示绿色小锁。

如果你是网站搬家,把之前的网站搬过来的,那么可能会不显示小锁。如果你每一步都做好了,但是还是不显示小绿锁,那么只能说,你的数据库中调用的资源虽然都是 https 的,但是页面存在仍用 http 调用的资源。最常见的可能是:

某个主题的 banner图片,你在 主题设置 里面填写的某个资源(多数是图片) 的URL 地址是死的,并不会被存入数据库,所以用插件替换不掉。比如:http:www.xyz.com/wp-content/upload/2016/xx/xxxx.jpg

类似这样在主题设置里写死的 URL 里的 http,插件是没有办法替换到的。所以你要自己去检查是否有调用 https:// 的资源。把这些改成 https:// 就会正常出现小绿锁了。

怎么检查呢?

用浏览器的 F12(科学点的浏览器,如 chrome, firefox … 搜狗高速模式也OK,360我不用所以不知道,IE是铁定不行)。

按 F12 后弹出的工具界面 tab 里选择 network,会列出加载的网络资源。注意这时候是空的,因为页面已经加载完毕了。

resource-examination

你需要再按一下 F5刷新页面,这个时候会出现加载的资源列表。把鼠标移动到这些资源的 URL 那里会自动显示出资源 URL 地址。一个个检查哪个是 http 的,然后想办法改掉就OK了!

七、关于免费的 Let’s Encrypt SSL 证书的说明

免费的 L et’s Encrypt SSL certificates 的有效期一般是 90天,90天之后可以再续期。也不麻烦,执行命令行即可。

八、可以让证书到期自动续期吗?

可以!利用 cron 可以让证书到期自动续期。

关于自动续期,建议看看这篇文章:Cron自动续期命令失效导致网站SSL证书到期的解决方案

九、测试 SSL 是否完全OK

感谢 @tudou 提供的测试网址:

https://www.ssllabs.com/ssltest/

测试结果:A+  完美~!

get-score

十、为什么我的测试结果是 A,不是 A+?

没关系,A已经够了!写这篇文章之前,我配置 SSL 的 nginx 规则代码(本文第三部分)里是含有 HSTS (HTTP Strict Transport Security) 协议的。至于什么是 HSTS 协议,你可以自行百度。

如果你的 SSL 规则里添加了 HSTS协议,那么它起到的主要作用是 强制用户的浏览器只能用 https 来访问你的网站。所以得分一定高:A+。上面截图也是基于之前的 https 配置。

但是,根据我数次试验,HSTS 是个双刃剑,一旦你启用了,想取消特别特别麻烦。所以我后来在文章中把那个代码注释掉了。大家可以无视,其实得分 A 也够了!

如果你特别在意得分,觉得网站也一直会使用https下去,那么就在第三部份的网站配置代码中 443 Server 段内,找到以下这两行代码:

HSTS 要求 max-age 最少为6个月,即 15768000,最好为12个月。

把上面第 2 行里的 add_header 前面的 # 号去掉,保存覆盖重启 nginx 即可启用 HSTS。再测试得分,就是A+。

但,我还是建议不要单纯为了锦上添花的分数给自己麻烦。一旦加了 HSTS 之后,想取消很麻烦。以后你如果想临时停用 https,网站是无法访问的。因为你网站临时恢复成 http,但 HSTS 强制了所有访问者的浏览器在 12 个月内只能用 https 来访问,于是就会访问出错。因此,建议如果以后需要,再加上这条。

关于 HSTS 的用法其实还有更细节的内容,比如,如果对子域名也同样执行 HSTS,则规则为:

还有是否创建 preload list 等等……

这里不想介绍那么多,因为并不建议设置 HSTS,所以这里就不再多说了,有需要请自行百度。

十一、有两个网站,怎么给第二个网站配置 https?

进入证书目录

粘贴一下命令,回车执行:

此时,会提示你端口443已经占用,无法安装证书。

由于我们第一个网站的 https 已经占用了443 端口,所以我们要先把 443 端口进程关闭。一般是因为当前网站 nginx 占用了 80 和 443 两个端口。所以我们先执行:

如果停止成功,则重新粘贴上面那条 sudo 命令来安装证书

如果出现如下的问题,如截图所示:

那么就要从进程里把 nginx 强制关闭。执行命令查看 nginx 的 PID:

ps aux |grep nginx

可以看到类似于如下截图中的进程信息:

比如:图中有三个 PID:28576 28579 29928  (不一定是这3个进程号,你要自己看)

于是执行命令:kill -9 28576 28579 29928  (格式为 kill -9 进程号1 进程号2 进程号3,进程号之间有空格)

然后再执行命令:service nginx stop,停止 nginx 之后,接着粘贴上面那条 sudo 的命令,即可正常给第二个网站安装证书。

安装完证书,完成之后,记得重启 nginx!

安装好证书后,再从第三步开始配置网站 conf 文件。三、四、五、八。


本文完!

675d5d27jw1f3bnbao1dbj20z80jujyu

游戏 |《奥利与黑暗森林》

07 | 07 | 2017

希望是光芒,爱把它点亮。

奥利与黑暗森林》是博主今年在steam夏促上买的一款游戏,游戏发行时间是2015年,steam原价¥68,半价折扣。

QQ20170707-160700

目前博主已经通关了,耗时12小时17分24秒,死亡523次 ((٩(//̀Д/́/)۶)),steam排名13万,没有什么值得骄傲😂

QQ截图20170707153735

剧情概要

故事发生在一片叫做Nibel的森林,森林中有个守护神,“灵魂树”。灵魂树孕育了很多精灵。

9daf5144f0689d96d27ac7f46bec9da5

一天夜里,暴风雨吹走了灵魂树的孩子Ori,Ori被一只黑暗生物Naru认养(博主刚开始以为这货是公的,看体型不像是母的啊喂),快乐地生活。

9daf5144f0689d96d27ac7f46bec9da5副本9daf5144f0689d96d27ac7f46bec9da5副本19daf5144f0689d96d27ac7f46bec9da5副本2

灵魂树派其他孩子寻找Ori,但是损兵折将,不得已之下放了个大招,黑夜中照亮天空,召唤Ori。Ori看到了光,但不明白是什么意思。

9daf5144f0689d96d27ac7f46bec9da5副本3

从那以后,森林渐渐枯萎,Naru找寻食物受伤,当Ori抱着食物回到Naru身边发现她再也醒不过来。(这里被虐的不要不要的,老夫的少女心啊)

9daf5144f0689d96d27ac7f46bec9da5副本49daf5144f0689d96d27ac7f46bec9da5副本6

 

孤单的Ori独自踏上流浪的道路,当希望失去方向,世界以沉寂回应哭泣,生命之火渐渐消散;疲惫的Ori终于忍受不住沉沉是睡去,精灵树用最后的法力复活了Ori,新的故事就这样开始了。

接下来游戏正式开始,Ori为了使森林恢复原貌踏上了寻找真相的路,后面就不剧透了,游民星空上有免安装版的链接(咳咳,请大家支持正版),B站也有这个游戏的视频攻略,大家如果感兴趣可以切身感受下这个游戏。

附上游戏的原声音乐辑,同学们自己感受下吧

5532f9_5792712

2017-Steam夏季促销

05 | 07 | 2017

steam的夏季促销结束了,亲们你们的钱包还好么。反正up主的状态是这样的

df1bef58ly1fgv88x6q2og205004rkct

好心塞有木有,明明知道是个坑还是往面跳

93e30d0828381f301fc0bf14ae014c086c06f0fa

好吧,其实我也是今年刚玩steam,还算是个新手玩家呢,总共才31款游戏(大多是今年夏促买的)

QQ截图20170705221602

感兴趣的小伙伴们要不加个好友先

前端组件化开发方案及其在React Native中的运用

02 | 07 | 2017

随着SPA,前后端分离的技术架构在业界越来越流行,前端(注:本文中的前端泛指所有的用户可接触的界面,包括桌面,移动端)需要管理的内容,承担的职责也越来越多。再加上移动互联网的火爆,及其带动的Mobile First风潮,各大公司也开始在前端投入更多的资源。这一切,使得业界对前端开发方案的思考上多了很多,以React框架为代表推动的组件化开发方案就是目前业界比较认可的方案,本文将和大家一起探讨一下组件化开发方案能给我们带来什么,以及如何在React Native项目的运用组件化开发方案

一、为什么要采用组件化开发方案?

在讲怎么做之前,需要先看看为什么前端要采用组件化开发方案,作为一名程序员和咨询师,我清楚地知道凡是抛开问题谈方案都是耍流氓。那么在面对随着业务规模的增加,更多的业务功能推向前端,以及随之而来的开发团队扩张时,前端开发会遇到些什么样的问题呢?

1. 前端开发面临的问题

(1)资源冗余:页面变得越来越多,页面的交互变得越来越复杂。在这种情况下,有些团队成员会根据功能写自己的CSS、JS,这会产生大量的新的CSS或JS文件,而这些文件中可能出现大量的重复逻辑;有些团队成员则会重用别人的逻辑,但是由于逻辑拆分的粒度差异,可能会为了依赖某个JS中的一个函数,需要加载整个模块,或者为了使用某个CSS中的部分样式依赖整个CSS文件,这导致了大量的资源冗余。

(2)依赖关系不直观:当修改一个JS函数,或者某个CSS属性时,很多时候只能靠人力全局搜索来判断影响范围,这种做法不但慢,而且很容易出错。

(3)项目的灵活性和可维护性差:因为项目中的交叉依赖太多,当出现技术方案变化时,无法做到渐进式的、有节奏地替换掉老的代码,只能一次性替换掉所有老代码,这极大地提升了技术方案升级的成本和风险。

(4)新人进组上手难度大:新人进入项目后,需要了解整个项目的背景、技术栈等,才能或者说才敢开始工作。这在小项目中也许不是问题,但是在大型项目中,尤其是人员流动比较频繁的项目,则会对项目进度产生非常大的影响。

(5)团队协同度不高:用户流程上页面间的依赖(比方说一个页面强依赖前一个页面的工作结果),以及技术方案上的一些相互依赖(比方说某个文件只能由某个团队修改)会导致无法发挥一个团队的全部效能,部分成员会出现等待空窗期,浪费团队效率。

(6) 测试难度大:整个项目中的逻辑拆分不清晰,过多且杂乱的相互依赖都显著拉升了自动化测试的难度。

(7) 沟通反馈慢:业务的要求,UX的设计都需要等到开发人员写完代码,整个项目编译部署后才能看到实际的效果,这个反馈周期太长,并且未来的任何一个小修改又需要重复这一整个流程。

2.组件化开发带来的好处

组件化开发的核心是“业务的归业务,组件的归组件”。即组件是一个个独立存在的模块,它需要具备如下的特征:

  • 职责单一而清晰:开发人员可以很容易了解该组件提供的能力。
  • 资源高内聚: 组件资源内部高内聚,组件资源完全由自身加载控制。
  • 作用域独立: 内部结构密封,不与全局或其他组件产生影响。
  • 接口规范化: 组件接口有统一规范。
  • 可相互组合: 组装整合成复杂组件,高阶组件等。
  • 独立清晰的生命周期管理:组件的加载、渲染、更新必须有清晰的、可控的路径。

而业务就是通过组合这一堆组件完成User Journey。下一节中,会详细描述采用组件化开发方案的团队是如何运作的。

在项目中分清楚组件和业务的关系,把系统的构建架构在组件化思想上可以:

(1) 降低整个系统的耦合度:在保持接口不变的情况下,我们可以把当前组件替换成不同的组件实现业务功能升级,比如把一个搜索框,换成一个日历组件。

(2) 提高可维护性:由于每个组件的职责单一,在系统中更容易被复用,所以对某个职责的修改只需要修改一处,就可获得系统的整体升级。独立的,小的组件代码的更易理解,维护起来也更容易。

(3) 降低上手难度:新成员只需要理解接口和职责即可开发组件代码,在不断的开发过程中再进一步理解和学习项目知识。另外,由于代码的影响范围仅限于组件内部,对项目的风险控制也非常有帮助,不会因为一次修改导致雪崩效应,影响整个团队的工作。

(4) 提升团队协同开发效率:通过对组件的拆分粒度控制来合理分配团队成员任务,让团队中每个人都能发挥所长,维护对应的组件,最大化团队开发效率。

(5) 便于自动化测试:由于组件除了接口外,完全是自治王国,甚至概念上,可以把组件当成一个函数,输入对应着输出,这让自动化测试变得简单。

(6) 更容易的自文档化:在组件之上,可以采用Living Style Guide的方式为项目的所有UI组件建立一个‘活’的文档,这个文档还可以成为业务,开发,UX之间的沟通桥梁。这是对‘代码即文档’的另一种诠释,巧妙的解决了程序员不爱写文档的问题。

(7) 方便调试:由于整个系统是通过组件组合起来的,在出现问题的时候,可以用排除法直接移除组件,或者根据报错的组件快速定位问题。另外,Living Style Guide除了作为沟通工具,还可以作为调试工具,帮助开发者调试UI组件。

二、组件化开发方案下,团队如何运作?

前面大致讲了下组件化开发可以给项目带来的好处,接下来聊一聊采用组件化开发方案的团队是应该如何运作?

在ThoughtWorks,我们把一个项目的生命周期分为如下几个阶段:

组件化开发方案主要关注的是在迭代开发阶段的对团队效率的提升。 它主要从以下几个方面提升了开发效率:

1. 以架构层的组件复用降低工作量

在大型应用的后端开发中,为了分工、复用和可维护性,在架构层面将应用抽象为多个相对独立的模块的思想和方法都已经非常成熟和深入人心了。但是在前端开发中,模块化的思想还是比较传统,开发者还是只有在需考虑复用时才会将某一部分做成组件,再加上当开发人员专注在不同界面开发上时,对于该界面上哪些部分可以重用缺乏关注,导致在多个界面上重复开发相同的UI功能,这不仅拉升了整个项目的工作量,还增加了项目后续的修改和维护成本。

在组件化开发方案下,团队在交付开始阶段就需要从架构层面对应用的UI进行模块化,团队会一起把需求分析阶段产生的原型中的每一个UI页面抽象为一颗组件树,UI页面自己本身上也是一个组件。如下图:

通过上面的抽象之后,我们会发现大量的组件可以在多个UI界面上复用,而考虑到在前端项目中,构建各个UI界面占了80%以上的工作量,这样的抽象显著降低了项目的工作量,同时对后续的修改和维护也会大有裨益。

在这样的架构模式下,团队的运作方式就需要相应的发生改变:

(1) 工程化方面的支持,从目录结构的划分上对开发人员进行组件化思维的强调,区分基础组件,业务组件,页面组件的位置,职责,以及相互之间的依赖关系。

(2) 工作优先级的安排,在敏捷团队中,我们强调的是交付业务价值。而业务是由页面组件串联而成,在组件化的架构模式下,必然是先完成组件开发,再串联业务。所以在做迭代计划时,需要对团队开发组件的任务和串联业务的任务做一个清晰的优先级安排,以保证团队对业务价值的交付节奏。

2.以组件的规范性保障项目设计的统一性

在前端开发中,因为CSS的灵活性,对于相同的UI要求(比如:布局上的靠右边框5个像素),就可能有上十种的CSS写法,开发人员的背景,经历的不同,很可能会选择不同的实现方法;甚至还有一些不成熟的项目,存在需求方直接给一个PDF文件的用户流程图界面,不给PSD的情况,所有的设计元素需要开发人员从图片中抓取,这更是会使得项目的样式写的五花八门。因为同样的UI设计在项目中存在多种写法,会导致很多问题,第一就是设计上可能存在不一致的情况;第二是UI设计发生修改时,出现需要多种修改方案的成本,甚至出现漏改某个样式导致bug的问题。

在组件化开发方案下,项目设计的统一性被上拉到组件层,由组件的统一性来保障。其实本来所有的业务UI设计就是组件为单位的,设计师不会说我要“黄色”,他们说得是我要“黄色的按钮……”。是开发者在实现过程中把UI设计下放到CSS样式上的,相比一个个,一组组的CSS属性,组件的整体性和可理解性都会更高。再加上组件的资源高内聚特性,在组件上对样式进行调整也会变得容易,其影响范围也更可控。

在组件化开发方案下,为了保证UI设计的一致性,团队的运作需要:

  1. 定义基础设计元素,包括色号、字体、字号等,由UX决定所有的基础设计元素。
  2. 所有具体的UI组件设计必须通过这些基础设计元素组合而成,如果当前的基础设计元素不能满足需求,则需要和UX一起讨论增加基础设计元素。
  3. UI组件的验收需要UX参与。

3. 以组件的独立性和自治性提升团队协同效率

在前端开发时,存在一个典型的场景就是某个功能界面,距离启动界面有多个层级,按照传统开发方式,需要按照页面一页一页的开发,当前一个页面开发未完成时,无法开始下一个页面的开发,导致团队工作的并发度不够。另外,在团队中,开发人员的能力各有所长,而页面依赖降低了整个项目在任务安排上的灵活性,让我们无法按照团队成员的经验,强项来合理安排工作。这两项对团队协同度的影响最终会拉低团队的整体效率。

在组件化开发方案下,强调业务任务和组件任务的分离和协同。组件任务具有很强的独立性和自治性,即在接口定义清楚的情况下,完全可以抛开上下文进行开发。这类任务对外无任何依赖,再加上组件的职责单一性,其功能也很容易被开发者理解。所以在安排任务上,组件任务可以非常灵活。而业务任务只需关注自己依赖的组件是否已经完成,一旦完成就马上进入Ready For Dev状态,以最高优先级等待下一位开发人员选取。

在组件化开发方案下,为了提升团队协同效率,团队的运作需要:

(1)把业务任务和组件任务拆开,组件的归组件,业务的归业务。

(2)使用Jira,Mingle等团队管理工具管理好业务任务对组件任务的依赖,让团队可以容易地了解到每个业务价值的实现需要的完成的任务。

(3) Tech Lead需要加深对团队每个成员的了解,清楚的知道他们各自的强项,作为安排任务时的参考。

(4) 业务优先原则,一旦业务任务依赖的所有组件任务完成,业务任务马上进入最高优先级,团队以交付业务价值为最高优先级。

(5)组件任务先于业务任务完成,未纳入业务流程前,团队需要Living Style Guide之类的工具帮助验收组件任务。

4.以组件的Living Style Guide平台降低团队沟通成本

在前端开发时,经常存在这样的沟通场景:

  • 开发人员和UX验证页面设计时,因为一些细微的差异对UI进行反复的小修改。
  • 开发人员和业务人员验证界面流程时,因为一些特别的需求对UI进行反复的小修改。
  • 开发人员想复用另一个组件,寻找该组件的开发人员了解该组件的设计和职责
  • 开发人员和QA一起验证某个公用组件改动对多个界面上的影响

当这样的沟通出现在上一小节的提到的场景,即组件出现在距离启动界面有多个层级的界面时,按照传统开发方式,UX和开发需要多次点击,有时甚至需要输入一些数据,最后才能到达想要的功能界面。没有或者无法搭建一个直观的平台满足这些需求,就会导致每一次的沟通改动就伴随着一次重复走的,很长的路径。使得团队的沟通成本激增,极大的降低了开发效率。

在组件化开发方案下, 因为组件的独立性,构建Living Style Guide平台变得非常简单,目前社区已经有了很多工具支持构建Living Style Guide平台(比如getstorybook:https://getstorybook.io),开发人员把组件以Demo的形式添加到Living Style Guide平台就行了,然后所有与UI组件的相关的沟通都以该平台为中心进行,因为开发对组件的修改会马上体现在平台上,再加上平台对组件的组织形式让所有人都可以很直接的访问到任何需要的组件,这样,UX和业务人员有任何要求,开发人员都可以快速修改,共同在平台上验证,这种“所见即所得”的沟通方式节省去了大量的沟通成本。此外,该平台自带组件文档功能,团队成员可以从该平台上看到所有组件的UI,接口,降低了人员变动导致的组件上下文知识缺失,同时也降低了开发者之间对于组件的沟通需求。

想要获得这些好处,团队的运作需要:

(1) 项目初期就搭建好Living Style Guide平台。

(2) 开发人员在完成组件之后必须添加Demo到平台,甚至根据该组件需要适应的场景,多添加几个Demo。这样一眼就可以看出不同场景下,该组件的样子。

(3) UX,业务人员通过平台验收组件,甚至可以在平台通过修改组件Props,探索性的测试在一些极端场景下组件的反应。

5. 对需求分析阶段的诉求和产品演进阶段的帮助

虽然需求分析阶段产品演进阶段不是组件化开发关注的重点,但是组件化开发的实施效果却和这两个阶段有关系,组件化方案需要需求分析阶段能够给出清晰的Domain数据结构,基础设计元素和界面原型,它们是组件化开发的基础。而对于产品演进阶段,组件化开发提供的两个重要特性则大大降低了产品演进的风险:

  • 低耦合的架构,让开发者清楚的知道自己的修改影响范围,降低演进风险。开发团队只需要根据新需求完成新的组件,或者替换掉已有组件就可以完成产品演进。
  • Living Style Guide的自文档能力,让你能够很容易的获得现有组件代码的信息,降低人员流动产生的上下文缺失对产品演进的风险。

三、组件化开发方案在React Native项目中的实施

前面已经详细讨论了为什么和如何做组件化开发方案,接下来,就以一个React Native项目为例,从代码级别看看组件化方案的实施。

1. 定义基础设计元素

在前面我们已经提到过,需求分析阶段需要产出基本的设计元素,在前端开发人员开始写代码之前需要把这部分基础设计元素添加到代码中。在React Native中,所有的CSS属性都被封装到了JS代码中,所以在React Native项目开发中,不再需要LESS,SCSS之类的动态样式语言,而且你可以使用JS语言的一切特性来帮助你组合样式,所以我们可以创建一个theme.js存放所有的基础设计元素,如果基础设计元素很多,也可以拆分位多个文件存放。

然后,在写具体UI组件的styles,只需要引入该文件,按照JS的规则复用这些样式属性即可。

2.拆分组件树之Component,Page,Scene

在实现业务流程前,需要对项目的原型UI进行分解和分类,在React Native项目中,我把UI组件分为了四种类型:

  • Shared Component: 基础组件,Button,Label之类的大部分其它组件都会用到的基础组件
  • Feature Component: 业务组件,对应到某个业务流程的子组件,但其不对应路由, 他们通过各种组合形成了Pag组件。
  • Page: 与路由对应的Container组件,主要功能就是组合子组件,所有Page组件最好名字都以Page结尾,便于区分。
  • Scene: 应用状态和UI之间的连接器,严格意义上它不算UI组件,主要作用就是把应用的状态和Page组件绑定上,所有的Scene组件以Scene后缀结尾。

Component和Page组件都是Pure Component,只接收props,然后展示UI,响应事件。Component的Props由Page组件传递给它,Page组件的Props则是由Scene组件绑定过去。下面我们就以如下的这个页面为例来看看这几类组件各自的职责范围:

(1)searchResultRowItem.js

(2)SearchResultsPage.js

(3)SearchResultsScene.js

3.Living Style Guide

目前社区上,最好的支持React Native的Living Style Guide工具是getstorybook,关于如何使用getstorybook搭建React Native的Living Style Guide平台可以参见官方文档(https://github.com/kadirahq/react-native-storybook)或者我的博客(http://www.jianshu.com/p/36cbd8393288)。

搭建好Living Style Guide平台后,就可以看到如下的界面:

接下来的工作就是不断在往该平台添加UI组件的Demo。向storybook中添加Demo非常简单,下面就是一个关于SearchPage的Demo:

从上面的代码可以看出,只需要简单的三步就可以完成一个UI组件的Demo:

(1)import要做Demo的UI组件。

(2) storiesOf定义了一个组件目录。

(3) add添加Demo。

在构建项目的storybook时,一些可以帮助我们更有效的开发Demo小Tips:

(1)尽可能的把目录结构与源代码结构保持一致。

(2) 一个UI组件对应一个Demo文件,保持Demo代码的独立性和灵活性,可以为一个组件添加多个Demo,这样一眼就可以看到多个场景下的Demo状态。

(3) Demo命名以UI组件名加上Demo缀。

(4) 在组件参数复杂的场景下,可以单独提供一个fakeData的目录用于存放重用的UI组件Props数据。

4.一个完整的业务开发流程

在完成了上面三个步骤后,一个完整的React Native业务开发流程可简单分为如下几步:

(1)使用基础设计元素构建基础组件,通过Living Style Guide验收。

(2)使用基础组件组合业务组件,通过Living Style Guide验收。

(3)使用业务组件组合Page组件,通过Living Style Guide验收。

(4)使用Scene把Page组件的和应用的状态关联起来。

(5)使用Router把多个Scene串联起来,完成业务流程。

四、总结

随着前后端分离架构成为主流,越来越多的业务逻辑被推向前端,再加上用户对于体验的更高要求,前端的复杂性在一步一步的拔高。对前端复杂性的管理就显得越来越重要了。经过前端的各种框架,工具的推动,在前端工程化实践方面我们已经迈进了很多。而组件化开发就是笔者觉得其中比较好的一个方向,因为它不仅关注了当前的项目交付,还指导了团队的运作,帮助了后期的演进,甚至在程序员最讨厌的写文档的方面也给出了一个巧妙的解法。希望对该方法感兴趣的同学一起研究,改进。

转自:前端之巅

下一页