

近距离看一看常规软件项目中架构师的工作

鲁班搭软件

2025-12-24

对于架构师的面试中，我都会让面试者把其搭建的架构以及日常的架构工作画出来看一下，遗憾的是，绝大部分居然画不出一份清晰的架构图，日常的架构工作也整理不清楚，这就是我们IT行业普遍水平的反映，当然，还有99%的一手蹩脚字...

所以，在一个团队中，能够把架构画清楚、把字写清楚的，务要珍惜

。再能够把逻辑说清楚、简洁的架构师，更是少之又少。

下面把面试中架构师的日常工作信息汇总出来，近距离看一看有哪些内容，再放到组件化架构的体系下分析，看一看架构应该如何去发挥更大的作用：

1、项目前期阶段

2、项目开发阶段

3、项目收尾阶段

4、项目投产阶段

一、项目前期阶段

1、后台开发人员的能力了解：便于后续模块的分工

2、需求分析，给出：

1）数据库表结构

2）JAVA类图

3）核心流程时序图，比如登录验证、下单、发货

4）后端模块分解，比如商品模块、订单模块、物流模块

5）预设的部署结构图

3、开发规范约定：

1）技术栈约定：比如前端技术栈 vue3、后端技术栈 jdk11

2）基础框架约定：比如 Spring, DDD

3）基础环境约定：比如 mysql、activeMQ、redis、mongoDB

4、工具指定：

1) Nginx

2) Nacos

3) K8S

4) git

5) docker

6）jTest 等

二、项目开发阶段

1、后台模块的人员分配建议

2、通用模块的开发，比如统一登录、统一验权等

3、业务基座类的开发：基础接口类等

4、代码review

三、项目收尾阶段

1、模块性能测试与调整

2、部署结构的可能性调整

四、项目投产阶段

1、听取运营反馈，针对性优化

------------------------------------------------------------------------

通过上面的汇总，我们可以看到常规软件项目中架构师工作的一些特点：

1、相当于后端开发的负责人

2、对于前端，几乎没有涉猎

3、有相当多的工作在不同项目中是重复的

仔细推敲，架构师的工作中存在一些明显的缺陷：

1、“开发思维太重”：架构应该与业务开发分离，不解决好这个问题，会既没有好的架构，也做不好开发；

2、单体风险很大：

1）“给出数据库表结构”，给的不合理呢？可能导致许多开发都要重来；而且其潜在逻辑就是该架构师要精通这个项目涉及的所有业务领域，这个逻辑就是不合理的。

2）“基础环境约定，比如 mysql、activeMQ、redis、mongoDB”，这些约定往往并不是基于清晰、准确的业务量化指标，而是基于技术偏好。可能导致不必要的方式或者错误的选型，导致后续项目上为此付许多代价；

3）“业务基座类的开发”，基座设计不合理或者不完整，都会很大地影响整体开发，成为开发中的瓶颈。

3、没有整体架构

1）前端就依据产品经理的原型设计去逐页开发，这就是传统软件大量定制、成本不低、质量不高的起源；

2）软件系统核心的“业务对象”看不到，基本散在各处代码中，只见树木，不见森林。这样会导致系统整体上缺乏可持续维护的骨架；

3）故障排查和解决很麻烦：系统出现问题后，不能够直接准确地定位故障源。

由于我们现在的软件工程模式，是基于实现项目交付这样的目标的，架构对于软件系统的应该起到的作用、架构师应该去做什么工作，在这个模式中被模糊了，加之软件行业自身的历史并不太久，作为软件系统的核心：架构，其形态、价值，还远没有清晰化。看到的结果就是大量的低质、高成本、难维护的软件系统，在AI爆发的今天，架构对于软件依然成立，而且会更加凸显其价值。

基于工业化生产模式的软件架构，一定会来到。

【声明】内容源于网络

鲁班搭软件

分享、交流关于软件的组件化架构的思考、方法和实践，聚集同行、朋友，为行业在组件化、产业化的发展共赋绵薄之力。

内容 14

粉丝 0

鲁班搭软件分享、交流关于软件的组件化架构的思考、方法和实践，聚集同行、朋友，为行业在组件化、产业化的发展共赋绵薄之力。

总阅读8

粉丝0

内容14