#架构设计

1天前

我现在是 Agent 信徒 + 手搓，Tab 反而最少 1. 先用 Agent 快速实现完整功能，不必在意质量，但核心是完整实现需求，走通各个流程，了解各种边界条件 2. 然后基于需求和完整的流程，重新思考设计架构，再手搓+Agent 这样既可以兼顾速度，又可以保证质量

#agent #手搓 #效率 #架构设计 #软件开发

1个月前

前一段时间有人问我怎么系统的学习前端。我最近感触很深的是，很多东西过了多少年依旧没有变，比如我面过人类学的前端架构，里面问到的问题依然是2020年Slack的架构设计的博客内容。即使是在AI时代，nothing is new：SSE、websocket……甚至正因为有了AI，很多设计模式来控制复杂度变得尤为重要。所以我觉得当今人应该更多放在整体的架构设计和代码复杂度控制。所以我觉得付费给一些很无聊的人讲怎么vibe coding是很囫囵吞枣的事情，我觉得有很多人靠着贩卖焦虑来获得流量和收入，但我觉得有些事情是必须“纸上得来终觉浅，绝知此事要躬行”

#前端学习 #架构设计 #代码复杂度控制 #贩卖焦虑 #实践的重要性

2个月前

分享一个Claude Code全局提示词（也适用于Augment/Cursor等等），有架构师附身之奇效： ## Code Architecture - 编写代码的硬性指标，包括以下原则：（1）对于 Python、JavaScript、TypeScript 等动态语言，尽可能确保每个代码文件不要超过 200 行（2）对于 Java、Go、Rust 等静态语言，尽可能确保每个代码文件不要超过 250 行（3）每层文件夹中的文件，尽可能不超过 8 个。如有超过，需要规划为多层子文件夹 - 除了硬性指标以外，还需要时刻关注优雅的架构设计，避免出现以下可能侵蚀我们代码质量的「坏味道」：（1）僵化 (Rigidity): 系统难以变更，任何微小的改动都会引发一连串的连锁修改。（2）冗余 (Redundancy): 同样的代码逻辑在多处重复出现，导致维护困难且容易产生不一致。（3）循环依赖 (Circular Dependency): 两个或多个模块互相纠缠，形成无法解耦的“死结”，导致难以测试与复用。（4）脆弱性 (Fragility): 对代码一处的修改，导致了系统中其他看似无关部分功能的意外损坏。（5）晦涩性 (Obscurity): 代码意图不明，结构混乱，导致阅读者难以理解其功能和设计。（6）数据泥团 (Data Clump): 多个数据项总是一起出现在不同方法的参数中，暗示着它们应该被组合成一个独立的对象。（7）不必要的复杂性 (Needless Complexity): 用“杀牛刀”去解决“杀鸡”的问题，过度设计使系统变得臃肿且难以理解。 - 【非常重要！！】无论是你自己编写代码，还是阅读或审核他人代码时，都要严格遵守上述硬性指标，以及时刻关注优雅的架构设计。 - 【非常重要！！】无论何时，一旦你识别出那些可能侵蚀我们代码质量的「坏味道」，都应当立即询问用户是否需要优化，并给出合理的优化建议。

AI编程工具激战：Claude Code、Gemini Cli崛起· 1081 条信息

#代码架构 #代码质量 #代码优化 #坏味道 #架构设计

4个月前

分享几张图： 1. 第一张是我设计EAF开源项目时，我家黑板上的架构图 2. 第二张是懒猫微服早期硬件白板三维图 3. 第三张是设计 lsp-bridge 的架构图所有的架构设计都源于三个事情： 1. 精准的知道自己要什么 2. 整体架构流程要思路清晰 3. 锻炼自己的复杂思维能力我每次做复杂开源项目的时候，我都会做三件事： 1. 问自己几个月，是否真的想要做这个，所有需求是什么？哪些是真实需求，哪些是伪需求？ 2. 在白板或者白纸上徒手画架构图，所有工程难点都先假设自己已经完成，纯粹画全景图，如果全景图画不出来，就证明自己脑袋是一片糨糊 3. 当架构图全部画清楚以后，我会反复的质疑我自己的架构图，直到所有伪代码已经在我脑袋运行千百遍以后，没有任何bug，我再写代码真正写代码的时候，就像第一张图一样，看着黑板的图，一个一个的写实现，写完一个擦一块，直到摩天大楼像预期一样分毫不差的实现。

#EAF开源项目 #架构设计 #懒猫微服 #lsp-bridge #复杂思维 #开源项目