读《Software Systems Architecture》（13）—— Creating the Architectural Description

🤔☕️🤔☕️🤔

• 读《Software Systems Architecture》（13）—— Creating the Architectural Description

• 📖：架构描述

  🤔：这不就是文档嘛，干嘛非得说成是架构描述，故弄高级嘛？假设就是文档，那么针对文档，问出的第一个问题就是，谁是这个文档的读者？不是所有文档都得读，我也不想读所有文档。其实，我更想不读任何文档，这可能嘛？给自己设定了个好问题，自己作为码农，所谓 Show Me The Code，为啥还要对文档心存幻想？或者，反过来问自己，何时会想念文档？当然抱怨的时候不算。细想起来，典型情况有两种，当第一次接触时，当第 N 次被问起时。所谓第一次接触，就是字面意思的第一次，别多想。这时要文档，期望看到的是待接触对象的概览，也就是期望有个整体把握。反过来说，代码最大的问题，也在于此，虽然什么都在代码里，但是直接接触代码，就不容易得到整体的把握感。如此看来，第一次的文档需求，合情又合理，同时也告诉自己，未来写文档的时候，必须记得因第一次而打开文档的读者。那所谓的被问烦，不就是问起就要翻代码，仔细看翻这个词就发现，它是线性展开的过程。如果一张图，一个维度表达过程，也就是翻代码的过程，另一个维度表达对象之间的层次关系，那得提升多少表达力，又能让多少烦人的问题自动消失。所以，为了别再烦我，也为了多出更多的表达维度，赶紧的，任何时候，都顺手把时序图画下来，下次再问起，先看文档，不懂再说。原来文档有这样的妙处。不过，刚不是在说，为啥叫架构描述，而不叫文档呢？暂时没有好的答案，留着继续思考。

• 📖：架构描述需要所谓的尽量到位（sufficiency），一方面指信息量足够，另一方面更是要突出，那些已经被降低的风险，和那些难以改变的决定。

  🤔：看文档，最毛的心态，就是看完啥都说了，可是心里还特别毛。原来是我担心的始终没有安放之处。我担心出问题咋办，所谓出问题，不就是容易出问题的点，也就是高风险点。如果告诉我，哪些风险已经在可控范围内，至少已经在关注范围内，那就是给我的毛心加了点肥皂泡，稍微顺滑点。我担心有些决定做下去，再也改不了，或者要极大代价才能修改。那我不就是在毛到底哪些决定会有这样的磐石般后果。如果告诉我，就这些硬石头，虽然硬但不臭，那就更是给我的毛心注入润滑油，无比顺畅。

    —— By 术子米德 @2022.05.25