热门标签 | HotTags
当前位置:  开发笔记 > 后端 > 正文

[架构师]论架构师的自我修养

转载:http:www.csdn.netarticle2015-10-252826034摘要:架构师,当然是脑力劳动者,但是同样是脑力劳动也存在重大的差别。有一类脑力劳动的

转载:http://www.csdn.net/article/2015-10-25/2826034

摘要:架构师,当然是脑力劳动者,但是同样是脑力劳动也存在重大的差别。有一类脑力劳动的成果,是比较容易被评价的。但是,架构设计只是软件开发过程中的一个环节,在这个多人协作的场景中,我们很难单独评价架构的优劣。

架构师,当然是脑力劳动者,但是,同样是脑力劳动也存在重大的差别。有一类脑力劳动的成果,是比较容易被评价的。或者能够判断其对错:比如考试的分数;或者能够比较其高下:比如两个人下棋分出输赢;或者能够交由市场来判断:比如某种UI/UE设计,我们可以通过数据统计,了解其受用户欢迎的程度。

但是,架构设计只是软件开发过程中的一个环节,而在这个多人协作的场景中,我们很难单独评价架构的优劣。由于硬件、软件、部署、人员、测试、用户、市场等众多的差别,即使是非常相近的两个系统,我们也很难判断两个架构孰优孰劣。比如:eBay的架构与Taobao的架构哪个更加优秀?在交付拖延的时候,我们可以将问题归咎于开发团队的效率低下。在出现质量问题的时候,我们可以将问题归咎于测试团队的疏忽大意。在负载撑不住的时候,我们可以将问题归咎于运维团队不够专业,甚至是竞争对手的DDoS攻击。那么,在出现什么样的问题的时候,我们可以将责任归咎于架构呢?

所以,现状就是:架构师是一个很难做好的职业。但是,从某种意义上来说,又是一个非常容易混的职业。(当然,混是另一种需要持续修炼的高端技能。)因此,架构师也是特别需要强调自我修养与职业道德的职业。

什么是架构?什么是架构师?

对于架构的定义,有很多种,我比较同意的一种定义是:“架构是一组关键决策”。这样的决策包括但不限于:使用什么操作系统、语言、框架与类库;是否在架构中使用某种全新的技术方案;优先考虑或满足哪一方面的需求以及如何在技术上实现这一点;更进一步的,面对一个不断发展的系统,哪些部分需要优先重构or优化、哪些决策需要重新考虑甚至修改;再进一步,某些前瞻性的考虑,也是架构决策的一部分,等到问题发生再来解决,同样是架构方面考虑不周。

能够做出这些决策的,就是架构师。或者说,在一个团队中,实际的最终决策者,就是事实上的架构师。无论他被赋予什么样的头衔。在一个团队中,我们总能找到这样的角色(无论他做得是不是称职),而一个优秀的架构师,就是通常能够做出“较多”正确决策的人。

架构师的工作是什么?

仅仅做出决策是不够的,我们可以从时间线上来观察:在做出决策之前,架构师需要足够了解自己的“可选项”,无论是用户的实际需求,还是最新出现的技术和框架,并且都得要有足够深入的理解(否则就是在拍脑袋做决策)。这时,架构师的角色,是一个“研究者”。

在综合各项因素,甚至是相互矛盾的各种需求之后,在考虑到团队的实际能力与交付压力之后,在平衡了先进性与可靠性、扩展性与稳定性、重要性与紧迫性之后,架构师做出了一组决策。这时,架构师的角色,是一个“设计师”。

为了确保自己架构设计能够被正确地实施和贯彻,架构师需要与研发团队密切配合,或者说服、或者引导、或者辅导、或者鼓动、甚至需要某种“强有力的推进手段”,这对于架构师的「硬实力」与「软实力」都提出了很高的要求。这时,架构师的角色,是一个“Top Coder”。

在某些大公司,架构师还需做很多的文档工作,这些文档并不是交付给开发团队的说明性文档。而是某种向上级证明某某方案可行,某某架构有效的证明性文档。这时,架构师的角色,是一个“说服者”。

从上面的描述,我们也可以发现,架构师像是一个千面人:需要与上下前后左右的不同角色打交道;多面手:需要了解甚至掌握诸多不同的知识和技能。要想做好这个工作,提升自我修养是根本之道!

什么是架构师的自我修养?

1. 以理解用户为荣,以想当然尔为耻

架构师不是产品经理,不是市场人员,不是客服人员。但是,如果只懂技术,只考虑技术,不能深入的理解用户的需求(强调一下,用户的真实需求!),就会做出“纯粹追求技术先进性”的想当然尔的架构出来。

2. 以脚踏实地为荣,以夸夸其谈为耻

架构师当然需要很强的表达能力,甚至还需要有忽悠能力。但是,无论是表达还是忽悠,都必须以“实力为基础”。如果不能脚踏实地,积累实力,只会夸夸其谈。那就相当可耻了。

3. 以身先士卒为荣,以指手画脚为耻

还是那个经典的台词“兄弟们跟我上”与“弟兄们给我上”的区别。如果对于一些困难的问题,架构师自己都搞不定,却摆出一副胸有成竹的表情:“这不是很简单的吗?你到网上搜一下嘛,资料大把大把的。”这种做派,就很令人不齿。

4. 以实践检验为荣,以道听途说为耻

如果某种技术,架构师自己都没有做过评测,没有看过框架代码,没有在过去的实践中应用过。却因为一篇文章,一个讲座,甚至某个大公司曾经用过这样的证据,就将一种技术引入到项目之中。这样的决策,很少有不失败的。

5. 以先见之明为荣,以后知后觉为耻

“过度设计”当然是一个贬义词,但是架构师一定要有前瞻能力。不能等到火烧起来了,再去救火。虽然在企业里,的确存在“救火英雄升迁快”的现象。但是,一个优秀的架构师,应该以“消除隐患于无形”为荣。

6. 以兼容并包为荣,以独断专行为耻

在架构领域,很少有唯一解、最优解。大多数时候,我们只能在多个各有优劣的方案中,反复权衡,考虑取舍。这时,开阔的视野、开放的心胸,就显得尤为重要。如果一味的独断专行,听不进团队里其他同事的意见(尤其是那些学习了乔布斯的架构师),就会非常危险。

7. 以主动学习为荣,以固步自封为耻

技术的进步实在太快,曾经有一种夸张的说法:“平均每天诞生一种革命性的、颠覆性的技术”。虽然有很多新技术,都在如此宣称,作为架构师,却必须不断地主动学习,了解,甚至在某些领域做一些初步的尝试。这样的过程,在架构师的整个职业生涯中,都无法停止。一旦产生了“固步自封”的念头,这个架构师也就“不过尔尔”了。

8. 以勇猛精进为荣,以疏忽懈怠为耻

架构师是一份困难的工作,更加重要的是:随着架构设计的完成,架构师的工作,才刚刚开始。接下来的任务,会非常琐碎,也许会更加困难。这份工作的主题是:“架构看护”尽可能保护架构,不会随着时间的推移,随着特性的增加,渐渐变得腐化。很多最初设计得相当优秀的架构,到最后变得不堪入目。说到底,还是要怪架构师没有能够坚持自己当初的决策。

如何提升架构师的自我修养?

在《中庸》里,子曰:“好学近乎知,力行近乎仁,知耻近乎勇。知斯三者,则知所以修身;知所以修身,则知所以治人;知所以治人,则知所以治天下国家矣。”

简单的翻译解释下:好学就能显得有智慧(至少能有知识),力行就能不脱离群众(因不忘本而能具备仁慈之心),知耻就能守底线(有所为有所不为之勇)。能做到这三点,就算是懂得如何提升自己的修养了。懂得如何提升修养,才能懂得如何驾驭团队。懂得如何驾驭团队,才能创作出真正伟大的,甚至风行全球的软件产品来。

这就是我理解的架构师的中庸之道,与诸位共勉吧。

(责编/ 钱曙光,关注架构和算法领域,qianshg@csdn.net)


作者简介:华为开源专家,目前主要的工作是华为的内源社区平台建设。

1997年毕业于华东师范大学,曾任盛大创新院的高级研究员、印客网的技术总监。多年来一直在编程的第一线,并以Coding为最大的乐趣。

推荐阅读
  • 对象存储与块存储、文件存储等对比
    看到一篇文档,讲对象存储,好奇,搜索文章,摘抄,学习记录!背景:传统存储在面对海量非结构化数据时,在存储、分享与容灾上面临很大的挑战,主要表现在以下几个方面:传统存储并非为非结 ... [详细]
  • ABP框架是ASP.NET Boilerplate的简称,它不仅是一个开源且文档丰富的应用程序框架,还提供了一套基于领域驱动设计(DDD)的最佳实践架构模型。本文将详细介绍ABP框架的特点、项目结构及其在Web API优先架构中的应用。 ... [详细]
  • 本文档详细介绍了服务器与应用系统迁移的策略与实施步骤。迁移不仅涉及数据的转移,还包括环境配置、应用兼容性测试等多个方面,旨在确保迁移过程的顺利进行及迁移后的系统稳定运行。 ... [详细]
  • 本文详细探讨了字符编码的发展历程,从最早的8位字节编码到现代的UNICODE和UTF8,解释了各种编码方式的原理及其在不同场景下的应用。 ... [详细]
  • 微服务架构详解及其入门指南
    本文详细介绍了微服务的基本概念、发展历程、与传统架构的区别及优势,并探讨了适合采用微服务架构的场景。此外,文章还深入分析了几个主流的微服务开发框架,特别是Spring Cloud的组成和特点。 ... [详细]
  • 远程访问用户 Kindle通过电子书实现控制
    介绍自2007年以来,亚马逊已售出数千万台Kindle,令人印象深刻。但这也意味着数以千万计的人可能会因为这些Kindle中的软件漏洞而被黑客入侵。他 ... [详细]
  • 深入解析Dubbo:使用与源码分析
    本文详细介绍了Dubbo的使用方法和源码分析,涵盖其架构设计、核心特性和调用流程。 ... [详细]
  • IOS Run loop详解
    为什么80%的码农都做不了架构师?转自http:blog.csdn.netztp800201articledetails9240913感谢作者分享Objecti ... [详细]
  • 本文通过思维导图的形式,深入解析了大型网站技术架构的核心原理与实际案例。首先,探讨了大型网站架构的演化过程,从单体应用到分布式系统的转变,以及各阶段的关键技术和挑战。接着,详细分析了常见的大型网站架构模式,包括负载均衡、缓存机制、数据库设计等,并结合具体案例进行说明。这些内容不仅有助于理解大型网站的技术实现,还能为实际项目提供宝贵的参考。 ... [详细]
  • Juval Löwy主张,每个类都应被视为服务,这并非是为了让服务无处不在,而是因为微服务是经过深思熟虑后系统分解的自然结果。在他的设计和构建的系统中,这种理念有助于提高模块化、可维护性和扩展性。通过将每个类视为独立的服务,系统能够更好地应对复杂性,实现更灵活的部署和更高的性能。 ... [详细]
  • MySQL 8.0 MGR 自动化部署与配置:DBA 和开源工具的高效解决方案
    MySQL 8.0 MGR 自动化部署与配置:DBA 和开源工具的高效解决方案 ... [详细]
  • 在CentOS 7上部署WebRTC网关Janus
    在CentOS 7上部署WebRTC网关Janus ... [详细]
  • 揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节
    揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节 ... [详细]
  • PHP中元素的计量单位是什么? ... [详细]
  • 本文深入剖析了jQuery的架构设计与实现原理。jQuery的总体结构采用了一个自执行匿名函数的形式,该函数接收`window`和`undefined`作为参数,并在内部定义了一个局部的jQuery副本,以确保其内部变量和方法不会污染全局命名空间。这种设计不仅提高了代码的封装性和安全性,还使得jQuery能够更好地与其他JavaScript库兼容。通过详细分析这一架构,读者可以更好地理解jQuery的核心机制及其高效运行的原理。 ... [详细]
author-avatar
甫士归
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有