这是什么
主要用来记录自己在生活中的一些小感想(如果有说的不对的地方，欢迎指证)，可能会一直更新，也可能会断更，希望不要太监
8.12
今天读了两篇文章，一篇文章是《你可能并不需要微前端》，这是一篇技术随想文章，主要讲的是微前端这个概念在前端社区上已经烂大街了，以至于很多并不适合微前端的场景也用上了微前端，本文作者陈述了他的两个观点，一个是微前端是用来解决团队间协作带来的工程问题，而不是某个单纯的技术问题，另一个观点是微前端的是基于大型系统逃不过熵增定律（所有大型系统都将从有序变为无序，他们背后的 codebase 的归宿都将是「屎山」），当然在理想情况下是可以避免codebase成为屎山，但很多时候互联网工程师都是一茬又一茬，导致项目变成了屎山，微前端从解决屎山的角度就是不让一坨屎影响其他的代码，用西方人的话说就是上帝的归上帝，凯撒的归凯撒，作者也讲了一些微前端适用的一些场景：
- 旧的系统不能下，但新的需求还在来，这时候如果不想在屎上堆屎，可以考虑适用微前端
- 不同系统之间的边界区分明显，不想让不同系统的代码互相污染
第二篇文章是《我为什么从google离职》，其实读这篇文章自己也一度感同身受，从自己升入大三以来，自己一直在追求唯结果论，有点魔怔了，慢慢丧失了快乐的能力，以及很久没有思考过自己真正想要的是什么，当然我也没有文中的作者那么洒脱，没有生活的压力，可以放肆追求自己想要的东西，但我想我也可以做出一些改变，追求过程才是生活的乐趣所在，就比如写代码，最近业务上的压力比较大，以至于很多代码上值得思考的点没有写好，今天同事在写我之前写过的代码时，把我的代码提炼了一下，代码质量提示了不少，多沉下心来思考，让自己活的快乐一点，毕竟人生只有一次，生活是给自己过的，做让自己快乐的事情吧。 今天还发生一件事情，是关于沟通的，在和ui沟通时，一个样式上的问题，基于我们现有的组件能力，实现成本是非常高的，但ui坚持需要实现，无奈之下，只能找来组里一个老大哥来帮忙battle，老大哥battle的时候有一个点是我之前没想到的，从业务的角度出发去说服对方，作为一个ui和一个产品关心最多是这个功能带来多大的收益，以及需求排期，当收益和付出成本差异过大时，就需要评估一下这个功能的必要性，这个功能的出发点是有用户反馈我们的问题，老大哥没有过多的去讲这个功能技术上实现的难度，而是从根本去剖析让ui去调研用户真正需要的效果，以及这个需求实现的必要性，试着从对方的角度去分析一个问题是一种不错的沟通角度，能减少不少沟通成本
