随笔分类 - 架构
摘要：什么是重构 软件内部调整，不改动原来的功能，将原来设计不合理的地方，进行完善，解决技术债务等问题。提高代码可理解、降低维护成本。 早期系统 开发速度快 功能业务相对简单 遵循编码规范，不允许不好的代码产生 晚期系统 业务复杂 代码量庞大 代码相对不规范 代码耦合性比较高，修改一处，容易引起其它问题
阅读全文
摘要：日志记录 第一时间获取用户操作行为 及时解决技术债务 遏制新增 code review 脏数据兜底和检验 单元测试 崩溃预警 自动化测试 更广的灰度触达 性能优化体系
阅读全文
摘要：技术填补 开发过程中因为时间紧迫导致的不合理的实现 某些算法性能较差 暂时没有想到更好的实现方式而妥协 例如刚开始使用if...else实现，随着条件越来越多，逐渐难以维护 可以使用责任链模式 架构设计前期没有考虑到的细节 例如交互细节-> props传递参数（交互冗余，流程较长） 使用全局状态管理
阅读全文
摘要：技术前期准备 技术选型：社区氛围、发展规模、未来发展趋势、与团队的契合、维护成本、迁移成本、执行效率 充分调研每一项技术可能带来的利弊 最大程度上预测架构设计中的缺陷，防止意外发生 技术优化 在构建发展过程中，可能存在有悖与技术 架构优化 架构不是一蹴而就的，架构是不断演进的
阅读全文
摘要：系统架构师 负责整体系统的架构设计 着眼全局，基础服务和各系统协调 负载、可靠性、伸缩、扩展 应用架构师 从应用程序的维度，负责某个应用的技术架构，主要偏业务系统 关注理解业务，梳理模型、设计模式、接口、数据交互等 业务架构师 从业务流程的维度，关注某一个行业、业务领域分析，获取领域模型 也叫业务领
阅读全文
摘要：稳定性 系统受到外来作用影响时，系统经过一个过渡阶段，仍然能够自身系统稳定 健壮性 计算机软件在输入错误、磁盘故障、网络过载、有意攻击，能否不宕机 架构质量的衡量 拓展性 维护性 可管理 高可用 日常开发中的架构质量 理解难度 接入依赖的成本 崩溃率和错误率的指标 开发效率 错误上报和信息收集等功能
阅读全文
