你已经写了五年代码。
技术上你很自信。SQL、Spark、Flink、Python，各种技术栈都能玩得转。同事有技术问题来问你，你基本都能解答。
但最近你开始感到一种隐约的焦虑。
团队里新来了一个技术leader，比你小两岁。他不比你代码写得好，但每次讨论方案他总能提出一些你没想到的角度。老板开始把更大的项目交给他而不是你。
你心里有点不服气：我技术比他好，为什么重要的事情不让我来？
你开始琢磨：他有什么是我没有的？
想了一阵，你发现一个区别：他看问题的方式和你不一样。
你看到的是一个功能怎么实现、一个bug怎么修复、一个性能怎么优化。他看到的是一个系统应该长什么样、各个模块之间应该怎么配合、未来可能会有什么变化需要考虑。
你是在”写代码”，他是在”做架构”。
这是很多工程师在职业中期会面临的转型问题：从写代码到做架构。
核心区分写代码是解决问题，做架构是定义问题。
写代码回答的是”怎么做”，做架构回答的是”做什么”和”为什么这么做”。前者是执行力，后者是判断力。执行力让你成为好员工，判断力让你成为不可替代的人。
两者都很重要，但后者的影响力更大、可替代性更低。
如果你一直停留在”写代码”的层面，你的职业发展会遇到天花板。你会发现那些比你晋升更快的人往往不是代码写得最好的人，而是架构做得好的人。
两者的本质区别
为了更直观地理解，我们从四个维度对比代码思维和架构思维：
| 维度 | 代码思维 | 架构思维 |
|---|---|---|
| 关注点 | 算法对不对、代码能不能跑、bug有没有修 | 系统有哪些部分、如何交互、怎么保证扩展性 |
| 时间尺度 | 当前需求：功能写完这事就结束了 | 未来半年到三年：数据量增长10倍还撑得住吗 |
| 抽象层次 | 变量、函数、类、模块 | 组件、接口、数据流、服务边界 |
| 决策影响 | 影响一个功能或模块 | 影响整个系统、整个团队、未来很长时间 |
关注点不同。
写代码关心的是：算法对不对、代码能不能跑通、性能是否达标、bug有没有修复。做架构关心的是：系统有哪些组成部分、各部分之间如何交互、怎么保证扩展性和可维护性、怎么平衡各种约束条件。
时间尺度不同。
写代码解决的是当前的问题。功能写完、bug修复、这个需求就结束了。做架构设计的是未来的系统。要考虑半年后、一年后、甚至三年后系统会面临什么挑战。
架构师常问的问题是：如果数据量增长10倍这个架构还能撑得住吗？如果业务有新的需求这个架构能灵活扩展吗？如果团队成员换了一波这个架构能被快速理解吗？
抽象层次不同。
写代码处理的是具体的变量、函数、类、模块。做架构处理的是组件、接口、数据流、服务边界。架构图里没有代码，只有方框和箭头。每个方框代表一个概念，每个箭头代表一种关系。
能在更高的抽象层次思考，是架构能力的核心。
决策的影响范围不同。
写代码的决策影响一个功能或一个模块。你选择用什么算法、写什么样的代码结构，主要影响你负责的这一块。做架构的决策影响整个系统。你选择用什么存储、什么通信方式、什么分层结构，会影响整个团队、整个系统、未来很长时间。
架构决策一旦做出，改变的成本很高。所以架构师需要更谨慎、更有远见。
架构能力是什么
架构能力不是一个单一的技能，而是一组能力的组合。
系统思维。 能够把一个复杂问题拆解成多个互相关联的部分，并理解它们之间的关系。体现在：面对一个需求能快速识别出涉及哪些系统哪些模块、能画出系统的整体架构图、能解释各个部分为什么这样设计。培养方法是多画图——任何一个系统都试着画出它的架构图、多问”为什么”——为什么是这样分层为什么用这个组件、看开源项目的架构设计理解它们的设计思路。
权衡取舍。 在多个相互冲突的目标之间做出合理的平衡。架构决策总是在取舍：一致性vs可用性、性能vs成本、灵活性vs简单性、短期收益vs长期健康。好的架构师能够识别这些取舍，并根据具体场景做出合理的选择。培养方法是每次做技术决策时主动列出各个选项的优劣、问自己为什么选这个方案而不是那个、学习经典的架构案例理解前人是怎么取舍的。
抽象建模。 能够把复杂的现实问题抽象成清晰的模型。体现在数据模型设计能够设计清晰的表结构和关系、接口设计能够定义清晰的API和契约、领域建模能够把业务概念映射为技术概念。培养方法是练习数据库设计从零开始设计表结构、学习领域驱动设计DDD的思想、多看好的API设计理解它们的抽象方式。
