download：大厂50万节点监控系统架构设计&Prometheus底层源码级剖析
业务前端的窘境与出路
业务部门的前端工程师，处在一个难以逃脱的怪圈之中——
大局部人想提升本身技术程度，却没时间和精神在工作时间「光明正大」地去研讨技术，这在组织里是「政治不正确」的做法，必需要业务为先，要研讨只能本人的非工作时间去下苦功夫。但是在非工作时间，由于人性或其他什么缘由，本人又不会去研讨技术，或者不够深化。
平常工作中在提效方面能做的顶多就是组件库和脚手架之类，一些应用、系统的架构设计工作，都被平台部门的人做了，直接用他们的东西就能够了。业务部门也根本不会让其下面的前端工程师去做整体架构方面的工作，由于不契合「价值观」，也就是「投资报答率」的问题。
大局部人在思想上存在一个误区——前端工程师不需求懂业务。以为本人的工作就应该是依据产品需求文档人工把设计图转化为页面，再与后端工程师把数据接口调通，保证本人没 bug 就行。
你看，就连本人都觉得本人在整个功用的迭代过程中充任「将产品需求文档与设计图转化为页面」的工具化角色，也就别怨他人把你当工具使了，可不就一个「有感情的工具人」咋的……假如前端工程师的价值如此，必定是被作为工具，作为资源呼来唤去。
前端工程师的这种行为，被称为「面向页面开发」；只会且整天围着框架、库团团转的，被叫作「面向框架编程」。
「面向页面开发」与「面向框架编程」的前端工程师会逐步失去竞争力，他们的工作终将会被其他职业的人或者非人工方式取代。
