又到了一段实习经历暂告结束的时候啦~ 时间说快吧，这两个多月的时间里也遇到了几多困难和挑战，在其中也挣扎许久。时间说慢吧，现在也已经快要离职并开始秋招这个最后的难关了。姑且就以此篇 Blog 作为我在腾讯从 2020.06.10 实习以来的一个小结吧。
腾讯的这段实习和我之前在字节的实习大不一样。因为在字节我所处的飞书商业化团队里，前端和后端界限分得很清楚，前端几乎只做纯前端的工作，服务器数据库等都是由部门里对应的后台同学负责的。而我在腾讯的这个部门（PCG/腾讯看点/内容平台中心/综合开发组）由于做的是中台，所以前端也要负责相当一部分的服务器和数据库等东西，平时接的每个业务需求，也基本都是前后端都得自己写。名副其实，真就是综合开发组了。
由于业务的关系，我也接触并实践到了许多后台的知识点，比如 Node、MySQL、Hbase、ES、Ckv、服务器等等。然而我觉得有一个很大的痛点就是，我对这些技术的掌握也就只是到达基本满足平时业务开发的程度，仅此而已。更何况项目代码里面还基本都封装好了对应的操作方法，开箱即用，也不用我怎么额外操作。所以我都不好意思在实习经历中写上在腾讯参与过的项目开发了，这实在是太容易给自己挖坑了呀。连我都可以随便想到几个问题就把自己给问到了，比如详细说一下 Hbase 和 ES？怎么缩短数据库访问耗时？一被问就是不会了 Orz。好吧，之后还是需要抽时间出来专门学一下后台这些知识点，这个软肋可太硬核了。
除了接触到许多后台的知识点外，也还了解了一些前端的技术方案，比如手绘图生成页面代码、自动化测试等。这两个其实是我 leader 为了让我在转正答辩上有拿得出手的产出可以讲而让我调研相关的技术方案后自己“搞”一个出来，只是可惜我后续一直忙于写业务需求，没能抽出足够的时间投入，而且后面决定不参加答辩直接离职参加秋招就更没有去看了。
所谓的手绘图生成页面代码（即 Design To Code，以下就简称为 D2C），指的是通过上传设计稿，就可以自动识别并生成对应的页面代码，从而一步完成页面开发。类似于业界内的前端页面可视化搭建平台，不过 D2C 直接就省去了人工拖拽和配置组件的步骤，极大程度上解放了生产力。对于 D2C，业界内其实还没有像可视化搭建平台那样有许多已经可以用于生产的成品了，也还只是出于探索阶段。其中应该属阿里的 imgcook 较为成熟了，不过很可惜 imgcook 没有开源。此外还有 UI2code、pix2code 等技术方案，不过这两个就各不如人意了。我觉得 D2C 最大的难点还是在于机器学习，如何识别出一张设计稿的内容，只要识别出来后将其表示成类似虚拟 DOM 的数据结构，后续的事就应该问题不大了。
而自动化测试方案，我原本的想法是遵循传统的方案，通过断言库（chai）和单元测试库（Jest）来写测试脚本，此外再借助其他的一些库如 UI 测试 puppeteer、组件测试 enzyme 等实现自动化测试的。但是由于部门里现在页面开发已经转向了由自研的 Dvl 可视化页面搭建平台配置生成页面，所以传统的前端自动化测试方案不适用于我们部门。之后调研方向转向了通过录制页面操作，生成脚本文件以供后续的自动化测试。这一方面主要看了阿里开源的 UI Recorder，不过后续时间紧张就没有再深入研究了。对于前者传统的自动化测试方案，主要参考了：京喜前端自动化测试之路、有赞前端质量保障体系等等。
emmm，这么说起来好像我在腾讯实习的这段时间里，除了写需求外就一事无成了 Orz？成长还是有一点的呐，比如使用 whistle 代理工具代理页面和接口，与此相关的还有 Host 等配置；出问题或 Bug 时能够比较熟练地到服务对应的机器上查日志，以此独立排查和解决问题；对于一些告警，可以根据告警 ID 或接口路径到相应的监控平台去查看日志排查问题；此外还有一些编码意识的提高，比如说写代码时要再多想想可扩展性、可复用性、健壮性。1. 可扩展性。我理解的是在针对一些 feature 进行编码开发时，需要考虑到后期该 feature 可能存在的迭代改进，以便提前在代码里做好兼容，避免后续 feature 迭代时又要大改特改代码。比如我做过的一个需求，要在原来单个单子审核的基础上支持批量审核，如果早期的编码考虑到扩展性的话，审核调用的函数入参时使用数组列表而非单条数据（单个单子审核时传一个长度为 1 的数组即可），这样后续支持批量审核时是不是只需要改一下入参就可以了？否则还得去批量调用原来单个审核的函数，甚至是修改原来的审核函数。2. 可复用性。我理解的是一些大众普用的函数或组件应该抽出来放到特定的代码目录里，以便在其他页面可以很方便地使用到。你能想象一些公用的函数也都被挤在一个组件里，既导致单个文件代码行数过千行，又使得其他组件想复用时只能望而却步只好再 copy 一份一模一样的代码出来的心情吗？当然对于拆分的粒度也不好把握，粒度过大则可复用性不佳，粒度过下则导致过于散乱。还得考虑到的另一个问题是在组件复用时，如何避免各自的影响。比如一个 Table 组件，很多个页面都复用到了它，但是后续需求在做迭代时往往都是只针对特定几个页面的，此时不得不得通过 props 来界定不同的页面，然而时间一长特别还是团队多人合作开发，代码就会愈来愈臃肿且难以理解。这些问题都是需要在编码时先想好的，不然不加以思索就直接编码，很可能写到一半才发现这样写不对得那样才行，于是推到重来。3. 健壮性。我的理解是编码时需要充分考虑到特殊情况，避免因出现语法错误而直接导致页面白屏。我最常遇到的主要还是对于接口返回的数据，实在是不能相信接口返回的数据，可能某个字段没有值时它会返回空也可能直接就不返回该字段了，可能同一个接口它返回的字段名是不一样的需要再获取响应数据时再额外判断…总之，对于接口返回的数据，先去判断一下某个值是否存在再去取它的属性比较保险。
其间也踩过一些坑，比如使用 source 命令往数据库里导入 SQL 文件时，需要在登录数据库时就指定 utf-8 编码（mysql -u localuser -p --default-character-set=utf8）才行，不然导入数据可能会失败，或者导入的数据不全；比如前后台接口联调时可能因为精确度溢出而导致数据不一致，具体参考我的另一篇 Blog 采坑记录-接口联调中的精确度丢失。
此外受我 leader 的教导，也明白了一个工程师应该具有的素养。我理解的是，身为一个工程师，职责说白了就是保证高效高质量的需求交付。而要追求高效高质量，就得打造一些智能平台来逐步代替人工劳动。对于高效，需要思考的是能否通过工具来避免重复的人工开发，不管是前端页面，还是后端接口。我们是不是可以直接通过页面可视化拖拽平台来代理常规的 React + Antd 开发页面，甚至是借助上文提到的 D2C？是不是可以指定数据库信息和需要的字段数据，就能自动实现 CURD 而不用人工每次都去专门写接口？是不是可以通过一些发布构建平台来快速实现 CICD，提高发布的便捷性和可靠性？对于高质量，是不是可以通过自动化测试对页面对接口对数据进行智能测试，提前发现潜在的问题将其扼杀在开发阶段？是不是可以通过监控告警平台来及时发现用户操作时遇到的问题比如页面白屏接口失败等等？是不是可以通过完善监控告警平台使得告警时能自动识别到问题并定位到对应的代码位置？此外还要考虑怎么把这些平台都打通，新项目怎么快速接入实现可插拔等等问题。当然，真实的业务场景可能很复杂，无法做到完全借助平台去完成，但是不是可以想方设法去提高平台的覆盖率，尽可能地实现工程化呢？这些问题，都是我平时没有去思考的，通过这次实习，也渐渐学会去思考怎么避免低效、保证质量，也算做是一个提高吧~
大概就总结这几个点啦，大后天就要离职了，只能说接下来的秋招加油了~ 早日上岸然后就可以开始做我喜欢的事啦，比如开始我 Web 仙剑奇侠传四的开发之旅 hhh~~
