The Myth of Architect as Chess Master

栏目: IT技术 · 发布时间: 4年前

内容简介:For software architects (especially atbigger organizations), it's not that uncommon to get a request like this from a manager or director:There's this tough problem the developers have been struggling with for weeks (performance, or scalability, or whateve

For software architects (especially atbigger organizations), it's not that uncommon to get a request like this from a manager or director:

There's this tough problem the developers have been struggling with for weeks (performance, or scalability, or whatever), so can you quickly look at it and show them the best practice, quick fix, etc. that solves it all?

Reasonable ask? No, not really. The expectation is that the architect is a chess master . It's just like that movie we've all seen. There's the young or disheveled or [insert surprising adjective] savant who, walking through central park mid-dialogue with someone else, glances for a nano-second at a pair playing chess and declares "bishop to queen 4, check mate" and then keeps walking. Minds blown.

The Myth of Architect as Chess Master

But why shouldn't an architect be able to size things up as quickly as a chess master? Both an architect and a chess master have accumulated thousands of hours of experience in their disciplines. Both are analyzing current states of a "board" and then evaluating the trade-offs of different next moves or options.

The difference is that chess masters are always playing the exact same game . Rooks always go forward-backward and side-to-side. Bishops always move on diagonals. And because the rules don't ever change, it's easier to take a mental snapshot of a board and instantly pattern match back to some other past experience - e.g. "this is exactly like the game I played/studied four months ago".

Any given software system, on the other hand, may look the same as countless others you've worked on in the past - I mean, hey, it's all ifs and elses, classes and objects, REST and SOAP calls, etc. - but just a little bit below the surface we realize the pieces and the rules are very different. In my system the rook can jump the first 2 squares but in yours the queen has 3 lives. Each system we visit has different intricacies and rules we must learn anew.

This immense variability and complexity is baked into even the simplest software system - it's in the business domain, in the frameworks/techologies used, and in the implementation itself - and so it takes time to grok all these nuances and details before we can build the right mental picture that allows us to reason about it effectively. Even for those with years of experience this is true. Sure there are common patterns, styles, tools, specifications, etc. that, if you know them, can help in terms of more quickly sizing up a system, but almost never do these alone allow you to pull off that type of chess savant "mate in one" mastery. Real-world software solutions take time. Architecture takes time.

This is why I think it's important to think about software architecture as a process and not a destination . Being an architect (or playing the role of an architect) doesn't mean simply divining the "right" solution or recommendation and handing it off to the developers. Anyone can whip up a bunch of boxes and lines that seem plausible, but do they really apply to the game of "chess" you're playing now, or the one from your past project or from that popular blog post? To truly know the right next "move" requires first understanding the rules of the game you're in. What are the business drivers, risks, technical constraints, legacy components, integrations, possible options, trade-offs, and so on. These are the details that take time to identify, clarify, and understand, and they are subtly (and sometimes not so subtly) different from project to project and organization to organization.

In my opinion, the expectation for the architect should be to setup the framework or process by which good architectural "moves" are made (Michael Keeling describes this well in Design It ). Thinking an architect is going to stroll into a meeting and find a check mate lurking in plain site is sadly unrealistic.


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

重来2

重来2

[美] 贾森·弗里德、[美] 戴维·海涅迈尔·汉森 / 苏西 / 中信出版社 / 2014-4-8 / 39.00元

“不再需要办公室”,这不仅仅是未来才有的事——它已经发生了。现在,轮到你迈开脚步,跟上时代的步伐了。 上百万的员工和成千上万的企业已经发现了远程工作的乐趣和好处。然而,远程工作方式还没有成为常见的选择。事实上,远程工作的技术手段都已齐备。还没有升级换代的,是人们的思想。 这本书的目的就是帮你把想法升级换代。作者会向你展示远程工作的诸多好处:可以找到最优秀的人才,从摧残灵魂的通勤路上解脱......一起来看看 《重来2》 这本书的介绍吧!

URL 编码/解码
URL 编码/解码

URL 编码/解码

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具