⌘K
Change language Switch ThemeSign In
Narrow Mode
How to Battle Complexity Before It Kills Your Software (30-Year Veteran's Take)
!Image 2: Beyond Coding Beyond Coding @Beyond Coding
One Sentence Summary
30-year coding architect Dennis Doomen shares battle-tested strategies for managing software complexity, embracing AI tools without compromising quality, and why staying hands-on is the only way to make good architectural decisions.
Summary
Microsoft MVP and open source creator Dennis Doomen brings 30 years of hands-on experience to discuss why coding architects must stay in the code to remain effective. He explores the dangers of dogmatic pattern-following and accidental complexity, shares his workflow for building open source projects with GitHub Copilot while maintaining code quality, and explains why test-driven development and architectural decision records have become even more critical in the AI-accelerated development era. The conversation covers practical approaches to code review, mentoring junior developers with AI assistance, and guidelines for responsible open source consumption.
Main Points
* 1. The only way to remain an effective software architect is to keep coding alongside your team.Doomen emphasizes that hands-on experience with production systems is irreplaceable for making sound architectural decisions and staying current with technological shifts like the AI wave. * 2. Dogmatic pattern-following without understanding creates accidental complexity that kills codebases.Teams often copy folder structures and architectural patterns without grasping the underlying principles, leading to unnecessary complexity that could be eliminated by challenging consistency when it doesn't serve simplicity. * 3. AI tools can accelerate development but require disciplined review and refactoring practices.While Copilot can generate entire projects from GitHub Issues, generated code tends toward long sequential methods and requires human oversight, feature branches, and comprehensive testing to maintain quality. * 4. Tests serve as the safety net in an AI-first development world.As execution accelerates through AI assistance, robust tests become essential documentation and protection against regressions, making test-driven development more valuable than ever. * 5. Architectural Decision Records (ADRs) protect designs from organizational amnesia.Documenting not just what was decided but why, along with rejected alternatives and trade-offs, enables future teams to understand context and defends against arbitrary management changes.
Metadata
AI Score
87
Website youtube.com
Published At Today
Length 3542 words (about 15 min)
Sign in to bookmark videos and track your viewing history. Sign in now
!Image 3: How to Battle Complexity Before It Kills Your Software (30-Year Veteran's Take)
How to Battle Complexity Before It Kills Your Software (30-Year Veteran's Take)
内容概要
在本期视频中，拥有 30 年开发经验的微软 MVP、开源传奇人物 Dennis Doomen 与主持人探讨了现代软件工程中至关重要的课题。Dennis 分享了他作为「编码架构师」如何通过亲身参与开发来保持对架构的判断力，深入剖析了教条主义和过度设计带来的「偶然复杂性」。同时，他也分享了自己在 AI 辅助开发时代的最新实践，包括如何利用 GitHub Copilot 和 Claude 快速构建开源项目，以及在 AI 介入后，测试驱动开发（TDD）和决策记录（ADR）为何变得比以往更加重要。
目录
* 编码架构师：为何架构师必须亲自动手写代码 * 识别与消除偶然复杂性：教条主义的陷阱 * AI 驱动的开发流程：从 GitHub Issue 到完整的开源项目 * 保持批判性思维：AI 生成代码的审核与重构 * 软件工程的新重点：测试作为安全网与文档 * 知识的传递：如何在团队中培养新人并利用 AI 辅助学习 * 决策记录的价值：为什么「为什么」比「如何做」更重要 * 开源项目的未来：商业模式、维护责任与社区回馈
编码架构师：为何架构师必须亲自动手写代码
主持人： 你认为在团队中创建软件最有效的方式是什么？ Dennis： 我认为这是唯一的方式，那就是作为架构师的同时，也与团队一起工作，通常是作为团队的一部分并与他们一起编写代码。我喜欢称自己为「动手型架构师」或「编码架构师」。我所谈论的一切几乎都是基于我的实际经验。如果你停止编码，停止构建实际的生产系统并将其部署到互联网上，你就会失去那种感悟。想象一下，如果我在过去三年停止了编码，我可能会错过整个 AI 浪潮。我今年 52 岁了，从事这一行将近 30 年，我无法想象停止编码。在生产环境中运行程序能让你学到很多。能够向开发者演示「如果你采取稍微不同的方法，代码会更具可维护性」，这是非常有价值的。同时，亲自动手也能让你撞上框架的限制，学到新的技术、洞察或范式。我不喜欢谈论 .NET 10 有什么新特性，这种人多的是，我更喜欢谈论我在日常工作中经历的痛苦与成功。
很多大公司的企业架构师只处理高层事务、政策或信息架构。他们不再有实际经验去判断某个解决方案是否真的有效，或者某个决策对长期可维护性的后果是什么。作为软件架构师，保持高效的唯一方法就是知道你自己在做什么，去实验，看看你构想的方案在实践中是如何被使用的。哪怕只是在现有代码库中修复 Bug 也是非常有价值的。
识别与消除偶然复杂性：教条主义的陷阱
Dennis： 作为顾问，我经常进入一些团队，看到他们正与代码库作斗争。你会发现代码耦合度太高、内聚性不足。当你从更高维度观察时，你会发现那看起来像是一个洋葱架构（Onion Architecture）或整洁架构（Clean Architecture）。原来过去有人曾有过某种愿景，但现在的开发团队已经完全迷失了方向，他们甚至不知道底层架构风格是什么。他们只是在不断地复制粘贴文件夹和项目结构，而不理解为什么要这样做。他们变得如此教条，以至于失去了优化或简化代码库的能力，因为他们只是在盲目复制某种模式。如果你不在代码库中，你根本察觉不到这一点。架构师在做设计时会做很多假设，但当这些设想转化为现实时，团队可能会犯错，或者你原本以为需要的某种抽象（比如事件溯源或 CQRS）其实对团队来说太复杂了，或者性能不够好。
软件工程的核心在于维持现有成果与不断累积的复杂性之间的平衡。有些复杂性是「偶然复杂性」（Accidental Complexity），即大家都在尽力而为，却没意识到引入了不必要的复杂工具。有时为了保持一致性，开发者宁愿保留复杂性。但我更倾向于简化。如果一个模块变得太复杂，我会打破所谓的「全局一致性」，把这个模块作为一个边界，在内部进行简化。很多开发者在 10 到 15 年经验时会过度热衷于模式，比如不断挥舞着 SOLID 原则对你说「我们要为未来做准备」，但其实你现在根本不需要那个抽象。
AI 驱动的开发流程：从 GitHub Issue 到完整的开源项目
主持人： 现在有了 AI 辅助开发工具，对话的方式是否发生了变化？ Dennis： 我觉得在未来的某个时间点，我们可能不再关心代码本身了。就像《星际迷航》里，他们不需要写代码，只需告诉电脑要做什么。去年 9 月，我建立了一个新的开源项目 Mockly，这是一个针对 .NET 的 HTTP 模拟库。我之前在客户项目中使用过其他库，但觉得不好用，于是我想：我有 15 年开源经验，我能做得更好。我先在 GitHub 的一个 Issue 里收集了所有需要的功能和 API 示例。出于好奇，我尝试把这个 Issue 指派给了 GitHub Copilot（GitHub 内部的一项功能）。令我惊讶的是，它生成了一个非常漂亮的开源项目，实现了我需要的所有功能，并且严格遵守了我的代码规范，因为我已经设置好了编辑器配置和静态分析器。
之后我通过 Pull Request 与 AI 交流。我让它移除一些步骤，创建断言方法。我还有一个开源项目叫 Fluent Assertions，我希望 Mockly 能同时支持版本 7 和版本 8，AI 也帮我做到了，甚至帮我拆分了项目并更新了 Readme 文档。从那之后，我开始接管代码，把它当作我自己的代码来演进。
保持批判性思维：AI 生成代码的审核与重构
Dennis： 虽然我拥抱 AI，但我也会遇到问题。AI 倾向于生成非常长的方法，尤其是逻辑按顺序排列时。我暂时接受了这些代码，直到我需要修改它们时再进行重构。我会不断切换工具，有时用 GitHub Copilot，有时在 IDE 里用 Claude。但我一定会审查测试。即使是 AI 生成的测试，我也要确保我理解它们，确保它们确实在测试我预期的行为。如果我觉得某项工作是重复性的，我就会让 AI 去做，比如增加测试覆盖率。但我会要求它在完成修改后同时更新「指令文件」（Instructions file），以便下次它能更紧密地遵循我的偏好。 主持人： 我曾尝试全 AI 驱动的工作流，结果因为上下文压缩导致了错误。如果你不在一个可以实验的环境中，很难跟上节奏。 Dennis： 没错。有一次我用 Claude 在 IDE 里改代码，同时也手动改了一些。我习惯快速提交临时 Commit 以防丢失进度。结果我发现 Claude 在我没注意的情况下撤销了我之前的一些手动修改。你必须非常小心，使用功能分支（Feature Branch）和 Pull Request 能帮到大忙，因为你可以通过 Git 记录找回被强制推送覆盖的内容。
软件工程的新重点：测试作为安全网与文档
主持人： 既然开发速度在加快，研究和规划是否变得更重要了？ Dennis： 确实如此。现在构建一个工具可能只需要弹指之间，但你要解决什么问题、如何获得用户变得更关键。 主持人： 我以前非常在意测试的结构，不仅是为了自己，也是为了未来的同事。在 AI 时代，测试就是你的安全网。如果你把软件看作黑盒，而测试是你的安全网，那么你必须投入额外的精力确保测试是健壮的。 Dennis： 我一直热衷于测试驱动开发（TDD）。我希望我的测试是自解释的，没有噪音，可以作为文档使用。现在有些人甚至先写测试和规范，然后生成代码。这是一种很好的方式，直到我们真正不需要写代码的那一天。知识的传递：如何在团队中培养新人并利用 AI 辅助学习
Dennis： 关于如何培养新人，我认为方式没变：让他们在现有代码库中修复 Bug，处理小的改进，让他们提问。我在做代码审查（Code Review）时会使用 Emoji 来表达意图。比如用「鹤嘴锄」图标表示我在「挑刺」（Nitpicking），这通常是针对新人，告诉他们代码没问题但可以更好；用「思考者」图标表示可以讨论不同的实现方案；用「营地」图标表示他们让代码变得更整洁了。如果他们卡住了，我会建议他们问问 AI，然后把 AI 的回答作为我们讨论的起点。理解为什么要用某种抽象（比如依赖倒置原则），这是 AI 现在还做不到的。AI 无法提供全局视图。 主持人： 有些人因为「冒充者综合征」不敢问同事，转而问 AI。 Dennis： AI 确实擅长解释不同的方案。比如我曾纠结于选 Azure Function 还是 Container Apps，AI 能给我一个很好的对比。它能解释不同版本的真相并汇总。我每天会用它很多次。
决策记录的价值：为什么「为什么」比「如何做」更重要
Dennis： 理解代码背后的历史和原因非常重要。这就是为什么我仍然坚持让大家在 Pull Request 中描述「为什么」要这么做，而不仅仅是「做了什么」。我经常说服客户使用 Confluence 这样的平台来记录「架构决策记录」（ADR）。对于任何非琐碎的决策，我们都会记录历史、优缺点对比、参与者以及拒绝了哪些方案。当一年后新来的架构师挑战之前的决定时，这些记录就能发挥作用。我曾因为这些记录在管理层变动时保住了我们的架构设计。
开源项目的未来：商业模式、维护责任与社区回馈
主持人： 像 Tailwind 这样的项目最近裁员了，因为 AI 降低了其付费组件的门槛。如果没有商业模式，人们会不会失去做开源的动力？ Dennis： 这是一个值得思考的问题。我在架构师的角色中经常写「开源消费准则」。我告诉团队：如果你使用开源代码，就必须意识到如果原作者不再维护，这就是你的代码了。你必须像对待 AI 生成的代码一样对待开源代码。你要考察它的质量、是否有自动化测试、社区是否活跃。虽然维护开源很辛苦，但它非常有趣。这是展示你能力的好方法。当看到别人欣赏你的作品时，那种感觉很棒。我也从别人的贡献中学到了很多。开源本质上是「给予并获得更多」的过程，你能获得知识、经验、新工具和知名度。这是非常有价值的。
!Image 4: Beyond Coding Beyond Coding @Beyond Coding
One Sentence Summary
30-year coding architect Dennis Doomen shares battle-tested strategies for managing software complexity, embracing AI tools without compromising quality, and why staying hands-on is the only way to make good architectural decisions.
Summary
Microsoft MVP and open source creator Dennis Doomen brings 30 years of hands-on experience to discuss why coding architects must stay in the code to remain effective. He explores the dangers of dogmatic pattern-following and accidental complexity, shares his workflow for building open source projects with GitHub Copilot while maintaining code quality, and explains why test-driven development and architectural decision records have become even more critical in the AI-accelerated development era. The conversation covers practical approaches to code review, mentoring junior developers with AI assistance, and guidelines for responsible open source consumption.
Main Points
* 1. The only way to remain an effective software architect is to keep coding alongside your team.
Doomen emphasizes that hands-on experience with production systems is irreplaceable for making sound architectural decisions and staying current with technological shifts like the AI wave.
* 2. Dogmatic pattern-following without understanding creates accidental complexity that kills codebases.
Teams often copy folder structures and architectural patterns without grasping the underlying principles, leading to unnecessary complexity that could be eliminated by challenging consistency when it doesn't serve simplicity.
* 3. AI tools can accelerate development but require disciplined review and refactoring practices.
While Copilot can generate entire projects from GitHub Issues, generated code tends toward long sequential methods and requires human oversight, feature branches, and comprehensive testing to maintain quality.
* 4. Tests serve as the safety net in an AI-first development world.
As execution accelerates through AI assistance, robust tests become essential documentation and protection against regressions, making test-driven development more valuable than ever.
* 5. Architectural Decision Records (ADRs) protect designs from organizational amnesia.
Documenting not just what was decided but why, along with rejected alternatives and trade-offs, enables future teams to understand context and defends against arbitrary management changes.
Key Quotes
* If you're not in the code, you can't make good architectural decisions. Period. * Imagine if I had stopped coding for the last three years, I would have completely missed the whole AI wave. * The only way to be effective as a software architect is to know what you're doing yourself, to experiment, to see how your envisioned solutions are being used in practice. * Many developers with 10 to 15 years of experience become overly enthusiastic about patterns, waving the SOLID principles at you saying 'we need to prepare for the future,' but you don't actually need that abstraction right now. * I tend to simplify. If a module becomes too complex, I'll break the so-called global consistency and treat that module as a boundary to simplify internally. * I asked Copilot to create assertions, and I also have Fluent Assertions as an open source project, so I wanted Mockly to support both version 7 and version 8, and it did that for me too. * AI tends to generate very long methods, especially when logic is sequential. I temporarily accept this until I need to modify them, then I refactor. * If you see software as a black box and tests as your safety net, you have to put in the extra effort to make sure those tests are robust. * Understanding the history and reasons behind code is crucial. That's why I still insist that people describe the 'why' in their pull requests, not just the 'what'. * I once convinced management to keep our architecture intact thanks to those records during a management change.
AI Score
87
Website youtube.com
Published At Today
Length 3542 words (about 15 min)
Tags
Software Architecture
Complexity Management
AI-Assisted Development
Clean Architecture
Test-Driven Development
Related Articles
* The creator of Clawd: "I ship code I don't read" * Choosing the Right Multi-Agent Architecture for AI applications, detailing their uses, tradeoffs, and performance to guide developers in choosing the right pattern.") * Conversation: LLMs and the what/how loop * Towards self-driving codebases * Lead Software Engineer: Stop "Future-Proofing" Your System Design.") * The Anatomy of an Agent Harness * Build Hour: API & Codex * The Extensibility Triangle That Stopped Me Over-Engineering Claude Code * OpenClaw: The Viral AI Agent that Broke the Internet - Peter Steinberger | Lex Fridman Podcast #491 * Design-First Collaboration HomeArticlesPodcastsVideosTweets