9年当上架构师，我的很多想法变了( 二 ) 作者|TagoFabic译者|刘志勇审校

步入架构决策记录时代：为什么ADR受到我们工程师的青睐？因为它为工程师提供了一个工具，使他们能够尽职地考虑决策的后果，并就组织中不同的专业领域进行有价值的对话。这使工程师们可以清楚地说明他们是怎样做决定的，比如他们探索了什么，却又为什么最终认为这并不是最佳的前进方式等等。
在我们采用ADR的初期，每一条记录几乎都是一件大事：有人将提出将ADR进行面对面的讨论，由20多名工程师组成的小组就细节进行讨论和辩论，我们发现自己在整个会议的一个小时里都在讨论一条记录。我们知道这种方法不会变得规模化，因此我们转向RFC类型的、代码审查式的审查，而且这样做看起来更好。
像所有其它事情一样，我们也在不断地调整这一过程。由于架构决策的结果，我们不希望让ADR成为实际交付的瓶颈，因此我们就拉取请求（PullRequests）中+1的最低数量达成了共识。就是说， ADR不寻求批准，而是针对不同课题做有效讨论。
有一点提示：偶尔， ADR编写者可能会因为在决策过程中添加一些并不真正需要的信息而使记录过长，那么可以设定一个预期，即ADR不是一个程序规范而是一份指南（也不是标准文档）。
在我看来，没有什么是天生不好的决定。只有不彻底、不够充分的决定。
下面罗列一些有关ADR的优秀参考资料：
来自Cognitect的《记录架构决策》（DOCUMENTINGARCHITECTUREDECISIONS）
来自BetterProgramming的《一款简单而强大的工具来记录你的架构决策》（ASimplebutPowerfulTooltoRecordYourArchitecturalDecisions）——他们称之为LADR（LightweightADR ，轻量级ADR），但是我们使用的格式类似。
《软件架构基础》（FundamentalsofSoftwareArchitecture）一书也有一个关于架构决策记录的好章节。
3
“这要视具体情况来看”
试想还是初级开发者的我要是穿越到现在，从现在的我寻求一些关于解决方案的意见，而现在的我会总说“这要视具体情况来看” ，那年轻的我肯定对此会翻白眼，哈哈。
不过这是事实，但你接触到的解决用户问题的各种方案和方法越多，你就越了解一个组织的成功案例可能在某个环境中行得通，也可能行不通（就像我们现在听到“速赢”或“唾手可得的果实”或流行语时产生的感觉一样）。
在“这要视具体情况来看”的回答之后，确实有一些开放的问题，以便进一步丰富这项建议的背景和理由。你认为数据库查询的意图是什么，或者缓存层是否有好处？需要的数据有多实时呢？认识到不存在银弹（不管是在解决方案上，还是在运作方式上），总能使问题的解决变得更生动、富有创造力。
4
完美是不切实际的
代码并不“关心”它的内聚或解耦程度；人们才会关心。 ——JamesCoplien
解决方案的完美之处在于接受或者承认，在某些时候，计划/投资的改变并没有给最终用户带来更多价值。
分解单体应用也是如此。我最喜欢的KelseyHightower的一条推文是这样写的：
很荣幸能在@thenewstack的Context播客上与@el-bhs辩论。虽然对单体和微服务存在争议，但是最终，我们都认为这两种架构模式都可以工作，而且对于复杂的组织而言，两者的混合是不可避免的。

文章图片
【9年当上架构师，我的很多想法变了】简言之，优雅的解决方案始终是适合客户/最终用户需求的解决方案。
5
真相存在于代码中，而非文档中（或JIRATicket中，请注意这点！）