原文:Software Architecture is Overrated, Clear and Simple Design is Underrated

今天读了「软件架构被高估,清晰简单的设计被低估」,获得了一些关于架构模式和简单的系统设计之间追求平衡的感觉。

First, none of these designs used any of the standard software architecture planning tools.

这些设计都没有使用任何标准软件体系结构规划工具。没有使用UML,也没有4+1的视图架构模型(4+1),也没有架构决策记录(ADR),也没有用C4(Context,Container,Component,Code)模型来可视化软件架构(C4 Model),也没有用依赖图。创建了大量的图表,但是都没有遵循任何明确的规则。

Second, there were no architects on the teams that owned the design.

设计了软件架构的团队却没有一个架构师。没有IT架构师,也没有企业架构师。对于所有项目,都需要有经验丰富的工程师参与进来。但是,没有一个能挑起架构或者设计的大梁。当这些经验丰富的开发者开始了设计,竟然需要最初级的团队成员参与其中,通常挑战决定并讨论提供的其他替代方案。

Third, we had practically no references to the common architecture patterns and other jargon referenced in common software architecture literature.

我们几乎没有参考通用软件体系架构模式,也没有引用其他通用软件体系架构文献中的术语。

Martin Fowler's architecture guide

也没有提及微服务,无服务架构,应用边界,事件驱动架构等等。

科技公司和创业公司中的软件设计

Start with the business problem

解决什么问题?创建什么产品,为什么?怎么样算成功了?

Brainstorm the approach

用多个会议,集思广益。保持头脑风暴尽可能小。从高级别开始,逐步下降到较低级别。

Whiteboard your approach

汇集所有的提议。能在白板上清晰的解释应用的架构设计,从高层开始,越深越好。如果不能说清楚,需要花更多的工作在细节上。

Write it up via simple documentation with simple diagrams

基于在白板上的解释通过简单的文档和图标写下来。能让初级的开发能看懂这是什么。

Undervalued Software Engineering Skills: Writing Well

Talk about tradeoffs and alternatives

说明权衡和替代方案。好的软件设计和好的架构都是要做出正确的权衡。

设计本身不分好坏,它们取决于上下文和目标。

这个提议的优点和缺点。

Circulate the design document within the team/organization and get feedback

在团队或组织的范围内传播设计文档,并或者反馈。

鼓励询问问题和提供替代方案。

如果需要,在限制的时间内讨论反馈和采用它。

在现场解决反馈。

Scaling Engineering Teams via Writing Things Down and Sharing - aka RFCs -

后端文档模板:

  • List of approvers?
  • 摘要 - 是什么项目
  • 架构调整
  • 服务级别协议
  • 服务依赖
  • 负载和性能测试
  • 关于多数据中心
  • 安全考虑
  • 测试和首次发布
  • 指标和监控
  • 客户支持注意事项

简单、少术语软件设计高于架构模式

The goal of designing a system should be simplicity

越简单的系统,越容易理解,越容易找问题,也越容易实现。

the least experienced person should be able to understand things equally clearly.

避免使用术语(行话),保证最没有经验的那个人都能清楚地理解。

Clean design is similar to clean code: it's easy to read and easy to comprehend

干净代码的特征是:单一责任,明确命名和易于理解的约定。这些原则同样适用于清晰的架构。

架构模式的作用是什么

它与代码设计模式相类似。但设计模式对于我成为更好的程序员的影响要小于从其他工程师那得到的反馈。

模式的好处:帮助缩短和别人的讨论,让别人和你一样的方式来理解。

但是架构模式不是目标,也不能替代简单的系统设计。不应该为了使用一种或多种模式,而把他们当做锤子,到处找钉子。

Architecture patterns are tools that came after the solution was solved, in hopes of making the lives of others easier

架构设计是诞生在工程师发现了一些场景的类似设计选择,并且实现也很相似。

As an engineer, your goal should be more about solving solutions and learning through them rather than picking a shiny architecture pattern, in hopes that that will solve your problem.

作为一名工程师,你的目标应该是更多地解决问题,并通过它们进行学习,而不是选择闪亮的设计模式。

更好地设计系统

Pull over a teammate and whiteboard your design approach

跟队友沟通,让他们理解,并给予反馈

Write up your design in a simple document and share it with your team, asking for feedback.

写一份简单的设计文档,在团队中分享,询问反馈。

邀请别人添加他们的想法和问题。

Design it two different ways and contrast the two designs

架构设计不是非黑即白的,找到第二种可以实现的设计,然后对比两个方案,解释为什么这个比另一个更好。

Be explicit about tradeoffs

明确做出的权衡,为什么这么决定,以及已经优化了什么。

清楚已存在的限制,并加到文档描述中

Review other's designs. Do it better

不要成为单向的观察者。

而是要:

对不清晰的地方提出问题

询问关于他们考虑过得替代方案有哪些

询问他们采取了什么权衡,假设了什么约束

提出可能更简单的替代方案,即时不是更好的,询问他们对于你的建议的想法

The best software design is simple and easy to understand