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

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

言归正传，本文不是吐槽架构上的坑，而是整理少量 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）适应度函数

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

适应度函数可以通过少量测试或者者工具来取得。

1-适应度函数.png

之前文档整理出一部分实践，例如：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）人人都是架构师

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

总结：

总结