讨论软件架构的30个共同原则

想象一下飞越架构评论。一位建筑师走进来,看着,通过他的双筒望远镜凝视着他。他提供的评论通常过于通用或脱离背景。评论经常遭到震耳欲聋的沉默或激动人心的争论。如果有的话,他们很少帮助任何人。每个程序员都害怕它; 每个建筑师也都害怕它。

据说,作为软件架构师,人们应该像园丁一样思考而不是指挥官。前者塑造,策划并去除杂草,而后者定义和指示。建筑师应该策划而不是指挥,塑造而不是定义,并煽动讨论而不是标签。但是,如何让它发挥作用?

在WSO2,我已经完成了八年多的架构评审。WSO2拥有广泛的产品组合,包括众所周知的WSO2 ESBWSO2 API ManagerWSO2 SP。在过去的八年中,我们对许多产品和功能进行了辩论,设计,改进和重新设计。

我们设计过程的一个关键部分是架构不是由架构师完成的。我们没有一组建筑师负责管理架构蓝图,而其他人则去实施它。相反,设计由编写代码的团队完成。建筑师修复,抱怨,策划和改进设计。我们有一个建筑团队,但他们是导游和守门人,而不是独裁者。

Gregor Hohpe在这次演讲中精美地捕捉到了这个想法。

是真的。在短期内,规定架构更快,甚至可能更便宜。但是,从长远来看,我们通过让他们自己思考,让他们发展架构,有时让他们犯错误来建立更好的团队。当我们专注于团队时,他们会随着时间的推移而变得更好。执行起来要容易得多,因为架构首先是团队的想法。

然而,建筑评论也存在缺陷。保罗(@pzfreo)过去常常通过建筑师来称呼这个驱动器,其中建筑师走进来,倾听,发表评论并继续前进。作为一名建筑师,它更容易看起来,抱怨并将设计分开。如果你不小心,你可能会让团队感到困惑,不确定什么是正确的做法。

我们通过列出共享体系结构主体来解决此问题。这些是每个人都同意的原则。建筑师提出反馈说,由于校长X,这是不好的。原则指导我们并使我们的讨论根深蒂固。他们还避免了永远持续的哲学战争。最后,如果设计师从未听说过这个原理,那么他很容易学习。

以下是其中一些原则。有些是众所周知的,而有些则是我们选择的方式。

基本

原则1: KISS(保持简单,愚蠢)和“一切尽可能简单,但不简单。”这个想法是使用最简单的解决方案来完成工作。

原则2:YAGNI(你不需要它) -在需要之前不要构建它。

原则3:爬行,走路,跑步。换句话说,让它发挥作用,让它更好,让它变得更好。迭代开发 - 做敏捷,迭代开发。对于每个功能,创建里程碑(最多2周)并迭代。

原则4:构建稳定,高质量产品的唯一方法是通过自动化测试。通过自动化测试发挥创意; 一切都可以自动化!在设计时考虑一下。

原则5:始终考虑投资回报率(ROI)并将最多的注意力放在产生最大影响上。

原则6:了解您的用户并相应地平衡您的努力。对于大多数产品,将有数千个最终用户,20个扩展产品的开发人员和100个设置它的DevOp个人。例如,不要花费数月的时间来构建一个不太可能使用它的DevOp用户界面(他们喜欢脚本!)。这是原则5的特例。

原则7:尽可能独立地设计和测试功能。在设计时考虑一下。从长远来看,它将节省很多麻烦,否则,在构建所有内容之前,您无法测试系统。此外,根据这一原则,您的版本将更加顺畅。

原则8:留意“谷歌嫉妒”。我们都喜欢闪亮的设计。您可以轻松地将功能和解决方案引入您永远不需要的架构中。

选择功能

原则9:不可能充分考虑用户如何使用我们的产品。所以拥抱MVP(最小可行产品)。我们的想法是找出一些用例,只做一些支持这些用例的功能,运送产品,并根据反馈和经验塑造未来的产品。

原则10:尽可能少的功能; 如有疑问,请将其删除。许多功能从未使用过; 也许你会留下一个扩展点。

原则11:等待有人要求(例如,对于不是交易破坏者的功能,请等到需要它)。

原则12:如果他要求弄乱大局,有勇气与客户作斗争。找出更大的图片,并尝试找到另一种方法来处理问题。请记住亨利福特的话:“如果我问过人们他们想要什么,他们就会说'马更快。'”而且,请记住你是专家。你应该领导。做正确的事情是领导者的工作,而不是流行的事情。用户以后会感谢你。

服务器设计和并发

原则13:了解服务器的工作方式,从硬件到操作系统,再到编程语言。优化IO调用的数量是迈向最佳架构的第一指导。

原则14:了解Amdhal关于同步的定律。线程之间共享的可变数据会降低程序的速度。如果可以,请使用并发数据结构,并且仅在必要时使用同步。尝试尽可能少地抓住锁。如果您计划在持有锁定时阻止,请确保您知道自己在做什么。如果它可以破坏,它会。

原则15:如果您的设计是非阻塞的事件驱动架构,则永远不要阻塞线程或从这些线程执行IO。如果这样做,系统将像骡子一样慢。

分布式系统

原则16:无状态系统具有可扩展性和直接性。尽可能了解并使用Shared Nothing Architecture

原则17:除非您在客户端和服务器中都控制代码,否则完全一旦消息传递,无论失败,都很难。尝试将您的系统设计得更少(使用原则18)。知道大多数承诺一次交付的系统会在某个地方偷工减料。

原则18:尽可能将操作实施为幂等操作。然后它很容易恢复,你可以至少一次交付。

原则19:了解CAP定理。扩展交易很难。尽可能使用补偿。基于RDBMS的事务不会扩展。

原则20:分布式共识不扩展,也不进行组通信,也不进行群集范围内的可靠消息传递。在一个美好的一天中,任一个的最大节点限制大约是八个节点。

原则21:您永远不能隐藏分布式系统中的延迟和故障(请参阅分布式计算的谬误解释)。

用户体验

原则22:了解您的用户并了解他们的目标:他是新手,专家还是临时用户?他对计算机科学了解多少?极客喜欢扩展点,像样本和脚本的开发人员,像UI这样的普通人。

原则23: 最好的产品不需要手册。它的用途是不言而喻的。

原则24:如果您无法在两个选项之间做出决定,请不要通过将其作为配置选项来传递问题。您正在为用户和解决方案架构师努力工作。如果他们对系统的工作方式了解甚少,那么他们又如何决定呢?最好的选择是找到一个每次都有效的选择; 下一个最好的是自动做出选择,第三个最好是添加配置参数并设置合理的默认值。

原则25:始终具有合理的配置默认值。

原则26:设计不良的配置会造成很多混乱。始终记录配置的一些示例值。

原则27:根据用户可以回答的问题配置值,而无需计算设置值(例如,不要求最大缓存条目的数量 - 而是要求最大内存应该用于缓存)

原则28:如果看到未知配置,则抛出错误。永远不要忽视它。调试时,无提示配置错误是许多丢失时间的来源。

难题

原则29:梦想新语言很容易,但要做到正确是非常困难的。除非团队可以花费至少十个人年,否则尽量不要这样做。如果您仍然不确定,请阅读有关语言设计的五个问题

原则30:可组合的拖放UI很难,除非团队准备投入10个人年,否则不要启动。

最后,让我谈谈我随着时间的推移改变主意的事情。在理想的世界中,平台必须由正交组件组成 - 每个组件处理一个方面(例如,安全性,消息传递,注册,调解,分析)。使用这些功能构建的系统将是最佳的。

不幸的是,很难到达那个州。它很难留在那里。严格执行这一点可能是一个错误,特别是在新功能的初始状态,其中简单的功能可以级联到大的变化,因为我们试图使一切正交。有时我们发现我们添加的功能毕竟没用,然后所有额外的工作都没有用。最后,如果这导致多个团队之间的协商,该功能可能永远不会完成。

事后来看,现在我愿意在尝试删除它时带来重复,导致重大的复杂性。治愈可能比疾病更糟。

结论

作为建筑师,人们应该像园丁一样思考,塑造,策划和清除杂草,而不是定义和建造。你应该策划而不是指挥,塑造而不是定义,并煽动讨论而不是标签。 虽然短期内可能会更便宜,更容易决定架构,但从长远来看,指导并让团队找到自己的方式会带来好处。

如果你不小心,建筑飞行更容易,设计师只告诉他的架构是错误的,但不是为什么它是错的。避免这种情况的一种方法是拥有一套普遍接受的原则,这些原则成为讨论的锚点,也是新兴建筑师的学习路径。

原文标题《30 Shared Principles for Discussing Software Architectures》

作者:Srinath Perera

译者:February

不代表云加社区观点,更多详情请查看原文链接

原文链接:https://dzone.com/articles/30-shared-principles-for-discussing-software-archi-1

原文作者:Srinath Perera

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ThoughtWorks

技术雷达第十九期正式发布——用百余个条目更新你的技能图谱!

ThoughtWorks每年都会出品两期技术雷达,这是一份关于技术趋势的报告,由ThoughtWorks 技术战略委员会(TAB)经由多番正式讨论给出,它以独特...

831
来自专栏ThoughtWorks

编程的精进之法|洞见

仝健 ThoughtWorks 编程,众所周知被定义为知识工作。所有的知识工作,从业者和门外汉都喜欢把它神秘化,将整个过程以不可知论的风格来解释。理由往...

3627
来自专栏跨界架构师

如何一步一步用DDD设计一个电商网站(一)—— 先理解核心概念

    DDD(领域驱动设计)的一些介绍网上资料很多,这里就不继续描述了。自己使用领域驱动设计摸滚打爬也有2年多的时间,出于对知识的总结和分享,也是对自我理解的...

1692
来自专栏美团技术团队

从Google白皮书看企业安全最佳实践

前不久Google发布了一份安全方面的白皮书Google Infrastructure Security Design Overview,直译的版本可以参考“网...

5085
来自专栏喔家ArchiSelf

IoT中的高音质音频设计

音频是许多物联网应用不可或缺的组成部分, 包括消费品(如扬声器、耳机、可穿戴设备),医疗设备(如助听器),自动化工业控制应用、娱乐系统和汽车的信息娱乐设备等。

1224
来自专栏鹅厂网事

5.0V—基于SDN的腾讯次世代数据中心网络架构

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

4059
来自专栏互联网杂技

3D交互设计会是这个样子?

现在,VR和MR已经越来越热门了(影视剧里已经出现的太多了,比如《黑镜》),但现实是,我们对于虚拟交互的认知还是仅限于酷炫的特效,真正第一次成系统并实用的交互模...

3697
来自专栏云计算D1net

如何制定云计算方案:以应用丈量已知改变

定义云计算的说法有很多,在此我们从狭、广两层来简单阐述:“狭义云计算”指IT基础设施的交付和使用模式,是通过网络以按需、易扩展的方式获得所需资源。而“广义云计算...

2739
来自专栏刘望舒

浅谈Android进阶之路

过去十年是移动互联网蓬勃发展的黄金期,相信每个人也都享受到了移动互联网红利,在此期间,移动互联网经历了曙光期、成长期、成熟期、现在来说已经进入饱和期。依然记得在...

1412
来自专栏Sign

月千之夜

这个是2012年做的一个游戏。 ======== 主角的控制方式: 右键移动, 按Q键角色会朝鼠标方向冲刺,冲刺位移距离大,但是冲刺过程不是无敌的,且伤害一般...

34111

扫码关注云+社区

领取腾讯云代金券