How to write complex softwarea day agohttps://grantslatton.com/how-to-software首先编写玩具驱动程序，以发现解空间的物理约束从栈顶（UI或API）开始实现，并向下推进按层实现软件，每层剥离最小逻辑，并将复杂性向下委托编写某一层时，将下一层的API定义为当前层最理想的领域特定语言在编写当前层时，先存根下层接口，然后递归地实际实现它仅对IO部分使用可模拟的抽象接口；其余部分应为具体实现该方法能尽早获得部分可运行的软件，并自然地在工程师之间进行委托如果某层的API无法实现，则回溯并重新设计上一层的API
Every Man a Microservicea day agohttps://grantslatton.com/every-man-a-microservice康威定律被倒置：系统的设计塑造了组织的沟通结构，而非反之。理想的系统设计由单人规模的服务组成，每个服务拥有数万行代码库，单个开发者能够完全理解。单人规模的服务允许离线思考、快速达成改进共识、减少宕机、提高质量、架构变更在政治上可控、以及加快工程师成长。传统的团队拥有服务导致纯粹增量式的变更、对深度重构的恐惧以及对废弃的政治阻力。巴士因素风险由了解多个服务上下文并能介入的高级工程师缓解；初级工程师接受指导并成长为负责人。这样的组织只需要少数管理者，并依赖高级技术副手来提供可见性，因为大多数系统只需要几十个服务。
How to be useful as a software architect3 days agohttps://swizec.com/blog/how-to-be-useful-as-a-software-architect软件架构师必须在改进未来代码和维护当前业务速度之间取得平衡。常见的架构师失败模式包括编写被忽视的文档、强制执行僵化的规则，或者因做所有清理工作而精疲力竭。高效的架构师构建能够使所有团队成员快速、安全地贡献的系统。代码审查和系统设计审查是关键，但它们不应成为瓶颈；自动化和文化有助于扩展这些流程。强大的文化包括让开发者承担自己工作的后果、通过解释推理来传播知识，以及使用令人难忘的类比。反馈循环（如测试、强类型和可观测性）对于管理复杂性和及早发现错误至关重要。自动化（包括 linter、格式化工具和 AI 驱动的代码审查机器人）减少了重复性争论，并扩展了架构指导的范围。维护系统涉及技术和人文元素，文化和自动化支持可持续的代码库改进。
MetaPatterns5 days agohttps://metapatterns.io软件架构的模式语言强调架构模式是相互关联的，没有任何模式是孤立存在的。架构元模式将数百种模式归纳为少数几个类别，适用于本地系统和分布式系统。在线书籍版本可在GitHub和Leanpub上获取，以树状层次结构呈现架构模式，将其分为不到20个类别。本书包含关于复杂性、编排、编舞和共享数据集成等补充主题，以及系统演进示例。内容无AI生成，共440页，并使用直观的NoUML图示。
Comparing Fable and 10 other LLMs on refactoring a LangGraph god nodea month agohttps://wtf.korridzy.com/twilight-of-the-gods/该文章描述了一项实验，其中11个大型语言模型（包括Fable-5、GPT模型等）被要求为一个LangGraph代理中的'神节点'提出重构方案，随后对这些方案进行了交叉评估。'神节点'（计划节点）包含约350行隐藏逻辑，使得整个图难以调试、测试和修改。实验目标是将这些逻辑提升至图级别以提高清晰度。第一阶段，每个模型生成了一个分割计划节点的方案。这些方案在粒度上各不相同，从平衡的管道（如Fable-5的5阶段分割）到更粗略或更细致的方法均有涉及。第二阶段，模型对所有方案进行了评估。评审的细致程度存在差异：Fable-5的评审非常细致并发现了错误，而其他模型如Gemini-3.1-pro的评审则较为简略。第三阶段，通过平均分、论点分析和元评估等方法比较了方案和评审，以确定最佳方案和最佳分析师。按平均分计算，最佳方案来自Fable-5，其次是GPT-5.4和GPT-5.5。在评估方面，GPT-5.5是共识预测的最佳模型，而Fable-5和GPT-5.5在元分析中获得了很高评价。关键启示：对于架构生成，推荐使用Fable或GPT模型；对于评估，GPT-5.5或Fable-5是好的选择，但模型仍会出错，因此仍需人工监督。