Weekly Summary(20220220)
SRE
最近领导提了好几次这个概念，这里做个记录：
SRE 全称是 Site Reliability Engineering，最早是由 Google 提出，并且在其工程实践中发扬光大。 他们还出了一本同名书籍「Site Reliability Engineering」， 让这个理念在互联网工程师圈子里广泛传播。
Google 对 SRE 解释是（via Site Reliability Engineering - Wikipedia）：
Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations whose goals are to create ultra-scalable and highly reliable software systems.
从定义来看，DevOps 是文化、运动和惯例，而 SRE 是有严格任职要求的职位。 文化是软性定义，文化有更多概念可以捏造，而 SRE 定义精准，就少了想象空间（也可能 SRE 门槛高 ）。 按 Google 给出的说法是，SRE 工程师实践了 DevOps 文化。
参考资料：https://zhuanlan.zhihu.com/p/87598465
2009 年 Fliker 的开发概念
2009 年，Flicker 提出了每天发布 10+ 次概念，其几个核心理念为：
- 业务快速发展，需要拥抱变更，小步快跑
- Ops 目标不是为了网站稳定和快速，而是推动业务快速发展
- 基于自动化工具提高 Dev / Ops 联接：代码版本管理、监控
- 高效沟通：IRC / IM Robot（现在那些 ChatBot 套路，10 年前就被 Flicker 玩过了）
- 信任、透明、高效、互助的沟通文化
难以想象，我们今天推崇的一些概念，居然在 10 多年前就已经被别人提出了。
不要将软件开发想得太简单
我发现领导经常会有一种思维：
- 看到某个文章，里面提到了某某公司做了某某事情
- 问我们是不是也能搞这个？
这个思路没错，多学习、多借鉴、多引入。但是有一个问题，就是没有配套资源。
比如某某公司搞了 LowCode 搭建，然后就让我们搞，问题是别人是一个团队几十号人专职搞这个，而我们是现有人员在背着现有业务的情况下搞，这能搞出个啥？进度慢不说，弄出来的东西配套设施生态啥都没有，很难用，推广也推不出去，最终大家累过一场，又不了了之了。
大家都追求快，但是这并不一定是对的。现在已经过了互联网爆发式发展的阶段，靠快速上功能已经无法打败竞品了，市场需要的是精雕细琢的精品，而不是一大推我有别人也有的凑数的产品。
守正出奇，方为正道。
人生就像线性回归一样，迟早要回到属于自己的地方
兜兜转转，最终还是回到初心所在的地方。
清理不良资产
人的精力是有限的，需要将意义不大的内容干掉，聚焦在价值体现明显的方向上。
能交接的交接出去，不能交接的学会借力。
数据可视化人员难招，背后隐藏的信息
1、可能说明市场需求的热度并不高；
2、可能说明应该通过更细分的领域和职业去招人；
3、可能说明大部分公司对可视化的定位只是一个工具，而不是完整的一个职位。
如何持续专注的学习
身体得锻炼起来了，不然硬件不支持，肯定是不行的。
晚上 6 点多座位上躺着眯了几分钟，居然做梦了。
兴趣驱动的不计价值的项目
兴趣项目可以大大提升你的技术水平。因为兴趣是最强大的驱动力，比金钱、名位都强大得多，你会愿意钻研技术的细节。很多优秀的开源项目，都来自个人兴趣，质量远胜大公司投入重金做出来的东西。
兴趣项目可以塑造一个人。 很多人没有意识到这一点，一般都是作者塑造作品，但是有些作品可以塑造作者。 你做着做着，变成了跟原来不一样的人。
许多知名程序员，刚入行时其实都很普通，看不出特别之处，但是他在追求自己兴趣的过程中，逐渐意识到了，自己是什么样的人，想要完成什么，从此找到了自我，全身心投入，成就了一番事业。
学习日记
2022.02.18
短视频前端项目的拆分设计：微前端、解耦
2022.02.17
查看粒子效果的技术实现方案
2022.02.16
重绘与重排的优化方案：理解浏览器的 flush 机制，通过缓存策略，减少这个 flush
看了下虚拟 DOM 的实现，里面的 patch 算法有不少技巧
2022.02.15
Vue 的变化侦测部分的原理