Frank the Obscure 无名的弗兰克

人人都是架构师


人人都是架构师

  • 架构是研究如何理性发现, 分析, 解决问题的学科
  • 为什么要从架构的角度思考?
  • 架构的技巧与艺术

架构是研究如何理性发现, 分析, 解决问题的学科

架构师的英文很有意思, 和建筑师共用了一个词 architect 1.

而从某些角度来看, 架构师很多时候面临的问题比建筑师更难: 从来不会有人要求建筑师先盖个能住 100 人的酒店, 然后直接原地膨胀到 1000, 10000, 甚至 1000000 人; 也不会有人要求建筑师盖的酒店中今天住人, 明天住牛, 后天住鸡鸭.

但是架构师们不幸(而又幸运地)在数字世界承接了这样一份有些荒诞的使命, 并切实开始理性地研究为什么, 做什么, 怎么做. 架构师们带领团队一起在现实中盖出了很多”不可能的建筑”. 并且还将有更多这样的项目出现.

当人类的理性之光和发现、分析、解决问题相遇, 架构师–这份充满了迷茫、困惑、挫折、挑战、责任–但又伴随着喜悦、乐趣、荣耀与梦想的事业, 就出现在了人类的历史之中.

为什么要从架构的角度思考?

数字世界相对于现实世界, 最大的优势或许在于其试错成本低, 反馈循环快. 因此架构师们以极快的速度实现并验证他们的想法, 在这个过程中也积累了大量的实际经验和最佳实践. 这些经验和实践不应该只是数字世界的宝贵财富, 更应该被当做全人类的宝贵财富2.

当我们仔细想想, 会发现架构师的工作和我们对自己人生中要做的事情的期待, 有惊人的相似: 我们总希望自己在不增加资源(或者极少增加资源)的投入下越做越好, 越做越多; 我们总希望自己能够样样精通, 不断进入不熟悉的领域. 因此, 有两个结论: 1. 这样的想法很多时候是不切实际的; 2. 架构中的经验和最佳实践也许会和人生规划同构. 再推而广之, 也许对于一个组织甚至全人类来看, 架构同样意味着相当宏大的发展机遇与挑战. (或许, 玩文明也是这样一种架构的演练 XD)

架构的科学与艺术

架构与其说是一门科学, 不如说是一门艺术. 优秀的架构如同优秀的艺术品, 不需要过多理性的解释, 有时更像是自然对人类的馈赠.

然而艺术毕竟是可遇而不可求的, 为了先达到温饱水平, 或许我们可以先从科学的角度来聊聊架构3.

  • 架构设计的关键在于思考系统之中, 什么是变的, 什么是不变的. 需求的稳定点, 往往是系统的核心价值点; 而需求的变化点, 则往往需要相应去做开放性设计4.
    • 从而构建足够合理且稳定的核心架构与关键数据结构, 避免在根基上反复设计.
    • 而上面的枝叶, 即使(暂时)不是最优解, 重新设计的成本也非常可控.
    • 一个典型的例子是 Git, 如Linus 在一次访谈中所说, Git 的成功之处就在于有一个足够稳定和优秀的数据结构, 非常精确地反映了人们对于版本管理软件的根本需求.
    • 这时候编写代码时, 你会发现一切都是顺理成章的. 反之, 如果编写代码时候总要使用一些特殊的技巧, 那通常不是一个好兆头. 也许你应该看看自己的数据结构(或者是需求,XD)是不是有根本问题5.
  • 提出问题是发现问题的关键, 发现问题是解决问题的关键.
  • 提出问题之后, 发现和解决问题的关键在于 profiling the system.
    • 80-20 原则对于架构优化往往很有帮助, 解决性能瓶颈的一个问题往往能带来成倍的提升.
    • 一个趁手的 profiling 工具非常, 非常, 非常重要.
    • 只打 print 看字虽然很方便, 但对于复杂系统往往是不够的. 人类是视觉动物, 架构设计和调优必须要符合人类的天性. 要有优秀的可视化框架.
    • 当然, 有了想法, 还要有优秀的测试框架, 才能使 grid search 等简单粗暴但经常很有效的调优成为可能.
  • 很多时候, 对于小规模项目, Jupyter notebook 这种所见即所得的编辑-测试模式有相当出彩的表现. 其成功原因就在于能够极其方便地构建快速的coding-running-profiling反馈循环. 相反, 很多大型项目推进缓慢的原因或许就在于花费太多时间在 build, 太少时间在 test & profile.
  • 反过来想, 总是反过来想: 当我们想不到应该怎么做的时候, 或许可以想想一定不能怎么做.
    • 很多时候我们的架构不需要得 100 分(因为事实上你永远不能知道到底自己是多少分, 现实世界之中, 并没有那么多的标准答案).
    • 但绝大部分时候, 我们有足够能力发现, 很多架构绝对不会及格. 如果能排除掉这些错误路线, 我们至少是在能及格的路线上前进. 这对于大部分时间有限的项目来说, 已经足够好了. 不妨有了初步的结果再做调优.

最后, 我想用芒格的一句话与大家共勉: “也许所有教育最有价值的结果是, 当你不得不完成一件事情的时候, 不管你是否喜欢它, 你都有能力去完成这项必须的任务. 这是每个人应该学的第一课, 然而, 无论一个人多早接受教育, 这可能是他彻底学到的最后一课”. 在最终解决问题之前, 一切架构都是纸上谈兵.

架构亦人生, 永远都是进行时. gl hf!


  1. 事实上, 由于下文提到的同构和隐喻原因, 也许这篇文章用英文来写会更好. 

  2. 这里的思考牵扯到认知与元认知的关系, 本文不再赘述. 或许, 这是人类完成下一次进化的关键之一. 

  3. 下面的讨论中, 我特意混杂了软件工程和生活观点, 有两方面原因: 1. 二者很多时候是同构的; 2. 生活中的问题很多时候并不会完全属于一个学科, 它们必须要用一种超越学科的综合式的思维来理解和解决. 拿着锤子就看什么都是钉子的想法往往是不切实际的. 

  4. 来自七牛云许式伟的一份讲稿, 极客时间上可以订阅许式伟的架构课

  5. 对于一个组织来说, 系统的稳定点, 核心架构和数据结构又都是什么呢? 或许就是组织的使命, 原则与价值观. 因此, 我也蛮喜欢 principle 这本书. 


Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

上一篇 《见识》笔记

Comments