为什么我认为架构师需要坚持写代码?

2015-12-09 Tim TimYang TimYang


最近在高可用架构群、EGO会员群等多个场合,大家都在讨论架构师的能力的问题,架构师应该具备哪些能力?在面试时如何合适的评估一个架构师的能力?


架构师的两种类型

第一种是可以将业务实现的人,他可能需要整合公司不同部门的资源、解决不同技术模块整合、解决不同版本之间的兼容性、解决各个模块的技术选型等,解决任务的分解及分配,解决进度上出现的问题。当上面所有这些问题都完成后,架构师顺利帮助公司完成了项目目标。


第二种是在第一种的基础上,利用技术的力量,改进了一个领域的效率或提升了生产力。比如一个在现有技术基础上提升20%效率的视频解码模块、或者类似美剧硅谷中的,研发出一套压缩比很大且保持高质量信息的压缩算法。目前的大部分互联网创新在某种程度也是利用技术变革的力量,比如电子商务及在线教育等行业。


如果从输出结果的角度来看,架构师有两种类型,具备技术杠杆能力的和不具备杠杆能力的架构师。并不否认第一种架构师在战略执行层面的作用,他们是各个软件开发团队的中坚力量。但从影响力的角度,其归根结底是在一个画好的表格里面填东西,他从事领域的最终的格局是由市场、运营或者产品主导。而一种是真正具备杠杆能力的工程师或者架构师,他可以利用技术的力量,在填写一个格子的同时,利用技术的力量,将格子的功效放大,影响十倍或者百倍以上的结果。比如在音乐播放软件中,推荐算法的应用彻底改变了用户播放音乐的习惯与体验。


很多人所说的架构师的设计能力,大多也可以归纳到第一种情况。很多所谓的架构设计,就是拿着多年一成不变的分层模式往业务上套,把业务按照功能规划成软件模块填写到架构图,并且把上下游的调用串起来。这种设计的大多时候是起给客户或者领导展示的作用。程序员代码的整体构思,大多可以通过白板上或者白纸以及程序员直接的沟通很敏捷的完成,大多不需要一个专职画图纸的架构师来指导。


第一种架构师是可以不写代码的,因为他大部分所做的事情是跟人打交道、分配任务以及解决开发过程中各种进度问题。因此很多技术负责人面试时候看重协调能力等非真正的技术能力。而那些服务甲方项目型的公司,更是特别看重人际关系、沟通能力、展示能力等跟客户打交道的能力。另外一些软件版本历史包袱重的企业,则看重架构师的打补丁能力。由于功能型及偏执型型的团队偏多,因此在很大程度上造成了架构师的能力标准的偏离,在一些讨论的场合,过份看重项目执行中的个别技巧型能力,比如项目管理、人际关系等能力常常还占据了主流的声音。


但这类架构师只能勉强称为“技术架构师”,因为大部分时候,他做的事情是填格子,而无法做到利用技术的力量,把一个格子放大到10个格子及更多。在另外一方面,这些不写代码进而慢慢丧失代码能力的“架构师”,也不太可能利用技术的力量去做发挥技术杠杆的事情。当然技术架构师也可以驱动工程师去完成一个技术型的大项目,大型的项目也需要合理的组织,但并不意味不写代码的人就比写代码的人做得更好。而那些对技术体系有深入了解及一线体验的架构师,比那些只跟人员管理打交道的人,更有机会利用技术的力量促进变革。


因此如果希望一个架构师有令人满意的技术驱动能力,他应该具备代码能力,对技术有直接的了解及体验,进而能够精通如何利用技术来改变未来生产力。


如何面试及评估架构师的能力

Tim 的面试方法是,候选人需要第一步通过电脑上完成一个小型的代码实现,在代码基本符合要求的情况下,才会获得所有面试官可以接受的一个能力起点。如果不做这一点,面试时候,面试官需要费尽心思去问对方项目上更多细节问题,才可能了解一个候选人真正的开发能力。而通过考试,则可以在验证候选人具备一定开发能力的基础上,愉快的聊一些其他轻松的话题。


在EGO会员讨论时候,一部分创业公司技术负责人担心一些资深的候选人不能接受这种方式,国内这种现象确实也不少见。但换个角度来想,创业公司大多还在起跑阶段,需要的肯定是从事大量一线开发的人。如果面试通不过机考编程,或者是不愿意做题,这种候选人也未必能完全适合创业公司需要。而那些不愿意做一线事情的架构师即使进来,他大部分时候在分派任务或者强化流程,可能让公司的技术层级及开发环节变多、管理成本变高进而导致整体研发效率下降。


面试时候大家也认可的一些验证架构师能力的方法,比如把当前技术开发中遇到的一些典型性技术场景让对方来提出实现方案,以便评估对方是否具备应对类似场景的能力。在入职之后,可以让新的架构师独立承担及完成一些任务,以便考察对方是否具备独立的架构实现能力。


正在做的与架构师相关的一个新的尝试

说个和更好运用技术杠杆相关的事情,考虑到不少同行对技术、架构、视野方面有更高的诉求,如果有一个场所能够进行一些更专注的技术传播及讨论,推进技术更好的发挥推进互联网发展的杠杆作用,因此在利用目前我个人业余管理的高可用架构群的平台来做一些不同的尝试。


初步的想法是创建一个收费群,供部分有兴趣的会员使用,一些使用规则说明如下。


  • 高可用架构会员群提供一个交流互联网技术为主,其他知识内容为辅的环境;

  • 在此基础上,尽力创造探讨技术变革的环境,探讨改变互联网的构造方法;

  • 该群为收费群,入群前需要交 1024 元 / 年;

  • 提供 7 天犹豫期,年费在 7 天内无条件退款,7 天后不再提供退款;

  • 群规以维护大部分成员的集体利益为主,给大部分人员带来困扰行为的成员可被取消资格;

  • 该群独立运作,不影响目前高可用架构系列免费群的运行;

  • 2015 年 12 月 31 日之前如果不够 100 人,群解散活动取消且全额退款;不过到今天(12 月 9 日),已经完成大部分招募指标。欢迎感兴趣的朋友继续报名。


请长按以上二维码图片,保存至相册,然后用支付宝识别,付费入群。


关于高可用架构

高可用架构由本人业余发起创建,主要关注互联网架构及高可用、可扩展及高性能领域的知识传播,其文章主要来源于高可用架构系列微信群的内容分享。订阅用户覆盖主流互联网及软件领域系统架构技术从业人员。


高可用架构系列微信群是一个社区组织,其精神是“分享+交流”,提倡社区的人人参与,同时从社区获得高质量的内容, 该系列群有近2,000位主要来自国内外互联网行业的架构师,首席架构师,CTO,资深工程师等组成,包括大量QCon明星讲师及互联网资深讲师参与分享优质内容。


高可用架构部分分享讲师名单(按姓名首字母排序)


  • 陈飞 新浪微博技术经理

  • 常雷博士 Pivotal 中国研发中心研发总监,HAWQ 并行 Hadoop SQL 引擎创始人,Pivotal HAWQ 团队负责人

  • 陈宗志 奇虎 360 基础架构组高级存储研发工程师

  • 杜传赢 Google 研发工程师

  • 付海军 时趣互动技术总监

  • 冯磊 新浪微博技术保障架构师

  • 高磊 雪球运维架构师

  • 郭伟 腾讯安全架构师

  • 高永超 宜信大数据创新中心云平台运维专家

  • 黄东旭 Ping CAP CTO,开源项目 Codis co-author

  • 霍泰稳 InfoQ、极客邦科技创始人兼 CEO

  • 蒋海滔 阿里巴巴国际事业部 高级技术专家

  • 金自翔 百度资深研发工程师

  • 吕毅 前百度资深研发工程师

  • 马利超 小米科技的系统研发与大数据工程师

  • 马涛 前迅雷网络CDN系统研发工程师,前 EMC/Pivotal Hawq 研发工程师

  • 彭哲夫 芒果 TV 平台部核心技术团队负责人

  • 秦迪 新浪微博研发中心技术专家

  • 沈剑 58 到家技术总监/技术委员会负责人

  • 孙其瑞 得图技术总监

  • 唐福林 雪球首席架构师

  • 田琪 京东云数据库技术负责人

  • 王富平 1 号店搜索与精准化部门架构师

  • 王劲 酷狗音乐大数据架构师

  • 王晶昱 花名沈询,阿里资深技术专家

  • 王康 奇虎 360 基础架构组资深工程师

  • 温铭 奇虎 360 企业安全服务端架构师,OpenResty 社区咨询委员会成员

  • 王新春 大众点评网数据平台资深工程师

  • 王晓伟 麦图科技

  • 王渊命 Grouk 联合创始人及 CTO

  • 王卫华 百姓网资深开发工程师及架构师

  • 萧少聪 阿里云 RDS for PostgreSQL/PPAS 云数据库产品经理

  • 杨保华 IBM 研究院高级研究员

  • 颜国平,腾讯云天御系统研发负责人

  • 闫国旗 京东资深架构师,京东架构技术委员会成员

  • 杨尚刚 美图公司数据库高级 DBA

  • 尤勇 大众点评网资深工程师,开源监控系统 CAT 开发者

  • 张开涛 京东高级工程师

  • 赵磊 Uber 高级工程师

  • 张亮 当当网架构师、当当技术委员会成员、消息中间件组负责人

  • 赵星宇 新浪微博 Android 高级研发工程师

  • 周洋 360 手机助手技术经理及架构师