Gergely Orosz 文章翻译-软件架构被高估，简明设计被低估
原文链接：《Software Architecture is Overrated, Clear and Simple Design is Underrated》
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2022-01-10
郭东白博士《关于中台的思考和尝试》
FROM：《关于中台的思考和尝试》 围绕中台的争议非常多，但是往往争议的原因是连中台这个概念都完全没有达成共识，可以说是毫无意义的争吵。在 12 月 20 日由极客邦科技举办的 QCon 全球软件开发大会 2020（上海站）上，车好多 CTO 郭东白博士发表了主题演讲《从中台技术谈架构师的独立思考能力》。由于演讲时间有限， 关于中台的思考没办法讲得非常透彻，本文是对演讲的补充，期望能与大家形成思想碰撞。识别文末二维码，可免费下载郭东白博士的主题演讲PPT。 中台的定义 我们的讨论先从定义中台这个概念开始。 定义中台我认为可以有两个角度， 一个是从中台本身的价值和出发点来： 中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合；另一个定义从中台的相对定位来：前台是面向终端用户的一组业务能力，业务中台是对前台应用的抽象，提供多个前台业务之间共享的业务逻辑、数据和计算能力。 我想特别强调这个定义是相对中性的， 我们能够通过这个定义区分什么东西是中台，什么不是中台。有的中台定义严格来说不是定义， 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略...
2020-10-11
数据密集型应用系统设计 - Designing Data Intensive Applications
数据密集（Data-Intensive）与计算密集（Compute-Intensive）是当今两大负载类型。前者以大数据为代表，后者以深度学习和 HPC 为主要代表。 谨以本书献给那些追逐梦想的人们。 [另一个电子版本。][1] 前言 数据密集型应用要处理的瓶颈往往是数据的规模、数据的复杂度和数据产生与变化的速率；与之对应的是计算密集型应用，CPU 往往成为其瓶颈。 本书是关于数据处理系统及其相关技术的（NoSQL、消息队列、缓存、搜索引擎、批处理和流处理框架）。 每一种技术都基于一定的设计理念，而且只适用于特定的场景。 不要过度优化。 数据系统基础 可靠、可扩展与可维护的应用系统 现在的典型系统架构已经很明确了，因为业界已经有成功的案例，对这些组件做了很好的抽象，我们只要做好拿来主义就行了。 可靠性（Reliability） fault tolerance 和 resilience 是系统的容错的体现。 硬件故障 对于大型 IDC，即使磁盘的 MTTF 很高，磁盘数量大了以后，每天发生磁盘损坏也是正常的事情。 硬件容错的方案是制造冗余（冗余磁盘、冗余电源）。 软件容错是第二种方...
2018-11-28
正交性
所谓正交性（orthogonal 意为正交的），就是设计的维度与其他维度完全隔离，一个正交的设计/值域设计，其变化绝不会受其他正交维度影响，也不会影响其他正交维度。 我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。 我们可以把问题域切分清楚。问题域之间完全不相互干涉（注意跨问题域问题）。 我们可以把变量、字段、列设计成正交的。这样不同业务场景下，列之间的赋值不会相互覆盖。
2021-02-10
《恰如其分的软件架构》
前言 这两周集中时间间歇性读完了《恰如其分的软件架构》这本书。这本书讲的是架构方法，架构方法是一种思维模型（mind set），这种思维模型叫作“风险驱动模型”。 这本书经我们团队的架构师推荐，列在我们团队的集体书目里很久了。但真正去读它、读完它的人又很少。究其原因，还是这本书的内容以谈概念为主，虽然书中举的例子非常生动，仍然始终无法摆脱“为了谈概念而举玩具例子”的问题-这几乎是所有架构书的通病。似乎正统的架构书籍都不可避免地举一些传统行业或者经典软件（比如很多书籍都会反复出现在“xxx 播放器”）的例子。这些软件架构非常经典，可以只用一些小的组件、场景，就讲清楚典型的组件、模式和架构风格的用处。但没有很深的工程/架构经验的读者读这些书的时候，仿佛重新回到了抄书和念书的大学课堂，对于脱离现实的例子只会产生“左耳进右耳出”的感觉。能够温故而知新，是一本书经典化的特征。而能够阅读非入门级的纯理论书籍，则是一个程序员的认知能力和经验达到了一定程度的特征。我读这本书里很多细节还是很痛苦，证明我还是对于形式化的符号（symbol）、记法（notion）还不是很熟悉，而且对于书中运用的问题解...
2022-03-11
面向好的架构编程
前言 本文是《架构随笔》系列的第五篇，也是它的收官之作。 架构的定义 架构是一个界定不清的东西，我们很难讲清楚哪些东西是架构，哪些东西不是架构。但软件行业里其实人人都在搞架构，软件设计就是架构本身。 架构这个词出现得很早，有些人认为是 NASA（也可能是NATO） 发明的。最早的架构定义就是描述软件的结构而已，但现在已经没有多少人谈论他们定义的“软件架构”了。工程师很难以克制描述复杂结构的原始冲动，但描述复杂结构的普世标准并不存在。大家常见的各种定义，翻来覆去地重新讲着“软件架构是软件结构的顶层设计或者抽象设计”之类的话。即使是这种软件架构的定义，也并不为所有人都接受。汗牛充栋的架构书籍里有各种各样的观点，有的进一步把软件架构视作一堆组件和交互的设计，有的则把软件架构视作架构师主观意图的体现。把自己当作架构师的人们，着迷于把软件里的“不变与抽象的部分”和“易变与具体的部分”分离出来，把前者当作架构。架构师们是如此地热衷于做这样一件事，以至于有些人认为架构设计好了就解决了基本问题，设计不好通常是因为架构不好。于是很多人开始刻舟求剑：从某某颗粒度开始的设计应该叫概要设计，从某某颗粒度...
2022-01-17
如何成为一名优秀的架构师
成为一个架构师：为了这一刻，你准备了多久？ 架构师的关注点：顶层设计、长期视角。 寿命：数据 > 代码（特指业务逻辑）> 技术（特指业务逻辑的载体） 不是传道受业，而是观点分享。 架构师的几种 profile：有架构能力、以架构为生也是一种架构师。 长期战略：对于任何一家公司，架构设计一定是必要的，而且需要自行解决。架构师的职责是保证组织拥有正确的设计，控制复杂度。 架构师的关键特质： 目标正确：限制条件和目标价值产生理解偏差。是架构师最常见的问题。 能力满足：为组织带来更好的外部适应性。 持续减熵：好架构等于发现、规划和演化。 思考深度和实战经验最重要：这是任何的书本都不能带给我们的。包容、求真、良知、勇气。 有没有德？考虑组织长期利益（基于良知做判断）。 有没有勇气？承担责任，决定命运。 有没有眼光？是否擅于思考？ 独立、理性、有深度的思考。长期感召力，来自于良知、成功、经验和勇气。 从复盘中学习。 郭东白.pdf
