（补11月）代码大全阅读笔记2

第6-9章的架构设计内容，彻底解答了我长期以来的核心困惑：为何同样实现了基础功能的代码，有的在后续迭代中能轻松响应需求变化，有的却如同“牵一发而动全身”的乱麻，修改一个小功能就引发连锁bug。书中系统阐述的“分层架构”模型让我茅塞顿开，尤其“表现层、业务逻辑层、数据访问层”的清晰划分，精准点出了我过往开发中的关键问题。此前负责公司电商平台的商品详情模块时，我为图便捷，将前端界面渲染、“判断商品库存是否充足”的业务逻辑，以及直接调用数据库查询商品信息的数据操作代码混写在同一个文件中。结果上线后，运营提出“库存不足时显示推荐商品”的需求，我修改业务逻辑时，不慎误删了界面渲染的关键代码，导致商品详情页短暂无法正常显示，这正是违背了“关注点分离”原则的惨痛教训。
书中关于“模块划分”的“高内聚、低耦合”原则，不仅有理论阐释，更有可落地的实践方法，让我对架构设计有了具象化认知。“高内聚”要求模块内部功能高度相关，比如将“商品的增删改查、库存更新、价格调整”等核心操作归为“商品管理模块”，而非零散分布在多个地方；“低耦合”则强调模块间通过简洁接口通信，避免直接依赖内部实现。受此启发，我对项目中的用户认证模块进行了重构：将密码加密（采用BCrypt算法）、短信验证码校验、Token生成与解析、权限判断等核心逻辑封装成独立服务，对外仅暴露“userLogin(String phone, String password)”“checkPermission(String token, String permission)”等清晰接口。重构后，当支付模块需要验证用户是否为VIP时，只需调用checkPermission接口即可，无需关心权限判断的具体逻辑；后续迭代中，将密码加密算法从BCrypt替换为Argon2时，也仅需修改认证模块内部代码，未影响任何依赖模块，彻底解决了此前“修改一处、牵动全身”的问题。
书中“架构需动态适配项目规模”的观点，更让我跳出了“要么过度设计、要么设计不足”的误区。书中明确指出，架构设计没有“放之四海而皆准”的模板：开发仅用于内部数据统计的小型工具时，若强行采用微服务架构，只会增加部署和维护成本；而开发用户量超百万的电商平台时，若沿用单体架构，后续扩展将举步维艰。我曾在开发一个员工考勤统计工具时，初期就设计了“考勤数据层、统计分析层、报表展示层”三层架构，还引入了缓存机制，结果因用户仅100多人，数据量极小，架构的复杂度反而导致开发效率下降30%。吸取教训后，在后续开发一个社区团购小程序时，我采用“单体架构起步，预留服务拆分接口”的策略：初期将所有功能整合开发，加快上线速度；当用户量突破10万后，基于预留接口将“订单管理”“用户管理”“商品管理”拆分为独立服务，平稳完成架构升级。这种“适度设计、动态调整”的理念，让架构真正成为支撑项目发展的基石，而非束缚开发的枷锁。