怎么像前端架构师一样想问题
我们大多数人，都是从写组件开始的。
照着设计稿做，把props写好，数据拉过来，功能跑通就行。但项目越做越大，问题就来了。文件不好找，代码开始重复，Bug到处冒，团队之间做的功能重叠。代码没有像我们想的那样顺利长大。
这时候，我们就被推着开始像架构师一样想问题了。
我觉得这种能力什么时候都能练。不管你干这行几年，是新手还是老手，都能学。不用等公司给你个头衔，换个角度看代码就行。
从干活的人变成设计系统的人
当架构师，不是你资历最老就行。关键是你怎么想问题。
你得从手头的任务里跳出来，开始问一些更深的问题：
UI这一层，我们的数据结构应该长什么样？
某个功能到底该归谁管？
这个组件半年后别人会怎么用？会不会用错？
怎么让代码对别人更友好，不光是自己看着顺眼？
这种活比写功能安静，但影响更长远。
1. 把组件看成层，不是盒子
大多数人把组件当成装东西的盒子。架构师看到的是职责分层。
举个例子。一个用户列表页面。常见做法是把所有逻辑都塞进一个UserList组件里：拉用户、loading状态、事件处理、UI布局，全放一起。
但如果退一步，按职责分层看：
UI层只管展示，不关心数据从哪来，也不管状态怎么变。
行为层管副作用、状态切换、调接口。
服务层处理api通信、存数据、业务逻辑。
这样一分，代码就好预测了，好测了，也容易复用。
我们不再写缠在一起的组件，而是开始组合组件。就像音乐家作曲一样。
2. 相关的东西放一起，但要有个度
把相关的代码放一起挺好的：样式、逻辑、结构放一个文件里，好找。但架构思维会让你想：什么时候"放一起"会变成乱？
如果有五个页面都用同一套状态逻辑，但每个页面自己写一遍，这不叫放一起，这叫重复写。
架构师要学会在重复开始成问题的时候才抽出来，不是一开始就抽。抽太早和抽太晚一样危险。
把代码当成种花：先让它长，长得差不多了再剪。
3. 用"契约"的思维看组件
每个组件都会露个脸给人看。我们通常只看视觉上的脸，也就是UI。
但还有个更重要的东西：契约。
这个组件接收哪些props？
对这些props我们默认了什么？
我们用组件的人承诺了什么？
一个好组件，应该有最小、最清楚、最有目的的API。别人用错的时候，它要能清楚地出错。它要能说明白自己期待什么。
这种思维不光少出Bug，还在组件之间、团队之间、过去的你和未来的你之间，搭起信任。
4. 为变化设计，不光为当下
架构师不会去猜未来怎么变。猜也没用，猜不准。
他们常问的是：如果以后要改，会不会动一处全得改？
所以要避免：
- 依赖嵌太深
- 状态绑太死
- 到处写死配置
很多时候，我们会故意加一层中间层，哪怕现在看着有点多余。因为我们知道，软件这东西，唯一不变的就是会变。
我们不是不让变化发生，是让变化发生的时候安全点。
5. 在开发者体验上花功夫
这可能是前端架构里最容易被忽略的事。
我们为用户做产品，但也在为开发者做系统——为同事，也为将来的自己。
这代码好读吗？
有没有清楚的套路可以照着写？
设计变量和组件的属性是不是一致的？
新人上手是顺的，还是难受的？
我们常说"开发者幸福感"，但这话其实有很具体的来源：名字起得好、结构能猜出来、默认值合理、文档清楚。
我见过一句话说得特别好：架构，就是把体谅做进结构里。
6. 知道什么时候可以不守规矩
架构思维给你的是指南针，不是笼子。
总有些时候，我们要抄近路、做实验、临时凑个方案。这没问题。
关键是：我们是不是有意识这么做的？知不知道为什么破例？知不知道以后得回头修？
这不是要完美，是要心里有数。
最后说几句
像前端架构师一样想问题，不需要谁批准。从好奇开始就行，从看模式开始，从在意别人怎么用你写的东西开始——不管这别人是用户，还是同行。
不用怕架构。它跟学hooks、学props、学布局一样，能一步一步来。而且可以从最小的组件做起，有意识地去用。
有时候，我们能做的最有用的事，就是停下来，把镜头拉远，问一句：
"这个问题到底长什么样？"
这时候，我们就开始变成架构师了。
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！