Hungry and Humble∎

「开源」这个词，大家肯定都不陌生了，今天想说一下和它相似的另外一种协同模式：「内部开源」，全称是「公司内部的开源」。

近年来，越来越多的优质人才涌进互联网行业，公司人变多了，极大程度上满足了公司业务发展的需要，但也带来了一些小的负面效应，其中就包括：卷起来了。比如某 A 姓互联网大厂，拿前端举例，今天 X 部门搞了个 UI 组件库，明天发现 Z 部门也搞了一个，组件库的作者拿着这套代码升了职，就再也没维护过。后来越来越多的人开始效仿，公司内的组件库变得越来越多，而这些在组织层面都没什么好处的，除了内卷，就是内耗。

解决这个问题，其实从大方向上看，很简单，那就是大家都去开发、维护同一套组件库，收敛人力，本着开源的精神，这个组件库肯定也会越变越好。

理想很丰满，那现实怎么样呢？下面是我以第一人称视角、结合自己的体验的、看到的、听到的总结出来的一些问题，内容纯属胡掰，如有雷同，可以交个朋友。

开源精神 vs KPI

虽然是「内部开源」，但也是「开源」，就不得不扯到开源精神。虽然我活跃在 Github 上已经有快 5 年的时间了，也有过接近 100 star 的个人项目，但我还是无法准确地对「开源精神」下定义，不过倒是能提供一些关键词：不逐利、自由、开放、平等、极客… 其实每个词都包含了很多层理解。从这些关键词就能看到：开源和“打工人来上班赚钱”这件事情从骨子里就有一些冲突。打工人在工位上花时间写开源代码的时候，肯定都会不自觉地问自己：这事能让我升职加薪吗？

能力不合格的人选

如果迫于某些问题，内部开源变得很紧迫（看似很紧迫？），项目的参与人选会通过一些筛选到岗，不过筛选条件不是“谁愿意”和“谁能行”，而是“谁有空”。这是个比较糟糕的事情。对比一下团队招人，候选人通常会面临一轮又一轮的技术测评和综合素质测评，通常由直属 leader、部门 leader 和 HR 共同把关，只有通过了这些测评，才意味着候选人有能力和现有团队一起共事。而内部开源，尤其是被迫开始的内部开源，那些“有空”的不合格人选得到了和现有团队一起共事的机会，这无疑是对现有团队技术规范和协作模式的一种挑战（or 破坏）。

跨团队技术管理困难

公司内部的项目往往都是业务驱动的，而在业务型产品中做技术管理，是件不容易的事情。当问题又加上了「跨团队」的 buff，情况可能会更糟糕。

拿我的真实经历举例子。

当得知自己团队的 A 项目即将迎来开源共建时代的到来，加班加点的在工具层面做了代码规范强校验的限制（husky + commitlint + eslint + lint-stage），也根据代码的提交情况，把有问题的代码拎出来公示在 Issue 里并附带改造方案。但是结果并不乐观，比如：

• 索性关掉代码检查
• 相同的问题反复出现
• 大量地复制粘贴，不思考复用的可行性
• 缺少有效注释
• 代码易读性和可维护性差

其实还有很多问题，都需要额外消耗精力去解决。如果精力不够，项目代码的熵越来越高，用不了多久就会变成屎山。

需求跟踪困难

参与开源的团队多了，需求方也多了。这些来自四面八方的需求如何做到统一评审？如何保证需求评审不是走形式？对于有争议的需求，谁能决策到底做不做？怎么确保需求的提出和实现是统一的？开发者们的代码实现了，有没有人力来测试？这些现实问题都很棘手。

最后

总结两条：

• 「内部开源」是把双刃剑，用对了地方，能产生很大的价值，但如果用错了，会造成很多不好甚至是不可逆的后果。
• 不管是什么范围内的开源，参与的「人」不靠谱，在别的地方整啥花活都没用。

前段时间在谷歌开发者文档上发现了一个系列文章，图文并茂的讲解了现在浏览器（Chrome）的内部工作机制，文章质量之高让我虎躯一震，所以决定着手进行这一系列文章的翻译。
虽然只有四篇文章，但是由于疫情后的这段时间，公司的产品同学们开始疯狂提需求，工作上还是比较忙的，导致翻译工作断断续续持续了一个月的时间。不过还好，在端午节的最后一天杀青。
这一系列的文章我第一时间同步在了自己的公众号上，果然太硬核的文章还是会造成一些取关（强颜欢笑）。
由于同步到这里的操作成本实在太高，我就直接贴公众号文章的链接了。

1. Part1: 浏览器的多进程架构
2. Part2: 浏览器中的导航
3. Part3: 渲染进程的一生
4. Part4: 浏览器是如何处理用户事件的

四篇文章确实比较硬核，建议用比较集中的一段时间（30-60分钟）来阅读，读完之后会对浏览器的整体轮廓有一个更深的理解。

少侠留步

相信你一定是通过某搜索引擎来到这个页面，既然如此，说明我们是非常有缘的。
不妨关注我的公众号，日后可以更愉快的一起玩耍～

我的博客即将同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=15i5mq87zywvt

用惯了别人的，不如自己搞一个？

没吹牛逼…而且…包教包会!

Season 1
Season 2
Season 3

为了减少资源管理的负担，我用的是百度云分享，但这个傻逼产品时常抽风（分享链接被屏蔽），所以，如果这篇博客的链接失效了并且你又非常渴求 Rick and Morty 的资源，不妨发邮件告知我，我会第一时间把资源链接给你。
发现了另外一个很好用的共享工具，如果还是有问题，依然可以发邮件给我。
kyrieliu@foxmail.com

Hexo apollo 主题对文章字数有限制，以及代码排版不是很美好，因此就直接放出公众号的文章地址了。

刚打完两把王者，两连败。

一场射手，一场法师，都打出了30%+的伤害，但还是被对面捉的没脾气，不出意外的话，是团队协作上的问题。

从年前到现在，在一家金融大数据行业的独角兽企业搬砖，虽然公司的 level 比不了上一家，但于个人而言，薪资和在团队中的发言权都有了一定的提升，是件好事。

To B 的公司都是一些脏活累活，这个我深切感受到了。从客观上来说，团队之间确实存在一些问题，但这不应该是我关注的重点，我也改变不了什么。在复盘整件事情的时候，尤其是那些出现冲突和矛盾的时刻，我当下的感受 feeling 和反应 reaction 才是可以提炼出一些宝贵经验或是反思的关注点。

面对上级

在传统企业里，这可能是一个需要贯彻整个职业生涯的命题。但对于互联网出身的我(以及本身的性格)，这道题就从必答题变成了加分题 —— 不做，无伤大雅；做了，锦上添花。

互联网公司天生就自带”扁平的上下级关系”的特性，只要你业务能力不拖后腿，为人正直有趣，leader 会自然而然的看好你。这也一直是我所崇尚的一种双方关系。阿谀奉承这种事情，我一想到就会觉得抵触，自己也很难去做出来，这一点可能是受到了父辈的影响。

在经历了一些价值观念上的冲突和挑战以后，在现阶段以及不久的将来，我给自己的指导方针是：

1. 如果有选择的机会，尽量去更符合自己风格的公司和团队
2. 存在即合理，不要太着急 say no
3. 试着调整自己而不是环境，毕竟在漫漫的人生长河里，不顺是常态

面对同事

所谓同事，就是一起做事，是一种搭伙把事情做完做好的合作关系。作为一种职场上最亲密的社交关系，应当更小心谨慎的处理。

好同事能给团队带来很多正面的作用，一群好同事就能营造起一片让人向往的团队氛围。何谓”好同事”，我认为这和”一个好的职场人应该具备哪些素质？”是同样的命题。

1. 专业能力过硬，不拖团队后腿
2. 团队协作能力良好，懂得在团队中展示自己更得体的一面
3. 具备其它社交场合中比较基本的一些品质

相比上级，同事是更容易处理的一种关系。优秀的人之间会惺惺相惜，和谐相处甚至深交自然不是什么问题；若运气不好碰到不靠谱的同事，我目前的处理方式是：不夹杂任何个人情感的公事公办。

面对下级

说来也神奇，在我毕业后不到两年的时间里，居然有了下级。虽然也是生平第一次处理这种关系，但我不要脸的认为，我是完全可以 hold 住这种关系的。

1. 下级并不低谁一等，行政上的职级划分不代表工作中就是大哥和马仔的关系
2. 归根结底下级也是同事，适用上一 part 的所有规则
3. 作为一个更有经验的人，应当在力所能及的范围内给予下级引导和帮助（开源精神）
4. 一定要教会下级如何正确的提问，不然时间久了谁也顶不住，参考提问的智慧
5. 对下级的考核一定要客观，晋升和淘汰机制在职场中都是至关重要的，不要给团队挖坑

最后

所谓职场的社交关系，工作和社交都是重要的组成部分，前者注重工作能力，后者强调交际情商，两者需要协调搭配，才能做到不给任何人挖坑。

传送门

昨天微信发布了轰动互联网的 7.0 版本，有很多新东西，体验之后觉得都是很有趣的 feature，具体都是怎么个玩法也没什么可说的，各大自媒体都在第一时间发了“新闻稿”，我想谈点别的东西。

Sublime 简直是前端 coding 神器
什么需求都能满足
我这辈子就用 Sublime 了
嗯，VScode 真香！