掘友等级
获得徽章 0
为什么要提“企业数字化转型”？
1，团队协同视角：数字世界中的信息传递效率理论上为光速，让工作普遍发生在数字世界里，对企业来说是最有效、最全面，且普适的降本提效手段。
2，管理运营视角：数字世界与现实世界相比最大的优势在于，一个被充分数字化的问题，有可能通过数学工具被优化到极致，而在现实世界没有这个可能。所以，要提高管理运营能力，先搞定数字化。
3，生产力视角：在可以预见的未来，ai的革命性生产力，主要还是发挥于数字资产的生产。而数字资产的变现，需要数字化企业的支撑。所以一个企业希望充分享受ai生产力的红利，必然把自己打造成数字化企业。
造轮子大多数时候并不能提升你的技术水平——注意我说的是“技术水平”，不是“知识量”，也不是“熟练程度”。
编程也好，架构设计也好，或者推而广之，任何工程领域，最难的，也是真正有价值的部分，不是具体的实现一个什么东西，而是面对一大堆模糊的、变动的、无边界的、不自洽的需求，设计一个方案真正把问题解决掉。
但是造轮子省去的恰恰是这个最宝贵的环节，别人都把轮子定义好了，你再去实现一边，尤其是大部分人是无脑实现，或者无脑简化实现，其实学不到什么真东西。
研究SSR语境下的微前端架构，可能会是打开下个时代企业IT系统前端架构的钥匙——SSR对应着前端职能从“大前端开发”逐步转变为“应用搭建”之后，面临的代码分发和部署问题，而微前端，对应着大型企业IT系统所固有的项目管理与集成问题。前者是前端的发展方向，后者是企业IT架构的复杂性，这两者碰撞出现的火花，就是企业IT前端架构的未来。
最近了解了一个新概念：“蒯因”，可以大致理解为如果一部机器能自己生产自己，那么这个机器可以被称为“蒯因”的。我模模糊糊的有种感觉——这个概念可能是中台架构乃至企业数字化架构领域的一些深刻问题的答案。
给技术文章作者朋友们提个建议——你们写文章之前，是否考虑下自己的选题是否太大了？我相信愿意写文章的朋友，对技术都是有一定热情和能力的，但是有时候看一些文章，不免有一种感觉——标题太大，内容太浅。
在大家都有一定热情和能力的前提下，内容太浅的原因，多半就是标题太大。你要写的东西你掌控不住，就会导致要么浮光掠影，拾人牙慧，要么标题谈森林，内容却只有树木。
我相信很多朋友都有这样的经历——读研或者写本科毕业论文的时候，开题阶段导师会催着我们缩小选题，因为在你不是大牛的前提下，你定一个大课题，说明你问题定义不清晰，还没有完全进入科研状态。
其实工作阶段的文章也是一样的道理，真正想写一篇有营养的技术文章，是很不易的，很多时候需要作者“降维打击”——如果你在工作中负责模块级的开发，你写文章最好写代码实现或者单一工具使用，如果你工作中负责项目级的开发，你写文章最好写模块级别的，这样就容易把文章写的完整且新（因为你有全局的视角和资深的经验）。
但现实中很多作者是反过来的——可能一个新人已经在写架构级别的文章了，这样的文章必然会呈现“流水钱”的质量，因为你在写一个你还没有完全掌控或者压根没掌控的东西。
其实这个话题还可以深化下去，比如如何在工作中克制“宏大叙事”的欲望，平衡领导需要你画饼的现实和执行层面越精确对自己成长越有利的道理，这就是另一个话题了，说实话我觉得自己谈这个话题还不够资格，等心里有底了我会试着写文章谈一谈。
总之就是想说，很多时候文章不好，并非大家在敷衍，也并非“中国就不能有好的技术社区”，只是有些有热情也有能力的作者，可能还没找到写好文章的方法，希望我上面的话，能帮到大家。
现在的前端培训真的太卷了，我最近看了几个培训班的课程，别说当讲师，当学生我感觉我都费劲![[捂脸]](//lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_28.8981538.png)
，讲全链路性能优化，从浏览器原来开始从头到尾给你讲一遍，讲v8引擎，各个模块的原理和实现细节全给你讲一遍，讲框架，带着你从头到尾写一个框架……
这样培训出来的前端，八股文完全不虚面试官，怪不得现在的大厂各种考leetcode了，也只能考leetcode筛人了。
其实leetcode现在也有培训。
![[捂脸]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_28.8981538.png)
，讲全链路性能优化，从浏览器原来开始从头到尾给你讲一遍，讲v8引擎，各个模块的原理和实现细节全给你讲一遍，讲框架，带着你从头到尾写一个框架……