得，今天就来唠唠“程序架构是做什么的”这个话题。这玩意儿听起来挺悬乎，没那么复杂，都是实践里摸爬滚打出来的经验。

刚开始干活那会儿，哪懂什么架构不架构的。拿到需求，撸起袖子就是干。代码咔咔一顿写，功能实现就觉得完事儿。那时候觉得，写代码嘛不就是把功能堆上去就行？简单直接。

结果？

我记得很清楚，有个项目，一开始功能简单，代码写得也挺顺。后来需求不停地加，不停地改。东加一块，西补一块。那代码，简直没法看。我自己想加个小功能，都得找半天，捋半天线索，还生怕改这儿，别的地方又出问题。那感觉，就跟在一个堆满杂物的仓库里找东西一样，头都大。

更要命的是，后来项目要加新人。新人来，看着那坨代码，一脸懵。我得花大把时间给他讲，这块是干啥的，那块是干啥的，数据从哪儿来到哪儿去。效率低得不行，而且稍微复杂点的改动，新人根本不敢碰。

那时候我就琢磨，这肯定不对劲。不能每次都这样，项目越搞越大，维护成本高得吓人，改个东西跟拆炸弹似的。

痛定思痛，开始琢磨咋回事

后来跟一些老前辈交流，看一些别人的项目，慢慢才有点感觉。发现人家那些好维护、好扩展的项目，代码不是随便堆的。它们是有“骨架”的。

这个“骨架”，就是我们说的程序架构。

它到底是干嘛的？按我的理解，就是在你动手写具体功能代码之前，先搭好架子，规划好蓝图。

• 先想想你的程序要分成几块？ 比如，跟用户打交道的部分（界面啥的）放一块，处理数据、算东西的部分（业务逻辑）放一块，跟数据库或者其他外部服务打交道的部分（数据存取）又放一块。
• 这些块之间怎么沟通？ 不能随便乱调，得定好规矩。谁能调用谁，通过什么方式调，传什么数据，返回什么结果。
• 数据怎么组织？ 哪些数据是核心的，怎么存，怎么管理，保证数据不出错，不丢失。
• 用什么技术来实现这些块？ 选合适的技术也很重要，不能拍脑袋决定。

你看，这些想清楚，再去填具体的代码，就不会像我之前那样，搞成一锅粥。

实践中我是怎么做的

后来再做新项目，我就学乖。不再急着写代码。

第一步，先理解需求，然后开始画图。不是啥高大上的图，有时候就是简单的框框图。把主要的功能模块画出来，连上线，表示它们之间的关系。比如，用户下一个订单，数据是怎么从界面流到业务处理，再到数据库的。

第二步，定好“分层”的规矩。 我比较喜欢简单明确的分层，比如常见的界面层、业务逻辑层、数据访问层。规定界面层只能调用业务逻辑层，业务逻辑层可以调用数据访问层，但是数据访问层不能反过来调用业务逻辑层，更不能调用界面层。这样代码就不会缠在一起。

第三步，定义好接口。 就是层与层之间，或者模块与模块之间怎么对话。把函数名叫什么，需要传什么参数，返回什么结果，都先大致定下来。这样，不同的人负责不同的块，只要接口对得上，就能协作。

第四步，才是开始写代码。 按照之前搭好的架子和定好的规矩，把各个模块的功能实现出来。

这么搞下来，确实感觉不一样。

• 代码结构清晰多，找东西、改东西方便。
• 出问题，也比较容易定位是哪个部分的问题。
• 加新功能，只要不破坏整体结构，往对应的层或模块里加代码就行，对其他部分影响小。
• 团队协作也顺畅，大家各司其职，对着接口干活。

架构也不是一成不变的。 随着业务发展，原来的架构可能不适应，还需要调整、优化，这叫架构演进。但关键是，一开始就要有这个意识，打好基础。

要问程序架构是做什么的？我的实践告诉我，它就是盖房子之前的图纸和施工方案。它帮你把复杂的系统拆解成可管理的小块，规定好它们怎么协同工作，让你的程序更健壮、更容易维护、更容易扩展，也让你和你的团队少掉点头发。