架构上“坑”了小伙伴如何填？

软件开发中大小坑遍地，架构设计上同样到处都是坑坑洼洼。随着工作经验积累的增加，自己也开始接触架构，自己做架构设计，也参考别人的架构设计。由于自己的经验和精力有限坑过小伙伴，也被小伙伴坑过。

言归正传，本文不是吐槽架构上的坑，而是整理一些 5 种常见的坑给出填坑思路。

(1) 架构产出不足

(2) 架构的技能不足

(3) 延迟决策坑队友

(4) 年久失修的架构

坑 01： 架构产出不足

表现形式：

1，一张架构图走遍天下…

2, 架构图离了架构师谁都看不懂，需要架构师频繁将

3，团队没有可用拿出来就用的架构图

…

架构资料应该怎么整理？

（1）团队资料空间和目录

为团队建立资料空间，并创建不同的目录结构，例如：Tech、Epic、Solution、DevOps等

（2）为不同的人准备不同的架构图

看架构图的人不一定是技术，还要可能是业务人员，精力足够的时候为他们准备不同的架构图，能够提升后续多个场景下的沟通效率。

（3）实用的架构图需要 1 - 3 级

架构图可以选择自己擅长的任何一个工具（软件/白板/草图）绘制就可以，为了后续好调整建议使用软件维护。

根据项目大小决定产出几级的架构图。下面是一个 3 级架构图的描述：

Level 1：包含 IT 环境、角色、受众，以及它们的互动

Level 2：项目中不同的服务如何配合的，需要标明通信协议、授权方式、同步/异步等等

Level 3：某个服务内部的层次设计，描述清楚每一层的作用，标注技术选型。

当项目短小时可以压缩为一张图，实用即可。当项目稍微复杂可以使用两层，但是要技术选择等信息是需要进行描述的，不能因为层级少了，应该介绍的部分也省略掉。

不用把代码逻辑也画出来，那和注释无异，反而增加了团队负担，因为要维护它，如果要了解业务实现可以通过 Story 描述和 代码直接了解当前运行的情况（PS：当然需要有看代码的技巧，否则只能抗拒，与其抗拒不同升一下自己的硬核技能。）

（4）架构图上标明技术选型

上面已经讲到了在架构图上标明技术选型，一方面有利于架构师注意到设计是否合理，也避免后面提到的延迟决策、多种技术扎堆的情况。

别人看一眼就知道的事，何乐而不为。

（5）将决策做记录

影响架构的因素很多，比如外部 IT 环境，当前团队人员能力等。记录下做出某个选择记录，避免后续需要频繁解释的问题。

（6）适应度函数

设定适应度函数能够帮助架构师更加实时了解项目架构设计情况，并了解引入的变化对项目的实际影响，从而引导架构演进。

适应度函数可以通过一些测试或者工具来获得。

之前文档整理出一部分实践，例如：PMD、CheckStyle、Jacoco、ArchUnit 等。通过工具和测试能能够让架构师和开发者了解难度并评估变化的价值。

坑 02：架构技能不足

坑的表现形式：

1，靠工龄得到的架构角色，并没有足够的能力

2，架构经验少，知识有限

…

架构经验不足怎么办？

（1) 勇敢的承认自己的缺陷

我有很多缺陷，所以也就有了一个很长的代办清单，通过清单来学习。但同时我选择勇敢的承认自己的不足，并从他人那里获得反馈和改进意见，并逐渐提升自己。我熟悉我的缺点，就和我熟悉我的优点一样。所以有很多次我的能力不足，但是我并没有把事情搞砸，而是一点点成长。

（2）和团队小伙伴共同制定架构

这是我经常使用的一个技巧。

当我设计完架构后会询问团队下伙伴的意见，这个过程是个相互学习的过程，有时候有自己能有意外收获，同时团队小伙伴也清楚接下来在架构上的思路。

当我没有把握的时候也会拿着自己的思路，向小伙伴寻求帮助，有段时间甚至都养成了“每日一问”的习惯。这个过程中也形成了“统一语言”（使用相同的思路描述问题和回答问题）。

（3）项目进展过程中逐渐引入新变化

当一个平衡的环境中引入新的变化，会破坏到原来的平衡状态，并寻找新的新的平衡点或者崩溃。所以引入变化时需要控制风险，不要让变化大的直接让项目重新来过。也不应该害怕变化而碌碌无为、不作为，最后全凭解释来变通。

（4）向环境外看，了解最佳实践，持续学习

不要抱怨自己的环境不好，把焦点放在投资自己，获取回报上，多向环境外看，锁定目标持续学习，了解最佳实践，从动作练习。编码的能力我们能够通过刻意练习来提升水平，架构方面也一样。

坑 03：延迟决策坑队友

坑的表现形式：

1，发现的问题 A 确实存在，但是难以取舍，搁置后就没人理会了。最终重要问题的解决办法是临时决定

2，技术选型没有定，导致开发过程中项目成了工具库聚集地

3，项目因为考虑少了，越做越难做，本来时间充裕，结果后期全靠拍脑袋。

…

那么遇到延迟决策怎么办？

（1）为自己设置 DeadLine

懂得时间管理的人一天会主要接种的 3 - 4 件事情上。同样针对某个难题需要设定 Dead line，然后去做，清晰的之后知道哪天应该完成什么，并执行到底，**延迟决定是债，得还！**如果决策不了怎么办，没必要一个人承担所有，和周围的小伙伴沟通一下，和其他团队的人沟通一下，相信很快问题就有结果了。

（2）提升专业技能

软技能可以让我们事半功倍或者弥补一部分不足，但是关键还是需要提升自己的硬实力。承认自己不行并没有解决问题，在架构上我们需要做到如下几方面的硬实力。

架构驱动能力、软件设计能力、技术风险、架构演进能力、编码能力、质量保证能力。

至于架构师要不要编码，在之前的文章《架构师要不要编码》中已经介绍过了。

除去编码部分，架构师可能还需要一些适应度函数来辅助自己了解现有系统的状态，例如了解现有系统的圈复杂度（在《实战Jacoco》中讲到了如何使用Jacoco来获取单一项目的测试情况），还可以通过建立约束来让架构能够可持续演进，例如引入PMD、CheckStyle

（3）和团队功能决定难题

前面已经讲到了和团队共同协作完成架构设计，他不但能让问题得到解决，还有很多附加价值。

坑 04：年久失修的架构

坑的表现形式：

1，项目在持续集成，但是架构图除了第一版后来再也没有关注过

2，靠读代码去反推架构，就想玩盲地图的解锁游戏

…

架构年久失修了怎么办？

（1）团队指定一个顾全‘大局’的人

年久失修很有可能就是没有人负责架构，或者全凭自觉。这往往是靠不住。指定一个顾全“大局”人很有必要。因为适当的设计和计划，能让人不盲目。

（2）适当的预先做架构设计和演进

不管你是否在敏捷团队，做架构设计都是好的，因为架构描述了愿景和目标，确保团队团队朝着正确的方向进行。重点是原先设计的量，可以结合交付计划，去逐渐补充团队需要的架构信息。

（3）人人都是架构师

这里并不是靠自觉。是指建立一种开放学习的氛围，帮助那些对架构感兴趣的小伙伴，并鼓励他们挑战当前的架构，这是和团队共同承担架构的另外一种形式。

总结：