架构设计过程中的10点体会

半吊子全栈工匠

发布于 2025-03-03 14:50:59

220

文章被收录于专栏：喔家ArchiSelf

在软件工程领域，任何脱离实际业务需求的架构设计都是一种不负责任的行为，甚至可以称之为"技术层面的形式主义"。这种设计倾向往往表现为过度追求技术新颖性、盲目采用复杂架构模式，或者为了架构而架构的设计理念。很多技术债务也是由于架构设计与业务需求脱节造成的。

多年的实践，经历了很多的项目和工程架构实现，整理了10点体会，可能不对，可能片面，都来自于过去的经验。

1.每个人都是凡人，无关职位

许多人从小就被灌输"要做一个听话的孩子"的观念，这种观念往往会在潜意识中形成对权威的畏惧心理。作为一位老码农，我也曾深受这种思维模式的影响。然而，随着互联网时代的到来，平等、开放、共享的互联网思维正在重塑新一代年轻人的思维方式。

事实上，在当今这个信息高度对称的时代，真正的权威往往更倾向于倾听不同的声音，因为创新往往来自于多元观点的碰撞。每个人都是独特的个体，都拥有值得分享的经验和见解。当我们能够以平等的姿态进行交流时，不仅能更好地表达自己的观点，也能从对话中获得更多启发。

在跨部门协作或多方参与的会议中，建立正确的角色认知至关重要。我们首先应当认识到，无论职位高低、资历深浅，所有参与者都是平等的，其次才是各自承担的特定角色——无论是负责技术架构的软件架构师、专注实现的工程师、把握产品方向的产品经理，还是统筹全局的项目经理。这种认知能够帮助我们摒弃职位带来的心理隔阂，营造开放、包容的讨论氛围。

2. 概念清晰是关键

若自己对某些内容不甚明了，很可能他人也同样处于困惑之中。这种情况下，不妨大胆发问！尤其是在踏入新的角色岗位，或是接手全新的产品、项目之时，常常会在会议场合发现这样的场景：有那么 1 - 2 个人正自信满满且语速极快地交流着，其余人则默默地点头示意。而于我而言，一些专业术语或者由三个字母组成的首字母缩略词颇为陌生。此时，往往会产生一种错觉，觉得除了自己，其他人似乎都对这些内容了如指掌。为了不暴露自己的无知，常常选择保持安静，只是默默点头表示认同。

然而，倘若逼迫自己主动提出问题，促使演讲者对自身观点加以阐释，便能够助力其收获清晰的认知，将那些复杂晦涩的内容转化为易于传达的信息。实际上，这种做法是在为在场的每一个人提供帮助，毕竟十之八九的人同样未能完全理解相关内容。尤其在主题繁杂且发言者又是该领域专家的情况下，最为关键的能力就在于能将复杂之处转化为清晰明了的表述，而我认为这恰恰是架构师所承担的重要角色之一。

明确概念至关重要。若涉及新术语，务必精准界定其内涵，即剖析该概念在时间与空间维度上的构成要素；而概念的外延，主要是为便于理解及指明其潜在应用场景。若仅阐述外延却忽视内涵定义，那便如同构建空中楼阁，永远无法切实落地。

此外，当有人使用广为人知的概念却发现其含义与自身理解存在偏差时，也需及时澄清。毕竟许多人对概念边界的认知较为模糊，容易引发混淆，我亦常有此类经历。

3. 文档决策

在项目管理中，有一条至关重要的原则：如果没有形成书面记录，就等于这件事从未发生过！这个观点在会议管理、技术探索和项目决策中尤为重要。

在快节奏的工作环境中，不要天真地认为参与者会记住会议的所有细节。一个人的工作记忆容量有限，48小时后就会遗忘约70%的新信息。如果会议结果确实需要后续跟进，书面记录就是确保执行力的关键。缺乏书面记录往往导致重复讨论、决策模糊和执行偏差，这种低效的沟通方式会显著延长项目周期。

这一原则同样适用于架构领域。概念验证（POC）、技术实验、探索性研究、架构设计直至工程实习——这些投入了大量时间和资源的努力，其成果必须以书面形式固化。这不仅是为了知识传承，更是为了避免重复劳动和确保技术决策的可追溯性。

关于记录的形式，建议根据信息的重要性选择合适的载体：

对于重要决策和长期参考的内容，建议使用Confluence或Wiki等知识管理平台
对于中等重要性的内容，可以在演示平台中存档
对于日常决策，电子邮件或聊天记录也是可接受的记录方式

特别要提醒的是，不要依赖会议录音。数据显示，超过90%的会议录音从未被重听。录音只能作为补充材料，而不能替代结构化的书面记录。有效的书面记录应该包含：关键决策、责任人、时间节点和具体行动项，这样才能真正发挥其价值。

4. 定义所有权人

所有权也是至关重要的，拥有一个明确的所有者，他们有责任和动力去加强和推动进步。经验数据表明，具有明确责任人的项目成功率比责任模糊的项目高出40%。这里的责任人，不仅定义了他的责任，而明确了他的权力边界。责、权、利明确才是定义所有权。

合作很重要，但总有一天你必须做出决定，继续前进，即使没有成功地达成共识。这个时候，在考虑到所提出的所有权衡之后，既定的所有权人应该做出决定，并允许每个人进入实现目标的下一步。过度的讨论和协商可能导致决策瘫痪。数据显示，约23%的项目延期都是由于过度追求共识而延误了决策时机。

如果没有明确的所有权人，预期的成果就不会产生，或者机会从时间中溜走。我们陷入了某个阶段而无法前进？这往往是由于缺乏决策或没有人站出来推动进展。

5. 使用架构合约

每当负责领导一个跨越多个业务单元与开发团队的技术架构项目时，都意味着会面临诸多相关利益所有者，因此务必创建某种架构契约。

当某个产品或项目仅由单一业务单元负责开发时，产品需求能够被较为清晰地定义为初始需求，毕竟显而易见的是，所有的技术工作均由该单一业务单元所拥有。然而，倘若一个大型项目涵盖跨业务组的协作，且每个业务组都各自提供特定的功能、服务或组件，那么仅依赖以最终用户为核心的产品需求便远远不够了，因为在各业务单位之间明确划分责任变得至关重要。

产品经理通常难以对每个技术服务或组件的需求作出精准定义，因为这是终端用户无法直接感知到的技术细分层面。故而，制定技术“合约”是必不可少的。

在技术合约之中——除了细致入微的书面要求之外，还应配备图表说明。组件图自然是首要之选，但时常会发现某些功能方面的细节在这一步被遗漏了，所以要运用序列图来强化契约内容，因为它们能够清晰直观地展现服务与组件之间的责任划分，进而明确各小组的分工。

随后，每个业务单元的核心干系人（如架构师和工程师）应当对技术合约进行审核并签字确认，以此确保各方认知的一致性与连贯性。

这或许看似理所当然，但令人惊讶的是，多个团队常常在推进过程中自以为彼此步调一致，而实际情况却是他们之间存在着差距，甚至持有相互冲突的观点。一个单一的产品需要有且仅有一个统一且明晰的技术愿景。

6. 不要盲目地相信指令

总是给自己提出问题和挑战假设的空间，保持独立思考的能力和勇于挑战既定假设的精神非常重要——这种品质对于身处领导岗位的人而言尤为难得。然而，真正的专业精神恰恰体现在这种敢于质疑和反思的勇气中。

在任何情况下，都切勿让他人肆意剥夺你那宝贵的自主权利。要始终保持独立思考的能力，紧密贴合自己内心深处的声音，这声音往往是经过多年深入学习与丰富实践经验的沉淀与凝练而成。

诚然，最终的决策或许并非总能如你所愿。每个人都应当拥有属于自己的决定权，而这个关键的决策者并不总是你。但是，一定不要就此沉默，而是要勇敢地说出自己的想法，积极地表达出你的反馈意见，努力让自己成为讨论过程中一个有价值的参与者。

7. 提出问题伴随着解决方案

这是我最重要建议，几乎适用于所有的行当。

发现一个问题很容易，但是尽量不要过来就指出问题，这常常被认为是批评或者抱怨。相反，总是至少为问题制定一个解决方案，理想情况下是制定几个替代解决方案，每个解决方案都有自己的权衡，并且只将问题与潜在的解决方案一起呈现。通过展示前进的方向来推动变革，而不仅仅是发泄。

采用"问题-解决方案"的方式能够带来显著优势：

展现专业能力和责任心
促进建设性讨论
推动问题实质性解决
提升个人影响力

选择的解决方案可能是你没有想到的替代方案，这没关系。通过提出至少一些解决方案，然后可以启动创新并思考如何改进。

8. 避免过度设计

致力于为每个特定的案例精心打造相应的架构，这无疑散发着巨大的吸引力。毕竟，我们每个人内心深处都怀揣着对完美工作的执着追求，期望自己所负责的每一个项目、每一项任务都能毫无瑕疵。

然而，在这看似美好的追求背后，隐藏着完美主义带来的重重阻碍。过度地对设计进行架构化处理，会引发一系列负面效应。其中最为突出的表现便是开发时间的急剧膨胀。开发人员可能会陷入无尽的细节优化和架构调整之中，导致项目的推进速度变得异常缓慢。从长远的视角来看，这种过度投入所带来的额外付出往往并不能得到与之相匹配的回报。

而敏捷方法的核心要点之一在于，精准地识别并放大每个阶段中真正具有价值的元素，然后将主要精力聚焦于此。通过这种方式，能够在确保项目价值得以最大程度实现的同时，有效地避免陷入过度设计和完美主义的误区，从而保障项目的高效推进和可持续发展。

9. 退一步海阔天空

当项目陷入停滞状态，出现原地打转的迹象时，退一步，找出根本原因。半数以上项目的延误都源于未能及时识别和解决根本性问题。

是因为缺乏所有权人吗？
是否缺乏充分的授权（人，钱，时间）？
这是一个没有实现的共识愿望吗？
是否有新的利益相关者需要重新作出决定？
...

工程停滞是多重因素叠加的结果。建议采用"5Why分析法"深入挖掘问题本质，同时建立预防机制。发现问题是成功的一半，但只有系统性地解决问题才能确保持续前进。

10. 真正的敏捷

我相信敏捷方法论，但是只有当它们真正是敏捷的时候。

在现实世界中，我们常常目睹这样的景象：众多公司长期以来深深扎根于传统的瀑布式开发模式，其组织架构、工作流程以及企业文化都已与瀑布方法紧密交织。然而，面对市场快速变化的挑战以及追求更高效开发过程的需求，这些公司试图踏上敏捷转型之路，却又难以彻底摆脱瀑布模式的束缚。他们在保持既定的最后期限、僵化的范围划分以及繁琐沉重流程不变的基础上，生硬地添加上某种形式的敏捷方法，而 Scrum 往往是首选的 “装饰”。

于是乎，在这些公司的日常运营中，“站会”“冲刺”“史诗”“用户故事” 等敏捷专业术语开始频繁响起，表面上看似在积极采用敏捷实践。但深入观察其实际操作就会发现，其核心思维方式依旧深陷线性的泥沼，仍然被固定的框架禁锢，未能拥抱应有的灵活性。当这种貌合神离的情况发生时，企业只是徒增了实施 Scrum 等敏捷实践的表面成本，却未能收获敏捷方法本应带来的诸多益处，如快速响应变化、提升团队协作效率以及更快交付有价值的产品增量等。

换句话说，这样的企业不幸陷入了两个世界的夹缝之中，形成一种称之为 “WaterGile”的境地。

留在瀑布公司通常有合理的理由ーー比如当所在的行业需要承诺的时间表和范围时。但是，如果真的决定引入敏捷，要确保自己致力于真正成为敏捷，不要让自己我称之为 “WaterGile” 的组合方法所拖累。

诚然，有些公司出于行业特性的特殊考量，如所在行业对明确的时间表和精确范围有着严格要求并需要对外作出承诺等情况，选择留在瀑布模式阵营往往存在其合理之处。但是，对于那些毅然决定引入敏捷方法的企业而言，务必确保自身全身心地投入到真正的敏捷转型进程中，避免陷入这种既不像瀑布也未得敏捷之利的困境。