TFC 2017 随记

2017-06-29

开篇闲扯

距离上次发博文不知道已经过去多久了,自从上次被虐的体无完肤后,就下定决定再给自己一年的时间,做一个更好的自己,或许这段时间不会发技术的文章吧,但是会随意发发这种扯扯淡的东西,是我的博客,其实想要用来发什么就发什么,随心所欲~其实距离上一次参加一些前端的大会已经好些日子了,这次凑巧也去参加了TFC,说实话,相当可以啊~

随便说说

我就挑了几个觉得不错的,不够貌似好像都是在开场的,但也许有些东西就是我想要的吧,或者是我所欠缺的,接下来的内容,我可能会重新看过录像,因为毕竟不是每一场都有听,有我喜欢的点,我会继续分享。

问题到此为止(黄希彤)

因为是开场致辞,时间比较早,还没进入状态的情况下听的第一场吧,太多东西没有记住,只记住了这句“问题到此为止”。之后又去查了一下资料,这是美国前总统杜鲁门写在自己办公室门上的一句话,原文是“Bucket stop here!”,具体的来源就不赘述了,有兴趣的同学可以自行进行百度就好。
谈一谈自己的感想吧,虽然说是一场技术会,但是能够有这样的开场白也是极好的,在如今如此浮躁的世界,有多少人愿意静下来心来,每天都像流水线上的工人,都在不断的忙碌,遇到了许许多多的问题,也许先想到的不是引发这个问题的原因是什么,而是先去看这个问题是不是来自我这边的,如果不是,就开始推卸,是的话,也只好各种难为情的处理,或者说当遇到一件事件,发现要牵扯到其它的事情,或者遇到帮别人牵头的一些事情,出现了麻烦,也会开始各种推脱。
如果“问题到此为止”,或许会节省更多不必要的时间,不管是自己的时间,或者是他人的时间。自己尽力完成每一件事情,或者尽心尽责的帮助别人完成一些事情,也是极好的,我一直相信,我如何对待别人,别人也会如何对待我。
“问题到此为止”看似简单,却是又很难办到的。因为当我们处于一种被动的情况下,往往的第一反应就是多一事不如少一事。如果对于我们的技术人员来说,也许就会少了不少的技术债。
或许这样的解读比较浅,但是想要做到还是要不断的改掉自己的习惯,也许我们贴一张“问题到此为止”的便利贴在我们的显示器上呢?

编写未来JS(Nicolás Bevacqua)

业界大牛,虽然在演讲的时候没怎么听懂,看了一下交流群,原来大家也都一样,可能是口音的问题吧,不过贴心的主办方给我们准备了一份讲义。嘉宾给我们普及了一下TC39 process,stage 0 ~ stage 4。之前在用babel的时候有看到过配置项,但是没有留意过,这次算涨了姿势,让我领悟到,不要忽略每一个配置项,或许后面就蕴藏各种知识。对于流程的解释其实可以看看http://www.jianshu.com/p/b0877d1fc2a4,还是蛮讲究的,当我们在babel中进行配置的时候一般都是选择“stage 0”,可以用的里面的所有提案,但是也要小心坑多。
其中有几个点是我比较感兴趣的:

正则命名捕获

恩。。。这个暂时没找到资料,也是我觉得蛮方便的一个新方法,可以进行命名分组,有点像匹配到的对象就会生成一个对象,通过之前定义的key进行取值,十分的方便。

prettier

代码美化工具,可以很好的用来规范代码风格,也可进行自定义的配置,我用的是vs code,整体美化效果还不错,这种东西其实用一下也是蛮好的,在多人协作的情况下,还是需要一定的制约,这样才便于后期的维护。

工具

在讲义中有提到说webpack的出现取代了gulp和require.js,取代gulp这点我不是很赞同,我个人认为在做静态页的编写,以及类库的编写时,gulp的作用还是蛮大的,用流的形式进行管理,还是很好的,我也不需要借助webpack那么多的功能,其实感觉两者的配置程度来说也是差不多的,都需要不断的踩坑才能找到一个适合的。在我目前的开发习惯来看,对于类库的编写、静态页的编写,我个人倾向于使用gulp,类库的编写现在又入了rollup的坑了,还在坑里。。。站点的开发还是会使用webpack。
当然也有提到了rollup、npm、babel等,工具这种东西,当然就要挑一个自己顺手的。

工程化(张云龙)

民工叔的这次分享真的是满满的干货,也是我最想要获得的实践经验,听的可真够爽的,真的是一次实践经验的总结啊,感觉有点毫无保留的向我们大家分享。

组件化

组件化应该是现在前端最流行的一种做法吧,各种各样的组件,UI组件,业务组件等。合理的拆分会对后期的迭代或者维护带来极大的便利,将各个部分按照组件化进行拆分和开发,互补受影响,列如头部、底部、tab切换等。
其实这样的做法在我现在的项目中,或者自己之前的side-project来说已经是按照这样的做法了,这样确实会产生极大的遍历,不过我的拆分方式是按照文件类型进行的,例如将HTML放在一个文件夹下,下面再进行命名,CSS和JavaScript也是相同的。发现这样后期的查找不是十分的方便,看来还是按照一个组件一个文件夹进行归类会简单点,同时也可以为下面的生成依赖树进行便捷的管理。
感觉在规划一个项目的时候,在前期还是要做好预演,考虑到尽可能多的情况,不然会很容易出现让自己想要重构代码的冲动,不要问我为什么,我因为一个静态页的编写,我就换了好几种的目录结构。
或许这也需要一个长时间的经验积累,踩的坑多了,自然就懂了。

依赖生成数据结构、工具解析依赖树

根据之前定义好的一些结构,根据目录生成相对应的数据结构,比如以组件的名称来作为key,相关的资源路径作为value,再通过工具进行解析这些组件,最后再引入到页面中,当然这个工具需要自己纯手工打造或者自行寻找开源项目,接下来我也要做这方面的尝试。

子系统拆分

子系统拆分的概念之前确实没有想到过,感觉也是蛮巧妙的,在划分的维度上又多了一种,比方说,在一个大型项目中,可能会有很多个页面,这时把各个页面看成一个子系统,单独开发这些子系统,与其它页面无关,这时各个子系统创建的也是新的一个分支,但最后进行测试或者一起联调时再合并到一个主分支上。这样不管是人员划分也好,维护也好,都有了极大的便利,决定将正在进行的side-project也用上这种方式。

持续集成/交付/部署 - gitlab CI

这一块也没自己搭建过,听了民工叔的介绍后,才发现gitlab不止是用于代码托管,还有一个gitlab CI这样一个强大的功能存在,看来要把玩一下,这里就不展开了,说实话也是不了解,实践后再总结。

前端自动化测试 - dom-diff、Dolphin log-diff

UI测试确实是一个比较麻烦的点,在测试方面我也没啥经验,不过觉得要想项目质量有保障和稳定,还是要将测试引入,尤其是UI测试,谁知道在未来的某一天会有哪个页面因为手抖一下花掉了呢,这也想在实践之后再做分享。

看板 - 可视化进度

恩,简单的来说,实物看板比电子看板更有仪式感。

Others

“TOOLS” 工具化思考框架 - 消灭假充实

发现低效:Think 思考高频低效环节
工具本质:Over and over again 复用性
Operability 实用性
工具价值:Leveraging 借力
Strengthen 赋能

结语

未完待续…

下面是我的微信

欢迎骚扰

ww1o01