2017 随记 【随心所语】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 赋能
开通2年，未推送一篇文章，现开启全新旅程
或许更新的时间不频繁
但每一次的推送都能带给你真心实意
轻轻长按加关注
有你想要的
问题到此为止（黄希彤）
因为是开场致辞，时间比较早，还没进入状态的情况下听的第一场吧，太多东西没有记住，只记住了这句“问题到此为止”。之后又去查了一下资料，这是美国前总统杜鲁门写在自己办公室门上的一句话，原文是“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 赋能
开通2年，未推送一篇文章，现开启全新旅程
或许更新的时间不频繁
但每一次的推送都能带给你真心实意
轻轻长按加关注
有你想要的