软件架构师是什么?他们应该写代码吗?

君子不器 2017年11月13日 编程世界 1413次阅读 查看评论

 

这几年来,我发现自己常常做着“软件架构师”的工作,这让我意识到,公司很少了解软件团队的真正需求,反而倾向于依赖所谓“软件架构师”来解决问题。

随之而来的,就是因交付前产品不符合商业预期、而导致的产品架构大规模修改,但这甚至不会影响产品交付日期。毕竟,软件架构师的责任正如其名:建立宏大而优美的软件架构。软件架构师并不需要对架构实现过程负责,他们也并不想参与代码编写工作。

我记得有一回,我在团队中作为开发者,着手实现一个大型、复杂的架构。我是在开发已开始后加入团队的,并没有参与架构设计,所以没过多久,我对整个架构的设计就产生了一系列疑问,比如软件架构师打算用 MySQL 作为数据库,配合一套复杂的前端缓存程序、一些自制的库和函数,完成软件的国际化和本土化。

产品是个简单的应用程序,作用是将译文字符串用多种目标语言展示,我认为软件架构师明显杀鸡用牛刀了。

团队讨论这个问题时,我建议我们用免费轻量的现成替代品,比如 gettext,它支持几乎所有系统和主流编程语言。不幸的是,我的建议被否决了,因为软件架构师的话是神圣不可侵犯的。我意识到:

  • 这位软件架构师没有听过 gettext,也没有任何兴趣去了解它。

  • 他喜欢用“自己的方式”解决问题,就算其他方案更简单,他也不喜欢改变。开发成本、产品效率什么的,统统与他无关。

  • 如果他要去写代码,实现自己的架构设计,他肯定会意识到这个方案将问题复杂化了,坚持这么做会浪费非常多时间,然后也许会考虑修改架构。

一个不写代码的软件架构师,对于软件开发团队、产品甚至公司,会有什么影响?

安东尼·兰斯沃斯(Anthony Langsworth)在著名的《软件架构师是否应该写代码?》一文中对此进行了精辟的分析,文章开头提到了一些软件架构师的反面形象典型:

不写代码的软件架构师,有时被称为“PPT 架构师”、“宇航员架构师”、“象牙塔架构师”,他们有特殊的说服技巧,能让不懂技术的股东们觉得他们很厉害,同时把真正困难而待解决的问题交给开发者,这个现象屡见不鲜。(编注:这些名称指不写代码的软件架构师指不接地气,“特殊的说服技巧”原文为 archibabble and talkitechture,分别取前后两端为 talkybabble,“夸夸其谈的架构师”之意)

这文章同步到 LinkedIn 后也遭到了热议,人们对于“软件架构师是否应该写代码”这一问题有许多不同意见,部分意见很有意思,但很难令人信服。然而这些讨论中全都忽视了一个重要前提:具体情境。

 

准确的说,如果想要对“软件架构师是否应该写代码”得出确切结论,必须讨论这些前提:

  • 项目属于哪个行业?银行、科技、电信、广播……?

  • 公司规模多大?

  • 有现成开发团队吗?还是正在打造开发团队?

  • 开发团队规模如何?

  • 预期产出是什么?(应用程序、服务还是创新?)

咱们一个个来看——

行业

软件本身和行业无关,难道不是这样?

我为不少互联网公司服务过,它们所属行业包括在线发布、广告和社交媒体,这些行业相似且相关,这让我了解了这些行业中的先进技术、行业间有何联系、一些变化会造成什么影响以及跨行业的创新情况。

如果对当前工作行业的相关行业不能深入了解,软件架构师就不能成为这个行业的专家。我会花上一定时间了解相关行业,尝试新的东西:比如去化工行业的公司考察后,我就能思考,如果到时候需要为他们设计软件,会遇到什么问题。

但我十年的网页和移动程序开发经验有什么用呢?在设计化学流程模拟器架构时,我怎么样才能比那些有过化学行业开发经验的人做得更好?此外,化工公司大多甚至不需要软件架构师b,而是需要有计算机科学背景的化学家、化学工程师,他们更适合做这类软件开发的领头人。

同样的,音乐行业也不需要软件架构师,他们需要的是音乐家(亦是有计算机科学背景的)和软件开发商,后者并不用懂得音乐理论。Spotify 和 iTunes 并不算意外情况,它们甚至不属于音乐行业,具体业务与音乐本身无关,它们更像是科技和娱乐项目,用于传播音乐。

让我们将范围限制到科技产业,简化讨论。

公司规模

一个开发团队,需要两名软件架构师吗?你听过成功的小规模创业公司有专业的软件架构师吗?

这不是“是否需要这个角色”的问题。创业公司根本无力承担专业软件架构师的成本,每个人都身兼数职,分担不同任务,就连创始人、CEO 和 CTO 有时候都要撸起袖子来顶工。

如果说不考虑创业公司,你的公司规模有多大?几百、几千、几万人?他们都专攻同一领域吗?工作都与科技有关吗?实际上,就连 Google、Apple 和 Facebook 这样的巨头,都会有一部分工作人员职责完全不与科技相关。

我们再缩小讨论范围至“软件开发部门”,这个部门完全专注于业务的技术部分。那么,这个部门真有必要雇佣专人,来协助部门之间的沟通、收集需求、最终把握项目方向吗?

如果你真的认为,不论如何都需要一位软件架构师来完成这些任务,那你有必要恶补关于产品开发管理的基础知识

归根到底,软件架构师在大公司软件开发部门到底有什么职责呢?或者这么问:“专业的软件架构师,对于这个部门有什么贡献呢?”

下面我从团队规模的角度来为你解答。

团队规模

你的软件开发部门像小团队一样整体运转吗?还是被分割成几个团队,分别专注于不同的项目?

根据我的经历,如果任务和责任明确,软件架构师在任何软件开发团队中都会成为累赘。

“这和我的职责无关!”、“这就是我的职责,我来决定我们应该怎么做!”我已经听厌倦了这两种论调,这些论调持有者都是团队蛀虫,影响团队协作。

斯科特·W·安布勒(Scott W. Ambler)警示了这点,并总结了“象牙塔架构”的危险所在

通常“象牙塔架构”由一名或多名架构师设计而成,他们与真正的开发团队和流程相对生疏。这些貌似大牛的架构师们,会给出一系列模型用于描述架构,不明觉厉的开发者就只能乖乖就范了,因为架构师永远伟大光荣正确。

由多个小规模团队(大约 15 人或以下)组成的大型软件开发部门,与多个小规模团队并没有什么区别,每个团队都要面对待解决的问题、项目完成期限和随之而来的压力。

那么谁来为这些小团队的软件架构负责?

安布勒写道:

对于小规模团队有个较为简单的解决方案:所有人都对项目架构负责。与其他人一起设计能够让你懂得合作的必要性,而且说真的,不论一个人有多聪明,他都很难完全掌控项目架构,让团队来做效果会更好。

每个人都参与了设计,所以每个人都会更进一步了解和接受架构,而且这样做还能提高架构灵活性,当发现缺陷和问题时,开发者们会更加愿意让它作出改变。

当软件架构师一人设计出“成果”时,他会将其视为“自己的孩子”,没有人愿意听到别人批评自己的孩子,同理,架构师会抵触任何批评。而若由团队设计架构,成员们更多时候会考虑团队因素,“这不是一个人的事情”,从而乐于反思。

当软件开发部门就是一个整体时,这个策略就无效了。

团队很大,或成员地理位置很分散,这两个敏捷调整模型(Agile Scaling Model,ASM)中的因素能够影响“所有人共同设计架构”的策略,此时你应该把整体打散成几个小团队,因为“共同设计”策略要求整体协作。

有时候软件开发部门需要某种形式的整体方向和指导,以确保部门生产力用在了正确方向、以及与其他部门能够顺利沟通和协作。

在我看来,这就是少数需要软件架构师的时刻。然而,软件架构师应该代表软件团队与其他团队进行什么互动呢?或者它仅仅是个单向输送信息的角色?并非如此,软件架构师的职能不因环境而变:除了设计架构外,还要承担起促进沟通、攒写文档的责任,统一认识并作记录,起指导作用。

终于为软件架构师找到一处用武之地了!

预期产出

你的团队在设计应用程序,还是写网页?

我们已经讨论了行业、公司和团队规模,但最终我们要做的是项目本身。如果你团队唯一的“项目”仅仅是制作简单网页,只需要一点 HTML/CSS 技能,还讨论架构的话……

现成开发团队 vs. 打造开发团队

你现在的开发团队结构存在缺陷吗?你是否打算雇佣软件工程师来解决问题?

如果你目标是扩大团队,那很有可能你已经有了软件架构师的候选人,他/她是领域专家,而团队其他成员需要加强合作跟上他的步伐,领会并实现架构。“软件架构师”的名分并不重要,如果某个员工为这名分斤斤计较、特别想成为“软件架构师”时,我会考虑这个人是否适合继续留在团队中。

有句名言是:“那些没法干活的,教他们应该怎么做。”我强烈反对这一点,但具体原因这里不赘述,请移步这个博客查看。

乔·温彻斯特(Joe Winchester)把这个名言改编了一下:“能写代码的写代码,不能写的去写架构。”虽然这观点看起来充满偏见,但文中有个好例子,说明了软件架构师这角色职责错位的状况:

当项目遇到问题、项目管理者问责时,软件架构师可以把原因归咎于程序员,“嘿,我早说了,要你们应该用 BOJOX 和 NADA 2.0 ,现在出 bug 了吧。”项目管理者有了这些“原因”,就能把开发报告写得冠冕堂皇,证明团队需要一年来重写这个项目。然后管理者大可以趁着“不做就不犯错”的这段时间,将期权变现后跳槽。

乔尔·斯波斯基(Joel Spolsky)这么描述他遇到的挫折:

有时候这些聪明的思想家不知道什么时候应该止步,他们能创造荒诞、无所不包的宇宙,但,那毫无意义。

如果你正在打造一个开发团队,那么请专注于项目本身。

“自下而上”的打造团队,聪明、勤奋、有强烈学习欲望的程序员是一切的基础,让每个人对项目架构有同等发言权,不要遏制创新,“软件架构师”的名分并不重要。这样你的队伍就会变得乐观而高效率。

总结

不是所有行业都需要软件架构师,一般能遇到的大多问题都已经有解决方案了,你需要的是执行者,全栈工程师(Full stack software developer)才能完成公司目标,保证产品质量和客户体验。

不管一个人有多聪明,他都很难完全掌控项目架构。

当项目架构由整个团队设计和完善时,团队成员们会更有协作意识:乐于承担责任,接受意见和进行修改。

关注最终目标:如果团队预期产出是软件上的创新,那你应该考虑雇佣软件架构师,让他来写解决方案、指导团队。如果你公司是 B2C 平台,不要浪费时间考虑这个问题,专心做好业务。

看到这里,希望你对软件架构师的职责、价值和雇佣时机有了清晰认知,那么回到最初的问题:“软件架构师应该写代码吗?”我想用一段话来回答——

几个世纪以来,熟练的石匠、建筑熟练工、细木工、半吊子、有天赋的外行,和专业建筑师(architects)之间的界限已经越来越模糊。以文艺复兴时期的建筑为例,很多就不是由建筑师设计:布鲁内勒斯基(Brunelleschi)曾是一名画家和金匠,米开朗基罗(Michelangelo)是雕塑者,达·芬奇(Leonardo da Vinci)是画家,阿尔贝蒂(Alberti)是律师,只有布拉曼特(Bramante),作为画家,曾专业地学习过建筑学。这些人之所以被成为建筑师,仅仅是因为他们设计了著名建筑,就是这么简单。——《世界上最漂亮的房子》,加拿大建筑设计师维托尔德·雷布津斯基(Witold Rybczynski)

« 上一篇 下一篇 » 君子不器原创文章,转载请注明出处! 标签:Java程序员转载

相关日志:

博主介绍
乌云蔽月,人迹踪绝,说不出如斯寂寞。
控制面板
您好,欢迎到访网站!
  [查看权限]
站点信息
  • 文章总数:1279
  • 页面总数:2
  • 分类总数:9
  • 标签总数:61
  • 评论总数:331
标签列表
友情链接