juejin.cn
获得徽章 0
- 昨天在github 上提交PR，提交完后发现还有点东西需要改动，就在本地改了再次push，push 完之后几秒钟，github PR 页面上的commits 就更新了。我以为github 用了轮询接口查询当前PR 的commits 信息，就打开F12 进行观测，结果发现没有轮询。没有轮询的话那就是服务端推送，H2？Socket？再看看协议和WS 的信息，都没有！这就奇怪了，那他是怎么做到的呢？
然后就开始探究工作的机制。先是查了下网页端的IM 通信技术，找到了这篇文章：
juejin.cn。确实存在一种基于HTTP1的服务端推送技术，叫做SSE，SSE 的信息参考MDN：developer.mozilla.org。大概实现思路就是客户端通过一个EventSource 跟服务端连接起来，然后服务端就可以给客户端单向推送消息。
排查了github 运行的源码（确实是源码，github 网站的sourcemap 是线上可用的），没有找到EventSource，但是发现了一个SharedWorker，SharedWorker 是一个用于客户端多窗口通信的东西，走不出客户端，所以肯定是其他东西在跟服务端保持通信。
然后去看了SharedWorker 初始化时请求的js 文件，发现这个文件里有一个AliveSession，而AliveSession 又是基于一个StableSocket 的类实现的，所以最终还是走的socket。但是现在我还是有两个问题没有搞明白：
1、为什么走了socket，但是在network 中观测不到，或许是因为非主线程调用socket？
2、socket-worker-xxx.js 在网络请求中一直处于pending 状态，但是页面能完成load，而且这个远程js 中的脚本能够工作？展开赞过
12 - 晚饭过后习惯在附近的小公园散会步，最近散着步，经常跟同事聊起代码检视这件事情。聊了很多，达成的一致结论就是团队目前对代码检视的整体投入不够。
目前团队里的代码检视主要有两种形式：
（1）群里发MR链接，大家有空的时候异步检视。检视的效果完全看接收到链接的同事愿意付出多少时间
（2）每周固定检视会议，多人线上检视。MR发起人主讲，其他人共同讨论。检视的效果受业务交叉范围和是否提前花时间看过MR影响
要做好代码检视会面临许多困难，大概体现在下述几个方面：
（1）业务交付压力大，代码检视又不能即时看到成果，大家对于检视的行为内心深处是抗拒的
（2）认真地检视本身就要耗费巨大的时间和心力，这个消耗可能是一个常数，比如10行/分钟
（3）代码量很大，尤其是业务交付密集的时候或者团队成员比较多的时候，两三天就提交几百上千行代码是很常见的。以一千行代码为例，按照上面的消耗常数计算，认真检视完1000行代码，可能需要100分钟的时间（但是谁会这么做呢？）
（4）有时候合代码方比较急，来不及检视的话，会催，次数多了，就直接点评分了
综合考虑，要做好代码检视，至少需要具备下述两个条件：
（1）认可代码检视的团队文化，组织上愿意每周为代码检视预留时间。比如，听说thoughtworks 有团队每周周五固定预留用于共同检视代码，只做4天的业务交付
（2）团队或个人能形成好的检视习惯，可以定期有规律的进行异步代码检视，比如每天下午五点到五点的时间就是用于异步代码检视。代码检视的大头一定是在个人花时间去看别人提交的MR，只有自己花时间去看过了，在集中讨论的时候才能参与进去，真正发现问题和改进点展开赞过 23 - 最近在读《Vue.js设计与实现》。在第8章“挂载与更新”中，作者花费了一些篇幅去讲HTML Attributes 和DOM Properties。浏览器在解析普通的HTML 文件时，会自动分析HTML Attributes 并设置合适的DOM Properties，但是Vue.js 中的template 不会被浏览器解析，所以原本需要由浏览器完成的工作，就需要由框架来完成。
紧接着举了很多案例来说明，不同的情况下应该如何将Attributes 合理地转换为Properties。比如说，在disabled 属性为false 时或仅添加属性不设值的时候如何进行正确地转换；比如说对于只读的form 属性只能通过setAttribute 去设置；比如说如何将对象、数组等动态转换为class，以及在设置class 属性时应该选择setAttribute、el.className 和el.classList 中的哪一种方法。
在讨论这些案例的过程中，作者写了下述一段话：我们不会列举所有情况，并一一讲解。因为掌握处理问题的思路更重要，另外我们也不可能把所有需要特殊处理的地方都记住，更何况有时我们根本不知道在什么情况下才需要特殊处理。所以上述解决方案本质上是经验之谈，不要惧怕写不出完美的代码，只要在后续迭代过程中见招拆招，代码就会变得越来越完善，框架也会变得越来越健壮。展开等人赞过 513
