1号店张立刚：架构师不写代码，怎能知道技术的痛点？

背景

什么是架构师？业内一直没有定论，在前两天『聊聊架构』群的讨论中，来自各大互联网公司的架构师都对自己的工作内容做了总结，然我们还是没有抽象出架构师的定义。反而引来了跟多的问题，比如：

1. 架构师应该写代码吗？

2. 架构师有分类吗？

3. 好的应用应该包含哪些特点？什么才是好的应用系统？

4. 对于架构师，有哪些能力要求？

5. 怎么才是完整的方案？ 怎么写出完整甚至完美的方案？

为了回答这些问题，1月10日晚上8点30分，我们邀请了1号店资深架构师张立刚来分享他自己的经验。本文根据其演讲整理而成。精彩观点提前看：

1. 代码也有架构有规范，后续的维护、扩展全靠它了，代码的结构规划也体现出一个人的架构规划能力。

2. 给你一套新的毛坯房你能设计出一个漂亮的家，给你一套阴暗狭窄的老公房你依然能设计打造出一个温馨的家，这才是本事。

3. 空降的架构师要先放到具体的核心项目里，沉下心来专注于一线的代码开发、业务讨论等至少2-3个月的时间，才有能力对现有系统提出相应的方案或改进意见。

4. 一个好的业务系统一定是技术与业务的完美平衡，完全满足业务需求做不出好系统。

5. 记住，首先技术是为业务服务的，再者，技术可以推动业务。

讲师介绍

张立刚，2012年7月加入1号店，架构部-OMS订单管理平台负责人，负责1号店订单、库存、拆单、运费、第三方平台订单等电商核心交易系统。期间，作为负责人及项目经理，主导并参与了1号店SOA治理、订单Service化、订单水平拆库&去Oracle迁MySQL、无线性能优化及拆pool、运费体系重构、库存准确率优化等重要项目，负责1号店与Tmall、百度、当当、B2B2C平台等第三方平台订单业务。立刚从0开始建立了1号店完善的订单监控、预警、履单体系，致力于构建新一代电子商务核心系统–智能OMS订单管理平台。

架构分类

关于架构，大体可以分为以下三类：

1.1 IT架构

基于硬件、网络等构建整体的IT运维架构体系，包括IDC机房、网络拓扑、安全、负载均衡、运维监控等

1.2 基础架构

主要基于基础服务的软件产品架构，如SOA中间件、消息中间件、规则引擎、大数据存储、数据库产品、第三方组件等，相对独立于业务系统、不考虑具体的业务场景，更多地关注技术产品本身的性能、可靠、可扩展等，服务于业务系统。

1.3 应用架构

偏重于业务功能的实现，在基于用户需求实现业务功能、提升用户体验的基础上，保证系统的性能、可靠、可维护、可扩展。

关于应用架构师

我个人更愿意把应用架构师称之为SA（system analysist），即系统分析师。

应用架构师是用户（需求方）与开发人员（实现方）的桥梁，他的作用就是把业务与技术更好地结合起来，站在中立的角度-不唯技术、不唯业务，在业务和技术之间找到那个平衡点，做出最好的系统。

记住：首先，技术是为业务服务的；再者，技术可以推动业务。

什么是好的应用系统（架构）

3.1 好的应用系统特点

1. 满足业务功能

2. 用户体验好

3. 稳定可靠

4. 维护简单

5. 扩展性强

3.2 完全满足业务需求做不出好系统

业务需求是理想、技术是现实，理想是我们希望像鸟儿一样自由地飞出银河系，现实就是我们刚能踏上月球，还上不了火星，还必须借助于笨重的宇航服、宇宙飞船。

3.3 纯靠技术做不出好的业务系统

以减少系统功能降低用户体验为代价的高可用、高性能、高并发等貌似很NB的系统是得不到赞赏的。

3.4 一个好的业务系统一定是技术与业务的完美平衡

找到这个平衡点，是应用架构师的职责。

架构师能力要求

4.1 先看一个百度而来的架构师能力要求

一般来讲，系统架构师应该拥有以下几方面的能力：

1. 具备 8 年以上软件行业工作经验；

2. 具备 4 年以上 C/S 或 B/S 体系结构软件产品开发及架构和设计经验；

3. 具备 3 年以上的代码编写工作经验；

4. 具备丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验；

5. 对相关的技术标准有深刻的认识，对软件工程标准规范有良好的把握；

6. 具有面向对象分析、设计、开发能力(OOA、OOD、OOP)

7. 精通大型数据库如 Oracle、Sql Server 等的开发；

8. 对计算机系统、网络和安全、应用系统架构等有全面的认识，熟悉项目管理理论，并有实践基础；

9. 在应用系统开发平台和项目管理上有深厚的基础，有大中型应用系统开发和实施的成功案例；

10. 良好的团队意识和协作精神，有较强的内外沟通能力。

4.2 如果我要招聘应用架构师会再加一条，并且是第一条

优秀的业务理解、分析能力，能站在业务的角度实现用户需求、提升用户体验。

因为上述的10条要求大多地是从技术的角度考虑的，可忽略了一点，我们做出来的系统是给用户使用的，用户说好才是真的好。

4.3 架构师的职责，不仅仅是技术

1. 架构师要做以下工作：

   需求分析->系统分解->技术选型->系统设计->培训与指导->沟通与推动

2. 技术选型、系统设计才涉及到技术，培训与指导也仅仅一半是技术相关，其他基本与技术无关

4.4 架构师是一个多角色综合体

1. 用户—使用方

2. 产品设计者—产品经理

3. 方案设计者—狭义上的架构师

4. 开发人员—功能实现者

5、 维护人员—系统维护者

只有站在一个系统所有的干系人角度，你才能设计出好的系统。

几点经验

5.1 架构师不仅仅是技术架构，也是业务专家

专注于技术领先的是技术专家，不是应用架构师。

首先站在业务的角度去考虑问题，找到业务架构和技术架构的平衡。

5.2 架构师要培养

1. 空降的架构师不接地气，给出来的方案或架构很美、很理想，但很难落地实现。这个方案拿去给投资方演示很有用。

2. 空降的架构师不是能力不行，而是他不了解现有系统、技术和业务

3. 空降的架构师要先放到具体的核心项目里，沉下心来专注于一线的代码开发、业务讨论等至少2-3个月的时间，才有能力对现有系统提出相应的方案或改进意见

4. 架构师要内部选拔，不足是视野不够，要提供学习培训等机会让其开阔视野，如InfoQ架构师峰会（没收广告费哈）。

5. 外部空降+内部选拔+培养的方式，能让你的架构师团队更强大，只是培养方式要稍有不同，外部空降的要往下摁让其根基牢固有深度、内部选出的要往上拔让其视野开阔有高度。

5.3 不要轻易说推倒重来

1. 在初始阶段设计出可扩展的架构是架构师一般的能力体现

2. 在维护阶段能在现有架构基础上进一步提升系统的扩展性，这是架构师的境界。

3. 给你一套新的毛坯房你能设计出一个漂亮的家，给你一套阴暗狭窄的老公房你依然能设计打造出一个温馨的家，这才是本事。

4. 太多的系统，我们永远没有推到重来的机会，只能优化、优化、不断地优化

5.4 架构师要不要写代码？可能的话，尽量写吧

1. 不写你怎么知道技术的痛点、怎么把控技术的方向

2. 代码也有架构有规范，后续的维护、扩展全靠它了，代码的结构规划也体现出一个人的架构规划能力

3. 技术人员最崇拜的就是技术，在这个圈子里除了以德服人，以技术服人更容易被大家接受，至少要有共同语言不要让大家嘲笑你吧

作为架构师，你能写出一个完整的方案吗？

6.1 怎么才是完整的方案

一说方案，好多人就拿出技术架构图、流程图了，很漂亮很完美，NO，NO这不是一个完整的方案。

完整的方案应该包括但不限于以下要素：

1. 项目概述：项目背景、项目需求、项目价值、项目干系人

2. 系统概述：系统目标、系统功能

3. 系统设计：架构设计、技术选型、系统性能\容量\扩展、功能设计等

4. 系统实现：详细开发设计、数据库设计等

5. 系统依赖：中间件、第三方系统、第三方组件等

6.2 怎么写出完整甚至完美的方案

还记得上面说的那几个角色么：用户、产品设计者、方案设计者、开发人员、维护人员

同时站在他们的角度看，你一定会写好的。