文章核心内容：只有实际参与开发大型软件系统的工程师才能真正参与设计过程，因为良好的软件设计需要深入了解系统的具体细节。通用的软件设计建议通常对实际开发问题无用，因为那些建议只针对问题本身，而不了解现有代码库的具体情况。

无法设计你不参与的软件系统

核心观点

只有实际参与大型软件系统开发的工程师才能真正参与设计过程。因为脱离具体系统细节的通用软件设计建议对解决实际问题通常毫无价值。

通用软件设计的局限性

1. 纸上谈兵的本质
   通用设计建议往往基于对领域问题的理解，而非对现有代码库的认知。这类建议充斥在技术书籍和博客中，但实际工作中：

   • 大型代码库中一致性比"完美设计"更重要
   • 现有系统存在复杂的连锁反应，实际可选的修改方案极其有限
   • 共享代码库永远处于不同设计理念的过渡状态

2. 适用场景
   仅适用于：

   • 全新系统构建
   • 具体设计方案难以抉择时的参考标准
   • 跨代码库的统一规范制定
   • 公司级技术架构选型（如云服务选择）

有效设计的真实样貌

1. 深度对话
   最有效的设计讨论发生在：

   • 少数深度了解系统的工程师之间
   • 聚焦具体技术细节（如"能否在子系统A添加新功能，需要考虑上下文C中B数据的获取..."）
   • 常涉及近期重构带来的隐藏可能性

2. 与通用设计的本质差异

   • 不讨论"DRY还是WET"等理论问题
   • 重点在于澄清具体实现细节的误解

架构师角色的困境

1. 现实矛盾

   • 脱离实践的架构设计常被一线工程师忽略
   • 架构师无需为实施结果负责（成功归功设计，失败归咎实施）

2. 健康模式
   作者主张：

   • 设计者应对项目成败负责
   • 真正的软件设计师应能处理代码库的所有"毛边"
   • "纯粹架构师"角色终将失败

结论启示

1. 优秀设计源于：

   • 对代码库的深度参与
   • 具体到文件/行号的讨论

2. 通用设计应限定于：

   • 新系统搭建
   • 决策辅助
   • 技术战略制定

（注：原文中的推广内容、注释索引等非核心信息已精简，保留了核心论证逻辑和关键案例）

以下是评论内容的总结：

支持通用软件设计的观点

1. 通用设计提供方向性指导

   • 评论1：通用设计为实施提供框架和共同术语，但实际实施可能偏离计划。
     "Generic Software Design... is nice for setting the general direction... The actual implementation can deviate from the plan."
   • 评论5：经验丰富的开发者可以无需编码即设计大型应用，需依赖多次实践和管理经验。
     "You absolutely can design a large application without touching the code... prior experience in management is extremely helpful."

2. 类比其他工程领域的有效性

   • 评论3：结构工程与软件工程类似，但软件需求变化更快，通用建议可能不适用实际场景。
     "Construction methods change, but they don’t change as quickly as software engineering... Generic advise may be helpful, but it always applies to some generic site conditions."

反对通用软件设计的观点

1. 通用建议缺乏实际适用性

   • 评论2：文章本身陷入其描述的问题，提供的是无法适用于具体情境的通用建议。
     "It’s generic advice that might not be appliable to specific situations."
   • 评论6：一致性优于“好设计”的建议本身就是一种通用设计建议，可能导致持续的不良实践。
     "Consistently 'bad' is better than being good at least in some areas!"

2. 实际需求的复杂性

   • 评论4：前期架构与实施难以分离，实际需求比最初想象的复杂得多。
     "No reasonable person can design such a system upfront... things like 'opt-out mechanism sometimes shouldn’t opt you out' do not occur to reasonable people."
   • 评论11：独立的软件架构师若不参与实际维护，其建议往往不切实际。
     "There are too many decisions, technical details... to have someone come in and give direction from on high at intervals."

关于架构师角色的争议

1. 架构师的实际作用有限

   • 评论13：大多数架构师不参与实际设计，仅提供泛泛建议或审批。
     "Most architects do not design, do not architect... At most, you can expect the architects to give generic advice."
   • 评论12：方法论制定者也应对项目成败负责，而 Scrum 管理者等缺乏实际投入。
     "Scrum masters just don’t have the same skin in the game that lead engineers do."

2. 平衡细节与全局视角

   • 评论14：需避免两种极端——脱离实际的架构师和过度优化的“真实程序员”，需结合细节与全局知识。
     "Decision makers need both intimate knowledge of the details and the broader knowledge to put those details in context."

其他观点

• 评论7：开发者作为软件用户时更能发现并修复设计缺陷。
  "A design flaw... will also affect the developers and will motivate the latter to correct it."
• 评论8：文章内容很大程度上是同义反复。
  "The post is largely tautological."
• 评论9：对作者高质量文章的赞赏。
  "Very impressed at the rate of high-quality interesting posts from this author."

总结：评论围绕通用软件设计的价值、实际需求的复杂性以及架构师角色的有效性展开，观点呈现明显对立，但普遍强调实践经验与具体情境的重要性。